# "color-accurate" tonemapping

I will answer, but needs time. Still at work and then family… Stay tuned.

Preview: Basically your question wrt locus CIE Luv and xyY is answered here:
saturation change causes color shift (with default settings) (#171) · Issues · GNOME / gegl · GitLab I use exactly this blending to gray

• Remember that your screen/print is limited and you will therefor need to make tradeoffs to fit reality. So you have to be very clear about what sacrifices you want to make with your approach. In other worlds how do you treat your boundaries, especially when going from infinite spaces (scene referred) to finite spaces (display referred)
• What would the method look like if we could measure and work with the full spectrum of the pixel, is it possible to optimize the operation to something simpler? White balance by a 3x3 matrix multiplication is for example a correct solution from a spectral perspective.

Now for the debate about luminance/ratio based methods vs channel based methods. I see the same as you, changing the tone curve changes the response for both methods, the first sees a reduction in chroma for increased contrast while the channel based one results in a increase in chroma. You basically have to pick your poison here. I much prefer the per channel based version as it elegantly and smoothly handles the boundary change and the chroma boost looks pleasant to me. Luminance based methods does not handle the new boundary at all and usually leaves a lot of colors out of gamut (see post in the sigmoid thread with the 2D examples).

I actually think that we should do both, first a luminance based contrast change to normalize the luminance range for the next step a per channel based method that handles the boundaries. There is likely a function that can be found for the relationship between the two if we want to maintain constant perceived chroma of the image.

Finally tip, implement you method in 2D and plot scatter plots with input/ouput. Helps a lot as our eyes aren’t always that reliable for color/brightness. We are a whole lot better at understanding geometries!

2 Likes

in short, what I want: systematically overcome the (de)saturation effect stated in Exposure - RawPedia

to achieve that, after finishing luminance-based operations, the steps are

1. re-map luminance from source to target - preserving spectral color of pixel (no change in saturation)
2. adopt chroma to overcome the (de)saturation effect.

here in the chart the “source” color patch is upscaled to a target - thats simply exposure (multiplying every channel):

and step 2: adopting chroma using the ratio (new contrast) / (old contrast)

No need for converting to LCH or JAzBz or sth. similar. Just linear blending between achromatic image and the image itself. done within the images colorspace. And it preserves hue better than CIE based methods (operations/common/saturation.c · master · GNOME / gegl · GitLab)

I much prefer the per channel based version as it elegantly and smoothly handles the boundary change and the chroma boost looks pleasant to me. Luminance based methods does not handle the new boundary at all and usually leaves a lot of colors out of gamut

absolutely! Thats it. This “looking pleasant” of channel based approach … or in my opinion this “looking not usual” of the luminance based approach. I think the proposed chroma-scaling method could extend the luminance-based methods to look as pleasant as the channel-based approach like you say:

There is likely a function that can be found for the relationship between the two if we want to maintain constant perceived chroma of the image.

With regard to the high out-of-gamut risk. Yes. This is the “downside” of luminance based workflow (thats btw. also shown in my chart (1). blue and maybe green massively exceed gamut.)
But I usually use S-shaped tonecurves on luminance: the upper (and the lower) end of the “S” have a slope (contrast) of “0” and thus with my contrast-based chroma-reduction my highlights can be tuned to be totally achromatic - to fit into given gamut.