Introducing color calibration module (formerly known as channel mixer rgb)

This is so awesome. Like watching Bob Ross painting, only for photography tech geeks. Keep up the good work, Aurélien, I already set up a liberapay recurring donation to support this amazing project.

3 Likes

Done :

9 Likes

Help please! I’ve just built Master, got 3.3.0+2085~gab91bf320-dirty, but can’t see the new checker GUI
-NoChecker

The build log includes the line “-- Found gtk±3.0, version 3.22.30”

Ubuntu 18.04, up to date

Any ideas please?

It is not yet merged in master. To get it, you would need to:
git pull https://github.com/aurelienpierre/darktable.git color-checker-calibration.

Thanks, I think I’ve done it. (I couldn’t get Pull to work but I did
git clone https://github.com/aurelienpierre/darktable.git ~/DT-Mast-13Dec20AP/darktable-code
git checkout color-checker-calibration
and it built (2.5.0+8469~gfa4716a8e-dirty).

I did a passport calibration with adaption=cat16, got a good report with deltaE=2.6avg, and noted the matrix.

The checker was photographed in summer in bright sunshine. If I want to use the calibration on a similar photo, is this what I do? -

  • set white balance to camera reference
  • in color calibration, set adaption to none? or same as for original calibration i.e. cat16?
  • type the matrix values into “R”, “G” and “B” tabs (assuming the original matrix was presented R-G-B across and down)

I’m getting a magenta cast, no doubt user error!

In the pull request item under “How to use” you say use the D65 reference white balance. Is this equivalent to choosing “camera reference” in WB?

The matrix you produce is only ever valid in the same space it has been produced. The tests I did so far show that CAT16 exhibits slightly smaller delta E after white balancing, so I personaly do everything in CAT16.

You have a button to commit the the matrix into the mixer directly. Just save that in a preset, then only adjust the illuminant.

D65 reference is for the white balance module. In color calibration, you set the illuminant to match the scene.

Also, I did tests with custom WB coeffs in white balance module (using a shot of my D65-calibrated screen), put that in a preset, and it tends to help the delta E of the profile to decrease. Just display a white patch on screen, and use the color picker in the central part to get the coeffs that make the patch appear neutral.

1 Like

@anon41087856 would it be possible to get a way to use the SC24 as well…its just the 24 patches starting from E1 so essentially same data set as the 48 just missing the first 24 patches…

if you know how to deal with code, it’s not terribly complicated to hack the colorchecker.h lib in my pull request (it’s just array declaration).

I’ll give it a try thanks for the starting point…

colorchecker_DT Mod.txt (15.9 KB) I made some edits based on your suggestion. Not sure if they are correct. I guess I need to figure out github so I can properly do this and respect process and etiquette. One thing …you are using the adjacent patch to white as middle gray…I think it should be patch 3 or 4…no ?? ie closest to 50% CIELAB lightness?? Think the patches are 0, 20,40,60,80,100% if I recall?? @MStraeten ?? EDIT:I just noted that I did not update the patch coordinates for the SC24 so I will do that and I missed a couple of other changes…should be corrected now…colorchecker_DT Mod_corrected.txt (15.9 KB)

I think, the second patch is ok. It’s about rgb 200/200/200 or L81 which is pretty near to 18% grey. It’s not the most neutral patch - thats patch 4 in the greyscale

So log vs linear…all the proprietary software that I am aware of uses 50% ie the linear ~128 127 127 or 128 128 128 ish RGB as middle gray and when doing icc directions are to WB on that patch Maybe it is what Aurelien is doing with the data?? https://www.xritephoto.com/ph_product_overview.aspx?id=943&catid=28&action=overview

The grey patch is just meant to perform the illuminant detection, its luminance matters less than its chromaticity: it’s should have a and b as close to 0 as possible. Anyway, color calibration does not deal with tone response.

Cool, thanks ! That’s like 98% of the job done to get support, I will wire the last bits.

If it’s about chromacity then it’s better to use .middle_grey = 21 for all xrite Colorchecker variants.
Just the black patch 23 is a little bit better

instead of hard coding the chart values why not have two external files withe same name but different extentions, one with values of the patches and one with the layout of the chart like in dcamprof .cie and .cht. Both this files can be put in .config directory under a directory like colorcharts.

so this module can work with many different types of color calibration charts of today and tomorrow

Just a suggestion

That would require an intermediate file parser and I’m not going to code that. Plus the cht files from Argyll are over-engineered and yet still miss some information like where the white and grey patches are.

Hardcoding is easy, consistent and fast to read, aka predictable and robust. It also mean someone has to check the validity of the charts instead of allowing users to put whatever in there.

2 Likes

Spyder Checker 24 is now supported.

@anon41087856

Spyder Checker 24 is now supported.

Thanks a lot!

Why illuminant is invalid? In WBModule when I press Camera reference Channel coefficiants are R=3.023 G=1.00 B=1.502 I

https://darktable-org.github.io/dtdocs/module-reference/processing-modules/color-calibration/#cat-tab-workflow