• Please use real names.

    Greetings to all who have registered to OPF and those guests taking a look around. Please use real names. Registrations with fictitious names will not be processed. REAL NAMES ONLY will be processed

    Firstname Lastname

    Register

    We are a courteous and supportive community. No need to hide behind an alia. If you have a genuine need for privacy/secrecy then let me know!
  • Welcome to the new site. Here's a thread about the update where you can post your feedback, ask questions or spot those nasty bugs!

Chromaticity shift in RGB tonal remapping

Doug Kerr

Well-known member
In another thread, Mike Spinak gave a link to a video from Unified Color discussing their own color space, "Beyond RGB" (gag me with a spoon), used in their HDR processing software.

It mentions a problem with "color shift" when applying tone remapping curves in the sRGB color space, and how that can become very troublesome in HDR processing..

I suspect they are speaking of chromaticity shift (we of course must shift colors when we do any remapping). (In their entire presentation, they call chromaticity "color".)

I thought I'd discuss one such phenomenon, not in the context of HDR processing, but in something perhaps more familiar.

Here we see a tonal remapping curve we might set up in Photoshop. It is set up to affect all three color "channels".

Chrom_shift_01.gif

Imagine that in our starting image we had a small region whose RGB coordinates were 50, 80, 110.

When we then invoke the curve shown, its coordinates then become 38, 68, 116.

The chromaticity of the region (with its original coordinates) on the CIE x-y chromaticity diagram (the graphic presentation we most commonly see for chromaticity) is x=0.26, y=0.28.

We can see that here:

After the "S-curve" has been applied, the chromaticity of the region is x=0.23, y=0.23. That means it is visually "more blue" than it was before.

CIE_x-y-01a.jpg

We might wonder why this is. Is it not so that if we have a color with certain coordinates and change them all proportionately, the chromaticity remains unchanged?

Quite so. (Almost exactly.)

But in our example, the initial values of the three coordinates fall at different points on the curve (at the horizontal values of the three little dots shown in the lower-left portion of the chart, in fact). Because the curve is non-linear, the new values of the three coordinates (the vertical values on the curve) do not change proportionally.

By the way, how could we avert this particular phenomenon? A direct way would be to use a luminance-chromaticity color space, and then doing general-purpose tone remapping on the luminance channel only.

Do we ever use such a color space? No.

Isn't L*a*b* a luminance-chromaticity color space? No. It is a pseudo-luminance, pseudo-chrominance color space. If we change L*, and leave a* and b* alone, the chromaticity does not remain constant (although it more nearly does than when working with RGB). (The pseudo-chrominance does remain constant.)

How does the color space used by Unified Color work, and how does that avert (or mitigate) this phenomenon? Beats me.

Best regards,

Doug
 
Hi Doug,

Thanks for the clear explanation/demonstration of a potential pitfall, that is (not only but) particularly relevant to the extreme luminance shifts that are used in HDR imaging.

[...] Because the curve is non-linear, the new values of the three coordinates (the vertical values on the curve) do not change proportionally.

By the way, how could we avert this particular phenomenon? A direct way would be to use a luminance-chromaticity color space, and then doing general-purpose tone remapping on the luminance channel only.

Do we ever use such a color space? No.

Well, usually not when we work in an ordinary RGB based photoeditor application. However, when we only want to change the overall luminosity with a curves adjustment, it's better to use a Curves Adjustment Layer, and change its blending mode to Luminosity.

Isn't L*a*b* a luminance-chromaticity color space? No. It is a pseudo-luminance, pseudo-chrominance color space. If we change L*, and leave a* and b* alone, the chromaticity does not remain constant (although it more nearly does than when working with RGB). (The pseudo-chrominance does remain constant.)

AFAIK, the Lab colorspace is used in Photoshop as a profile connection space, so at that level it has an effect on what we're doing, but not in a common Curves correction scenario. Also, converting to-and-from Lab mode in Photoshop is lossy and will shift colors (e.g. the blue to magenta skies issue).

How does the color space used by Unified Color work, and how does that avert (or mitigate) this phenomenon? Beats me.

They are not likely to tell us, but I assume they lean on the CIECAM02 Color Appearance Model for the perceptually correct adjustments of the 6 axes that that model allows to use.

For Photoshop Windows users, there is a free CIECAM02 plugin that allows us to change several aspects of our images without introducing chromaticity shifts.

Cheers,
Bart
 
Top