I pushed a commit that makes the exposure normalization optional :
As expected, not normalizing tends to make the max dE increase while the average dE should be a bit lower, provided the color checker is evenly lit. If not evenly lit, it’s completely random.
Hello to the Pros,
I am fairly new to darktable and RAW develpment and have read into the matter because for me it proved to be really hard to get my RAW colors from my Sony Alpha 6000 up to speed when taking the OOC JPG as a benchmark… I know it isn’t about reproducing the OOC look but for me it would be a good starting point to further improve the image. Having said this I read about color profiling with darktable -chart and the like even bougth myself a colorchecker passport and a spyder 5 for monitor calibration (didnt wanna break the bank right from the start though). Now I am waiting for the right illumination to create a D50 camera profile.
Nonetheless I would really like to use per scene color calibration with the cecker as described above. While knowing I am just a beginner and you surely have thought it through more than I could I have some questions and suggestions concerning this:
It has been said that Camera whitebalance does have to be aplied before calibration.
Do I have to apply a basecurve first too (I have one for the alpha 6300 that is fitting quite good)?
I have been using Rec709 linear as color input up to now for it gave me the best (to my eye) color reproduction. Is it important for the calibration module from Aurelian to chose another input profile?
When shooting with high iso and therefore chroma noise - should this be cleaned to achieve better color matching?
some suggestions about usability knowing the module is not ready yet:
as suggested rotation of the grid would be very handy
also shrinking and growing the pattern (e.g. with Ctrl-Mousewheel would be easier than to throw in another module?
it would be nice if the module remembered grid positions - currently they are lost when switching to other modules. Also the white and black field of the grid could display the luma lightness. As long as the grid keeps beeing displayed when in other modules one could better adjust the exposure
Auto transfer of the suggested Exposure and/or black point adjustment to the Exposure Module could be handy
Option to write a color profile to disk (is that even sensible - I am not really in your league concering the tec behind all this)
If I understand all this correctly this looks like a very nice tool to get pictures from several cameras with a consitent look and to easily get better color matching in general
Thank you very much for all the effort and heart you put into this
to create a color profile you might consult:
https://ninedegreesbelow.com/photography/well-behaved-camera-profile.html
or pcode — Darktable Camera Color Profiling
Thanks for that input… Quite a lengthy read before one can attempt to tackle this 
A degree in color science would be helpful… I will wait for the right weather to take the shots and meanwhile try to catch up on the principles behind all this… I seems it is not as simple as taking nice pictures if you want to raw-edit them…
If you get a dev build you can use the colorchecker in color calibration to modify you icc and better match color…Color calibration : add profiling from color checker by aurelienpierre · Pull Request #7293 · darktable-org/darktable · GitHub
This may be true but changing the histogram profile changes the values when looking at RGB values. LCH and Lab values from the picker don’t change when you change the histogram profile but RGB and HSV do…if some one has other then sRGB set for their histogram profile the values they might see if trying to test rgb values for patches will likely be much lower. I know they are lab based color patches but I just observed this when messing around with the picker and trying to see how it was deriving values…
Of course. RGB values are always relative to a particular colour space, and they are completely meaningless unless you specify exactly which colour space they relate to.
Ya I just commented as it can be a bit confusing to say the color picker works in display space or color profile. At least to me. In this case you have not altered your working profile or display profile so the colors in that pipeline should not change when you change the histogram profile, if that selection is meant only to change what profile is used to display the pipeline in the histogram. It would seem that the colorpicker values do change and so they are related to the histogram profile?? Maybe I am missing a nuance here. It makes sense to me that the values do reflect what you see in the histogram but I would not take that from the note in the manual and as of late several questions about values given by the picker from users clearly indicates that they are not even aware that changing the histogram profile could or would change those values…
Edit…maybe I need to review where the conversion through the display profile fits…I thought it would be input to working to output to display and output would branch to histogram …maybe this is where I go wrong in my thinking
If that is not explicitly stated in the manual, then I would consider that to be a defect in the documentation, and a github issue should be raised against dtdocs.
I think in a recent post AP actually said the color picker works based on the histogram profile. It might have been @kofa with his post on the colorfulness slider in the color cat module…I should go and look it up…
I already tinkered with the above linked 3.5 win64 build which works fine. But the link to aurelians description has been inspiring as to my questions - thanks!
currently it seems to me the only way to transfer the computed color correction is via a style that is then applied to other images… For each solved question a new one arises…seems I have a lot to catch up using dt…
I think a preset will do it…it just adds coefficients to the r g and b channels of the channel mixer…
It seems like some changes have been proposed but maybe have not made it there yet…also it seems to have been confusing even for the developers…long standing thread but the last few comments are relevant to our discussion and fairly recent… Choice of display profile affects histogram, color picker values and overexposure indicators · Issue #3271 · darktable-org/darktable · GitHub
This is fixed in current master
The global color picker works in the histogram profile: https://darktable-org.github.io/dtdocs/module-reference/utility-modules/darkroom/global-color-picker/
Also the clipping indicators work in the histogram profile.
The manual at darktable.org is probably out-of-date in this aspect.
Thanks I was reading the stuff in PR 3271 of which your were a part from Nov 2019 until just recently ….it sounds like it was meant to be updated but likely just fell off the radar…
Matt Maguire sent me a link from the “new” one but it had different text…WIP I guess…
That link is the new one. The WIP version is at https://darktable-org.github.io/dtdocs/en/ and the version released with 3.4 is at darktable 4.0 user manual - darktable
The darktable.org usermanual link at frozen at the time of the 3.4 release (ie. just before Christmas). The github.io link shows the latest master branch of the dtdocs usermanual. At the moment, the dtdocs master branch just contains “bug fixes” to the docs which are relevant for DT 3.4. At some point a branch will be created for the 3.4 version oif the user manual, and master will start to take in document changes for new 3.5 features (like the new color chart and color balance rgb features).
Thanks guys for the clarification. By new I had meant the new format not the newest version so it’s good to know what is hosted where