Over the past few days, I’ve been testing some ideas on the color look up table (colorchecker) module in my experimental libre DT-Lab fork. The module is already great, but I wanted to see if it could be modernized a bit for scene-referred workflows and allow chart calibration directly within the UI.
Personally, I’m very happy with the results, which motivated me to share them here. However, given the high volume of incoming proposals right now, I’m conscious that an overload of PRs can burden the core team and darktable itself. Do you think these changes would be a good fit for upstream darktable? I would be more than happy to discuss them and refine the code if there is interest.
Here is a quick summary of what I’ve been testing:
Scene-referred CIE XYZ mode: Added an option to switch between CIE Lab and CIE XYZ. In XYZ mode, the TPS (Thin Plate Spline) fitting runs directly on linear RGB / CIE XYZ (D50) via the pipeline’s work profile matrix.
In-app chart calibration: Added a 4-corner bounding box directly on the preview to sample target patches with automatic warping and CIEDE2000 feedback. It avoids roundtrips to external calibration routines.
TPS Smoothness slider: Added a regularization control to the TPS solver. It helps smooth out steep color transformations and avoids artifacts/overshoots (for instance on saturated gradients or noisy patches) at the cost of a slight fitting error.
OpenCL & robustness: Updated the OpenCL kernel to support the new modes and cleaned up a few edge-case divisions by zero in the math.
Everything remains fully backward compatible with existing edits and presets.
If anyone would like to test it, the latest code is available on GitHub and I’d love to get your feedback!
Happy editing,
& greetings from the Luberon
Christian
Hi
I’ve been following your hard work on new/upgraded modules for some time. I have two questions for you which I’m sure you up have considered!
Have you thought about making your fork of DT permanent and it so what would it look like?
Hello,
That’s a very good question, but I can’t give you a precise answer.
Originally, it was just a playground for learning without breaking darktable—a place to experiment freely and, above all, to learn. Currently, I use my fork on a daily basis, but I also receive a few requests for it, which is why I’m committed to ensuring its long-term viability.
It’s important to realize that darktable and my fork have undergone so many changes on both sides that it’s difficult for me to keep them in sync. So for now, I’m letting my inspiration guide me and am no longer trying to synchronize them.
As for the future, I don’t yet have a specific plan for this fork; it will all depend on how I use it and on requests from the community. In any case, I hope it can be a source of inspiration.
Happy creative editing!
Christian
Hello,
I’m sorry, but GitHub Actions has discontinued its build service for Intel Macs. I’m looking for a solution, but I don’t own a Mac, and I’m not very familiar with macOS.
I’d appreciate any information on this, as I’ve received a few requests from Intel Mac users.
Greetings from the Luberon,
Christian
I would be all over this! I’m doing exactly this with darktable-chart at the moment, to emulate Fuji film simulations. But that requires a specific export format, futzing with an external program, then managing the resulting styles…
If I could do all that right from within darktable, I’d be very happy! Does this “merely” equalize all colors to color-checker-neutral, or can you measure and fit custom targets, such as a film simulation render?
How does it deal with luminance-vs-color changes? I find it useful that darktable-chart separates them into a tone curve component and a color component. I guess I could just put a tone curve before the color lookup table that equalizes luminance, then the lookup table would only affect color.
Does that imply we could use a similar method in the tone curve? I’m just thinking out loud, don’t mind me.
That’s a very interesting idea. We open an OOC TIFF/JPG file, take a measurement by selecting the chart used, and after measuring the OOC file, we’d need to swap the source and target to achieve the desired look (otherwise, we end up with a neutralized result).
This gives us the following workflow (film-sim emulation):
Open the OOC (JPG/TIFF) and adjust the white balance.
Select the color chart, position the patches, and measure → source = measured OOC, target = reference.
Swap source and target → source = reference & target = OOC = the film-sim look.
Save a preset.
Open the RAW file and apply the preset or the last measurement.
With this option, we could implement two complementary features:
Invert the measurement → complete film-sim look (color + tone);
Preserve luminance → affects only the color.
What do you think,
I was thinking along the lines of the measure mode of color calibration. In the default correction mode, it equalizes a given patch to neutral. In measure mode, it shifts the target, so that the next correction equalizes to the new target.
Here is the latest version; I’ve fixed a few bugs and also included the two options mentioned above.
First, thanks to @bastibe for the idea. It led to a new option that reverses the direction in which the chart measurements feed the mapping.
Normally, measuring a color chart gives a calibration: the colors you actually photographed become the source, and the chart’s known reference values become the target, so the spline learns to bring your image back towards the reference. The new “measure as target” button reverses this: the chart reference becomes the source and the measured colors become the target. The same measurement then describes a look to reproduce rather than a correction to apply. That is useful when you shot a chart under particular lighting, through a filter, or with a film emulation already applied, and you want to keep that look instead of neutralizing it.
I also added a “colors only” option. It keeps the source lightness of each patch instead of the measured/reference lightness, so the calibration or look mainly changes hue and saturation and leaves the tonal curve untouched. Handy if exposure and contrast are already handled elsewhere and you don’t want the chart to override them.
Both options act on the patch data before the spline is solved, so they combine with the exposure-anchor normalization and the smoothness setting described above.
Just having my morning coffee…so this might be a dumb question…so if someone has a jpg with a color chart could this be a source to apply back on the raw to get them closer to this often requested jpg “look” for editing??
Absolutely, that’s the goal. I took an old photo of a color chart shot in RAW, processed it with Pentax software by adjusting the white balance, and then applied the various Pentax profiles to it.
And with the modules, I perform an inverse correction without luminance to create a look—it’s as simple as that.
I’ve noticed that when I measure using luminance, it’s better suited to a workflow that’s display-referenced.
P.S. It’s almost aperitif time here, so I’m going to go make myself a little pastis.
Greetings from the Luberon,
Christian
Apropos of nothing, it’s a great idea that you extend the existing color lookup table module, instead of creating a new one! We have so many new modules these days it’s almost difficult to keep up.
Just for my understanding, how is this update to the lookup table module different with the calibration that is already there in the colour calibration module ?
How does the two interact ?
Hi Christian, you immediately grabbed my attention with this because the Color Lookup Table is one of my favourites, and I have previously requested an updated, scene-referred version of it on Github here
I love the interface and the simplicity of being able to adjust the hue, saturation and lightness all from one panel. And the killer feature of it is that it takes hue, saturation and lightness into account when selecting colours, so selecting a light blue won’t select a dark blue, for example. In Color Equalizer, this is not possible without masks.
But the module is not currently perfect, obviously:
For starters, it isn’t designed for the scene-referred workflow, so it can be prone to artifacts if pushed too far.
And the other issue I have with it is that there is no visualization for what is selected, e.g. a mask view for the chosen patch. Sometimes, a patch will bleed into a similar colour, but you can’t tell until you start adjusting sliders.
So, am I right that you have already addressed the first point above?
And for the second point, it would be great to have a mask view when you select a patch, so you know exactly what you are working on. Plus, some way to control the breadth if you need to refine the patch.
Is having a certified color chart a necessity, or because this is all relative, accuracy of the checker’s colors is not a requirement? I guess the only critical thing would be the white patch for WB?
