Blue Channel "Noise" in Interpolated Raw Files

Converting interpolated raw files to ProPhotoRGB sometimes clips channel information

People who want to retain "all the colors" from their interpolated raw files often choose ProPhotoRGB as their output RGB working space. However, it turns out that converting interpolated raw files to ProPhotoRGB does sometimes clip channel information.

Upon conversion to ProPhotoRGB, a very yellow flower lost its blue channel detail

I was comparing the color gamuts of standard RGB working spaces (specifically sRGB, AdobeRGB, BetaRGB, and ProPhotoRGB) to the color gamuts of interpolated raw files of flowers, berries, and other colorful natural objects, when I noticed something odd. After raw rendering an image, assigning a custom camera input profile, and then converting to ProPhotoRGB, some images lost their blue channel details.

Here's the first and most extreme example that I have found:

Above: a very yellow flower.

On the left: the flower's blue channel after applying the custom camera input profile. On the right: the blue channel after converting the image to ProPhotoRGB.

Other colors also lost information in the blue channel after conversion to ProPhotoRGB

It wasn't just saturated bright yellows that were affected by this problem of blue channel detail being replaced by ugly pitting after conversion to ProPhotoRGB. Images with other colors also had holes in the blue channel after converting to ProPhotoRGB.

Above: Green lettuce and red tomatoes.

A crop (the red box to the right) from the blue channel of the custom camera input profile (above) shows there is little to none of the black pitting "noise" typically encountered in blue channels.

A crop (the red box to the right) from the blue channel after conversion to ProPhotoRGB (above) has black pits all over the lettuce leaf shadow areas (not just in the red box), and also in the tomatoes.

The pixel-peeping crops from the red boxes outlined in the lettuce and tomatoes images show that the very small dark areas in the blue channel of the custom working space become big black pits when the image is converted to ProPhotoRGB. The two crops were both levels-adjusted 'input 255' to 'input 64' to better reveal where the respective crops have gone to solid black in the blue channel.

If you are not convinced yet, here's a green leaf that has plenty of information in the blue channel after applying the camera input profile. Yet that information was almost completely lost upon conversion to ProPhotoRGB:

The more I looked, the more I found that black pitting in the blue channel is often not really "noise" but rather missing information, lost during the conversion from the camera input profile to the ProPhotoRGB working space. To check your own raw files for "noise" that's actually missing channel information, you do need to use a raw processor that allows you to output a linear gamma raw color image such as might be used for making a custom camera input profile. DarkTable, dcraw, Photivo, Rawstudio, RawTherapee, and UFRaw all can output raw color images:

• RawTherapee provides a "Save Reference Image for Profiling" button, which results in raw color output.
• dcraw outputs linear gamma raw color when you use the "-o 0 -g 1 1 -4 -T" switches.
• DarkTable, Photivo, Rawstudio and UFRaw all allow you to disable all enhancement algorithms and assign sRGB as the input and output profile. A conversion from sRGB to sRGB is a null conversion. So as long as all image enhancing algorithms are disabled, the resulting output is raw color.

Upon opening a raw color image with an image editor, the first step is to assign an appropriate custom camera input ICC profile. ArgyllCMS plus an IT8 or other target chart can be used to make custom camera input profiles, and a suitably made ArgyllCMS simple linear gamma matrix profile can actually be used as an RGB working space.

Is channel information lost to clipping useful?

If you only output color images and you never use individual channel information in your digital darkroom, perhaps the information lost to clipping wouldn't be of much use to you. However, if you work with individual channel information — to output black and white images or perhaps to alter an image's tonality by using the blue channel as a blending layer — then yes, you are limiting your creative options if you allow your raw rendering software to throw away your blue channel information by automatically converting your image to one of the standard ICC profile working spaces, even if that working space is the very large ProPhotoRGB working space. Here's one small example:

Above: A bright but bland yellow flower (left) has surprisingly nice blue channel details (right).

Left: After converting the yellow flower to a suitably large working space, I used its fully detailed blue channel as a blending layer to produce this reasonably pleasing black and white rendition; the petal detail is nice but alas the central cone is out of focus. Right: Converting to ProPhoto before retrieving the blue channel information reduces most of the blue channel to solid black, which would have made the black and white rendition to the left entirely impossible.

