In the profiling report, the last line gives you the black offset and exposure compensation to input as-is in exposure module if you want an exact color match including brightness.
Also, if you want to check the final colors, use an Lab color picker, otherwise the RGB values given in reference are usually sRGB or Adobe RGB but are measured by darktable in whatever display space, so basically you are comparing numbers that are not expressed in the same space.
Side note : your average delta E is quite good, so if I didn’t mess up the delta E computation, it means you have nothing to worry about.
Getting very close. However, two issues i can see.
The values on the 4th and 5th patches appear to be quite low compared to the reference values of RGB 121 & 85.
The white balance across the neutral patches isn’t great the whole way along. Even when optimising for the neutral patches.
I know the color pickers are still in RBG. However, when I export the image to 8/16 bit tiff and color check them in other apps, I get approximately those same values as DT pickers show in RGB. So, for my purposes those RGB values are a good reference.
Just curious if there is anything else I should be doing to get the colors closer. I’m following exactly the GitHub instructions along with inputting the black offset and exposure compensation into the exposure tab as Aurelien explained above.
PS…thanks for all the help and effort. The implementation is fantastic, just trying to understand how to get them best/closest reference values (color +luminosity) out, and so understand what the limitations are.
The problem is, to calibrate against luminance too, you need a perfectly even light on your target. To deal with the light field variations on charts shot on-location, under whatever light is available, the calibration first normalizes luminance, aka assumes each patch has the right luminance. This way, we only calibrate for color (hue/saturation) and disregard exposure discrepancies.
Then, the result shown is a numerical fitting. It will never be perfect. But from your screenshot, your average dE is already quite good, so I wouldn’t bother trying to get better. The next step would be using a LUT, that would allow correcting the non-linear effects.
I could add an option to disable the exposure normalization though, but I’m pretty sure the final dE will increase.
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.
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
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…
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…
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…