Great,
Thank you that worked! However the rgb values I’m getting from the calibration (see the color pickers on the left) are quite far off the published values. Is there something I should be doing to bring them closer in line?
PS…thanks for your help.
I suspect you want to make sure that the image is properly exposed, eg. so that the light white square is L=96 when you put the colour picker in Lab mode (you can refer the the ArgyllCMS .cht files to see what L value that pathshould have). I will take multiple images bracketed at different exposures in camera, so that I can select a properly exposed image when building a profile.
Its well exposed…i promise.
I have been using 3dLut maker to do this process for a few years now. I expose as close as possible.
Im suprised by how dark the blacks are…Ideally after this process they should be around 52 rgb, then next grey around 122…
You should be aware that the coefficients produced are relative to the CAT color space, not to the working profile color space (REC.2020), so this could result in different RGB values. Note that the specific RGB values depend on the primary colours defined for that RGB colour space, and there is no such thing as “absolute” color-space-indepentant RGB values.
I think I see what you are saying…
But I’m just surprised it seems that the black point is set much darker than what would match the chart. Even just looking at the last two darkest grey patches by eye. The profiling chart is much lighter than the patches in the resulting image.
Ps, if possible it would be great to have a rotate chart button to flip the calibration matrix in 90 degree increments.
What color profile do the pickers use to calculate the values they report histogram working display??
The global color picker works in the display profile colorspace:
https://www.darktable.org/usermanual/en/module-reference/utility-modules/darkroom/global-color-picker/
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.
Okay, that makes sense. That’s what I’m looking for!
Awesome…ill report back on the result.
Okay,
Getting very close. However, two issues i can see.
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.
Much appreciated!
RGB values you are stating for the color checker are also for d65…for other illuminants you would have to adjust…not sure how much that would change them but it would change them…https://www.xritephoto.com/documents/literature/en/ColorData-1p_EN.pdf
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.
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