Why converting interpolated raw files to ProPhotoRGB sometimes clips channel information

Compared to the ProPhotoRGB color gamut, the color gamuts of camera matrix input profiles have radically different sizes and shapes, with Green and Blue colorants that are far away from the corresponding ProPhotoRGB colorants. As an example, the following figure shows the ProPhotoRGB colorant xy values, compared to the colorant xy values of my Canon 400D custom camera matrix input profile. It also shows the xy locations of some of the brighter, more saturated yellows in the very yellow flower from Section A above:

The Argyllcms profcheck utility shows that my custom camera matrix input profiles for my two cameras, a Canon 400D and a Sony A7, both slightly increase saturation in already very saturated yellows. Based on perusing the ArgyllCMS mailing list archives and also on custom camera input profiles that I've made for a small sampling of other people's cameras, the same thing is true of custom camera matrix input profiles for other camera makes and models.

With the default Adobe camera matrix profile that's embedded in the DCP profile and also can be found in the dcraw code in the adobe_coeff table (this table and the accompanying code is used by many raw processors to make camera input profiles), the problem of slightly over-saturated yellows still exists but affects fewer images simply because the Adobe camera matrix profile produces somewhat anemic colors (desatured by design?). In fact that's how I discovered the problem in the first place — I was comparing UFRaw and Adobe Camera Raw output for the very yellow flower raw file, back before I had made the switch to an entirely "free/libre software" workflow.

In an interesting thread discussing Viable alternatives to Photoshop, a photographer on the Cambridge in Colour forum made note of this problem of yellows that are clipped in the blue channel when using ACR:

I'm using a yellow flower shot presently (flowers are hard on conversion algorithms). [The Sigma Photo Pro work flow] is currently ahead [of the ACR workflow] mainly due to the ACR converter's nasty habit of clipping the blue part of the yellows to zero while decoding raw data into it's working space. The blues come up clipped in Sigma Photo Pro too, but can be fixed by reducing the saturation - the main point being that Sigma Photo Pro actually re-does the conversion whenever a slider is changed - ACR 5.4 does not, as far as I can see.

Given that my custom camera input profile does add saturation to already saturated yellows, it's not too surprising that the "very yellow" colors in the very yellow flower are actually imaginary colors, falling outside the locus of visible colors. Regardless of whether the colors are real or imaginary, the channel detail is real and converting to ProPhotoRGB destroys the blue channel detail that was captured by the camera.

A camera-based RGB working space for editing interpolated raw files

There are several ways to avoid the problem of colors that are clipped upon converstion to ProPhotoRGB:

1. You can desaturate images with out of gamut colors before converting them to ProPhotoRGB. For most camera input profiles, doing this requires converting the images from the camera input profile to an RGB working space that's large enough to hold the image colors that would be clipped by converting the image to ProPhotoRGB.
2. If the goal is a black and white rendering, you can retrieve the channel information as layers, again before converting the image to ProPhotoRGB. One way to do this is to output raw color. If you have a custom camera matrix input profile, open the raw color image, apply the camera input profile, retrieve the channel information as a layer stack, and then convert the layer stack to whatever RGB working space you desire. If the input profile and your chosen RGB working space have the same TRC (for example, both are linear gamma profiles), the channel layers remain untouched.
3. You can use ArgyllCMS to make a custom camera LookUp Table ("LUT") input profile, as LUT profiles can be made with very small deltas, thus mitigating the problem of potentially imaginary colors.
4. You can cut the Gordian knot altogether: Use ArgyllCMS to make yourself a custom camera matrix input profile that's also a well-behaved RGB working space, thus avoiding any reason to convert the image to ProPhotoRGB for editing.

In case you are wondering, using CIELAB to desaturate the image is not an option because the conversion from the camera input profile to CIELAB likewise will clip some of the saturated colors that you would like to desaturate. Also, for most and probably all raw processors, by the time you have an option to convert to CIELAB, the image has already been converted to an RGB working space.

