@ggbutcher and @snibgo both mention the fact that various operations can push originally “in display range” channel values into negative territory. This is one reason to consider not clipping to 0. Unfortunately as noted in various recent pixls.us discussions, sometimes trying to make further edits using <0.0 (and sometimes even with >1.0) RGB channel values can lead to unexpected and visually awful results. Snigbo suggests one way to deal with these issues, and it seems like an approach with a lot of potential, but as always the devil is in the details.
Not clipping negative (out of gamut) channel values to 0.0 can be very important, even before any actual editing operations have a chance to produce negative channel values. Sometimes channel detail in the raw file will be summarily and irrevocably lost by a “negative channel values clamped to zero” ICC profile conversion. This does happen in RawTherapee and I’m fairly sure it happens in a conversion to LAB that happens somewhere in the RawTherapee processing pipeline. Here is an illustration of the problem:
“1” is what the color image looks like.
“2” is what the blue channel looks like in the interpolated raw file, after assigning a custom camera input profile and before converting to any other color space. This is the detail I sometimes want to preserve either as a blending layer or for channel-based conversions to black and white.
“3” is what the blue channel looks like in RawTherapee after converting to one of RawTherapee’s hard-coded RGB working spaces.
“4” is what the blue channel looks like when asking RawTherapee to convert to the custom camera input profile upon saving the interpolated file to disk. This conversion back to the input profile doesn’t retrieve the original blue channel information. The detail captured by the camera is gone.
Sometimes I use the channel detail from the camera raw file as blending layers, and sometimes for black and white output, which is one reason why I like the option to output completely scene-referred files that are still in the camera input color space. But currently this isn’t possible with RawTherapee, except when using the following work-around:
- Assign a linear gamma sRGB profile as both the input and the output profile, and choose one of RT’s larger RGB working spaces such as Rec2020 or ProPhotoRGB, to avoid clipping from whatever. This works because the color gamut of an sRGB profile from disk is smaller than the color gamut of any of RT’s built-in RGB working spaces, except possibly the RT sRGB color space.
The problem with the “yellow flower” raw file is that my custom camera matrix input profile interprets the yellow as outside the color gamut defined by real colors, colors seen by the standard observer. The dcraw standard matrix and the RT automatched DCP also interpret the yellow as outside the color gamut defined by real colors. But the channel detail captured by the camera is still valid detail.
This same problem happens with deep saturated violet blues such as blue neon signs or backlit blue glass, except it’s the red and green channels that get clipped to black. And the problem with violet blue is a bit more extreme as not only are one or two channel values less than zero, but also the LAB Lightness can be less than zero.
If they might be useful, I have sample raw files exhibiting the “bright saturated yellows and yellow greens” problem and also exhibiting the “dark saturated violet-blues” problem from my Canon 400D/Rebel xti camera, and also from my Sony A7 camera.
One solution to the “outside the realm of visible/real colors” problem is to make and use a custom camera input profile that’s a LAB LUT profile. But this creates a new set of problems: Colors resulting from using a LAB LUT input profile tend to be anemic (at least the ones I’ve made using ArgyllCMS produce anemic colors); LAB LUT profiles clip colors with channel values greater than 1.0; and commercially available target charts don’t have enough sample points to make a decent LUT profile.
My own solution for bringing “out of visible gamut” yellows, yellow greens, and blue-violets back into gamut for color output is to output the raw file to disk in my matrix custom camera input profile, make a copy, assign my custom LUT profile to the copy and then convert the copy to my custom matrix camera input profile, pull both images into the same layer stack, and blend using a layer mask. This can be done using output from current RawTherapee, but it does require using the “linear gamma sRGB as input and output profile” work-around.
As far as I know, which isn’t very far, the range of colors on which CIECAM02 was “built” isn’t that great. So for using CIECAM it’s better to have already brought all colors into the gamut of a color space that doesn’t include imaginary colors (which rules out camera input profiles). Personally I don’t have any qualms about the CIECAM02 module not handling out of gamut (channel values less than 0.0) colors or HDR colors. At least in my own workflow, when I use the RT CIECAM02 module, the image already has only “display range” RGB channel values, in a standard RGB working space.
As an aside, in theory can CIECAM02 be extended to handle “HDR but real” colors?
Edit: I did compile the unbounded code this morning, and confirmed that the issues mentioned above regarding dealing with “imaginary” colors produced by camera input profiles, still obtains with the new code, which of course would be the case as the issue precisely is clipping of negative channel values.