[Question] Color EQ questions and feedback

[pedrorrodriguez]

@aurelienpierre first of all amazing work on the color equalizer. The more I play with it, the more impressed I am at its capabilities and robustness. Particularly at strong brightness pushes based on hue or hue twists that span the whole shadows/midtones/highlights range and look natural (and again, don't break!). All without having to mask a single thing.

I do remember talking with you about the possibility of having a "primary vibrance" setting, for lack of a better term, where you would control a node between achromatic and max chroma for a certain hue angle. No matter where this max chroma node may have been moved to, the primary vibrance node would move towards it. This would allow for chroma soft clipping at lower chroma values, which I believe is one of the visual cues of the "film look".

My question is:

• Did you forget about our conversation, or decided against this for some reason?

Also:

• Why no cubic interpolation? Performance and overshoots? Negligible differences?
• Since the color picker can place the hue in the graph, as well as provide the percentage that each luminance range contributes to it (65% midtones, 35% highlights, for example), and since more often than not, whatever you sample will be a mix of two ranges: Would it make sense to have a "link" button next to the color picker, in case you want to make the adjusment in one go? In the example above, if linked, I would tweak the midtones, and automatically apply the same correction to the highlights at the appropriate ratio. This would only work if the color picker is activated. If not, nothing would be linked. After taking with @Jiyone this is nonsense. The ability to link/unlink shadows, midtones and highlights tabs would be very handy I believe. Not the advantage I thought it would be, across several images. A simple mode does not come from linking the tabs.

[aurelienpierre]

Did you forget about our conversation, or decided against this for some reason?

I forgot and also this is not really possible to implement in the current module, first because it would really tear the RGB LUT, then I can't think of a nice GUI to do that. That would be another module.

[pedrorrodriguez]

Hold that thought. I'm working on a detailed report for you. Charts and shit. Great stuff

[aurelienpierre]

I just added the same interactive cursor in color EQ as in tone EQ. See the doc : https://ansel.photos/en/doc/views/darkroom/modules/color-equalizer/#live-preview-interaction

[pedrorrodriguez]

Just saw. Great idea. I need to play with it some more. This probably negates the necessity for a 'simple' mode altogether.

[pedrorrodriguez]

With the help of Claude, I'm plotting various curves for various attributes of film images. They 86 images are color negative, but different stocks and scanned with two different scanners: frontier and noritsu. Additional processing besides white balance, black and white point and probably some contrast/saturation is unknown. My guess is not much besides the baked in profiles of those scanners, which is unavoidable.

I confirmed that the graphs were the same (for a handful of images) across chat gpt and Gemini. Hallucinations may happen, but I'd think it's unlikely that the three models would do so in exactly the same way. I consciously refrained from sharing my own biases or hypotheses with the LLMs. The results intuitively match what I see with my eyes.

I started with a chroma distribution, then a hue distribution, then a luminance distribution, then a 4D graph that plots chroma, luminance and number of occurrences on the 3 axes, and is colored with the image's hue, so you know where hues fall in the graph. If you look at it one way it's a regular histogram. If you look at it from the other side it's a chroma histogram. In 3d it's actually both + hue distribution as well. This kind of thing:

This is actually the average chroma/luminance/hue distribution.

This is the limit:

I also plotted average curves, and the curves as number of images approaches infinity.

Key takeaways from my report so far:

• Max chroma never exceeds 90% (images of neon lights), and is often much lower.
• The average chroma distribution is a downwards exponential curve. Number of occurrences diminish rapidly as chroma increases. This results in a somewhat muted image with some high chroma accents.

• The other main shape is relatively low max chroma, two peaks and a valley. The first peak is around achromatic, the second more or less close to max chroma. This results in very colorful images with low max chroma. If the second peak is very close to max chroma, it results in beautiful soft clipping, or chroma compression or however you want to call it.

• A regular chroma boost would not produce either of these shapes. It would tend to flatten the chroma histogram, and push colors into neon territory or out of gamut easily. As we know, saturation is more robust than chroma, since it avoids neon colors. However the distribution problem remains.
• The double histogram surface of course follows the chroma distribution, but generally shows that the bulge closest to max chroma (when there is one) is common to various hues. That is to say there are generally no individual peaks for different hues. That probably means we only need a way to control mid chroma relative to max chroma globally. So one slider relative to the color EQ saturation curve?

• We know that as film saturates it darkens. However max chroma is generally in the midtones. If deep rich colors are below the midtones, their chroma value is not that high.

[aurelienpierre]

Ok, but then what ?

What you are reporting here is that film gamut is slightly larger than sRGB and not as large as Adobe RGB (max chroma ~90% of CIE Lab C*) and that nearly-achromatic colors tend to be close to white or close to black (but that's again a gamut property).

Regarding the stats distribution of chroma vs. density, there is not much I can do in a pixel-wise module. There are histogram normalization technics, but they work in discretized spaces (typically 8 bits integer), and they are quite brittle in color. Forcing a chroma falloff on each pixel based on its chroma will not guarantee that the final image stats will respect the statistical prior. And even respecting the stats prior is not in itself a guarantee of emulating a film look.

[pedrorrodriguez]

Density is misleading here. Claude calls number of pixels, density.

Film emulation is not the goal. It's the standard, because it looks fantastic in terms of contrast and color.

What I'm observing is that chroma distribution in film makes two shapes: a peak towards achromatic and a long tail, or two peaks, one close too achromatic and one close to max chroma.

Chroma peaks are common to many hues.

The images analyzed are srgb, so their gamut cannot exceed it. Also frontier and noritsu output srgb afaik. Max chroma is well below max chroma in srgb.

Regular chroma or saturation controls don't produce the desired chroma distributions.

• I would like a way to control mid chroma (relative to max chroma) to be able to push it towards or away from max chroma.
• This means children nodes between your saturation nodes and achromatic in color EQ.
• Since chroma peaks are common to many hues, I think we could just have one slider to control them all (to move them all at once towards their parent nodes or away from them). Don't expose these children nodes to the user at all.
• Why would this break the lut? In a 64x64x64 lut, why is it bad to have 96 control points instead of the current 72?

[aurelienpierre]

Regular chroma or saturation controls don't produce the desired chroma distributions.

Indeed, because they do pixel intensity changes and not global image statistics. There is no way to anchor stats with a simple intensity change, it needs to use machine-learning to optimize the stats against a cost function.

This means children nodes between your saturation nodes and achromatic in color EQ.

As usual, it's not that simple because the color EQ nodes are defined in dt UCS HSB so the input S is fully contained within sRGB. So inserting nodes in-between is going to behave quite differently for blue or green, for example, since the space is not even.

Why would this break the lut? In a 64x64x64 lut, why is it bad to have 96 control points instead of the current 72?

Because 3D geometry is hard and nodes are not evenly-sampled in the 3D RGB space since we define them in dt UCS HSB space. Interpolation is always finnicky, and while 3D RGB interpolation preserves gradients much better and allows for smoothing parameters, it's still not magical and you don't want to over-constraint it.

And then remains the GUI… I have no idea how to insert that into the current GUI without turning it into a Darktable module.

I rather see a vibrance/gamut compression extra module, that protects the inner cylinder around achromatic, and stretches/compresses the outside, or the other way around. That would duplicate the existing color EQ GUI with a clearly different goal and different maths.

[pedrorrodriguez]

The GUI would really not be the problem. Adding a vibrance slider below the saturation graph is not overwhelming.

Regarding doing this in another module, you are the expert. If that is more robust/behaves better, there's absolutely no problem with it from the users POV.

[pedrorrodriguez]

OTOH I just tried the cursor thingy for color EQ. It's fantastic. Could it be that it sends the order to recompute the pipeline before updating cursor and curve? I've had some responsiveness issues.

Also, a 'simple' mode might eventually be welcome as well. Instead of 72 control nodes just 24 (idk how it's designed, maybe it's just 8 nodes and the three curves just control their movement along each axis). Basically get rid of highlights and shadows controls and control the strength via falloff sliders. Not to replace the current design, but in addition to it.

[aurelienpierre]

Remember we are defining a 64x64x64 LUT at the end. Currently, we have 3 hue rings, evenly-sampled at brightness = 15/45/75 %. On each hue ring, users define 8 GUI hue nodes that are interpolated at 64 evenly-sampled intermediate control nodes to build the LUT. Aka we are building the cube from 3 cylinder slices.

I can't build LUTs out of thin air, it's a volume. I need at very least 2 cylinder slices or a cube, so it's at least highlights/shadows. The more LUT volume we cover, with evenly-spaced samples, the more robust the interpolation gets. But a simple mode would cover only a surface, not a volume.