Unfortunately none of four alternatives listed above is available when using DCP ("Dng Camera Profile") profiles because by definition DCP processing converts the image from the Adobe (or custom, if you've made a custom DCP profile) camera-specific input matrix profile embedded in the DCP profile, to ProPhotoRGB, whereupon a LookUp Table transformation is applied to the resulting ProPhotoRGB channel values.

Only the third alternative, using a custom camera LUT input profile, is available when using raw processors such as RawTherapee that push all images through some predetermined RGB working space, except, of course, when outputting raw color. However:

1. Even with a low-delta LUT input profile, some colors are still going to be out of gamut with respect to the ProPhotoRGB color space, resulting in clipped channel values. And the lower the delta (deviation from the expected XYZ values for the colors in the target chart shot), the more likely you've "over curve-fitted" the available target chart color patch data points.
2. Custom camera LUT input profiles are usually regarded as more suited to custom lighting situations, where you might make a new input profile every time the scene lighting changes. For general usage, a matrix input profile made under full spectrum lighting, preferably direct sunlight, is a better choice.

The fourth alternative — making and using a custom camera matrix input profile that's also a well-behaved RGB working space — has several advantages over automatically converting your image to some standard RGB working space such as ProPhotoRGB:

1. The procedure for making a well-behaved camera input profile actually produces a better camera input profile, even considered as just an input profile rather than as also a working space profile.
2. No matter how saturated the interpolated raw file colors are,when using the camera input profile as your RGB working space profile, by definition none of the colors are clipped. So the original channel information, exactly as captured by the camera, is always available for use as a blending layer, regardless of whether the finished image will be black and white or color.
3. The channel information hasn't been rearranged by a conversion to an RGB working space that has colorants that don't have any relationship to the colorants of the camera profile that was used to interpret the colors in the first place. This preservation of channel information allows you to make channel-based selections that sometimes are difficult or impossible after the conversion to a standard RGB working space has rearranged the channel data.
4. You can change the image white balance even after the image has been interpolated, with excellent results and contrary to the usual advice that you should always white balance the image during rather than after the raw file has been interpolated.
5. Many editing operations do give results that are chromaticity dependent. Chromaticity dependent means the results of the operation vary as the colorants of the RGB working space vary (keeping the profile tone reproduction curve constant, of course; and preferably using linear gamma profiles for radiometrically correct results). Sometimes the results are radically different, and especially if any colors were clipped by a conversion to a standard RGB working space such as ProPhotoRGB.

Nothing is free, and so there are also disadvantages to using a well behaved camera input matrix profile for editing your interpolated raw files:

1. Many raw processors, RawTherapee being a prime example, don't allow you to choose a custom RGB working space, even if they do allow you to output a raw color image. So whatever amazing editing algorithms these raw processors offer, you can't take advantage of them without first converting your image to one of the raw processor's built-in RGB working space.

   A RawTherapee-specific workaround is to assign a linear gamma sRGB profile from disk as the input and the output profile and choose the RawTherapee built-in ProPhotoRGB as the working space. Then do whatever noise reduction and etc that you want to do, save the image to disk, open it with some suitable image editor you prefer, and assign your custom camera input profile. The problem with this workaround, of course, is that you can't use what you see on your monitor as a guide to what the final image will look like.

2. Camera input matrix profiles are oddly shaped and have a high percentage of their color gamuts taken up by imaginary colors. So it's really easy to add too much saturation, either directly or as a result of a Curves or Levels operation, pushing real colors right out into the realm of imaginary colors. This same problem obtains with editing in the ProPhotoRGB working space as 13% of the ProPhotoRGB color gamut is imaginary. But it's even more of a problem with camera-based RGB working spaces.

Conclusion

Well, the conclusions are pretty obvious. You can convert your interpolated raw files to a standard RGB working space such as ProPhotoRGB and risk finding holes in your blue channel. Or you can make yourself a custom camera matrix input profile that's also a well-behaved RGB working space. In some cases it won't make much difference to your final image, no matter which RGB working space you use. In other cases the differences can be significant, and on occasion you may find yourself in editing situations where the only way you can get the results you want is by using a well behaved custom camera matrix input profile as your RGB working space.