Chromatic adaptation
Curiously, you may have noticed that I haven’t talked about this (or very little). There are several reasons for this:
- Some software programs use this tool (along with other adjustments, of course) under the term « White-Balance », which for the user can lead to some confusion with Rawtherapee’s vocabulary.
- The “Chromatic adaptation/Cat16” slider in Local adjustments is not there to perform an operation of the type mentioned in this previous paragraph, but to slightly adapt colorimetry (warm up / cool down) if necessary.
On the other hand, this tool (Chromatic Adaptation) may prove indispensable in Rawtherapee, in particular for either :
- To cool or warm the image in a controlled way, starting from the white balance datas: temperature and tint (green).
- To adapt the system to the output device: TV, projector, monitor… In this case, we recommend using the main Ciecam module in “Advanced tab” - “Color Appearance & Lighting” and working in “Automatic Symmetric” mode - this is integrated into process 3 - Viewing conditions (Display).
Can Cam16 « Local adjustments » be used for high-dynamic images - Is Cam16 Scene-referred or Display-referred?
The answer is, of course, yes, for high-dynamic images (maybe no for the « old » Cam02).
Admittedly, Ciecam (here under the name Cam16) is a complex system, but at user level, with the choice of “Basic” complexity, specific settings are limited and straightforward.
It should be noted - and this may seem obvious - that beyond image dynamics, there are colorimetric aspects and the (personal) summary of what Ciecam is: “Trying to take into account by software, the physiological aspects due to the perception of the eye and the brain”.
Of course, nothing is perfect, and Ciecam cannot reproduce and improve every situation, but in the majority of cases, its contribution is significant.
As I’ve mentioned in other tutorials, Ciecam requires 6 variables - unlike RGB, XYZ or Lab, which use 3 variables: Lightness (J), Brightness (Q), Chroma (C), Saturation (s), Colorfulness (M) , Hue (h).
These 6 variables are updated throughout the process, for each change in one of the variables. This means that if you want to make internal function calls to calculate or modify the Dynamic Range (for example), you need to manipulate 6-dimensional variables. No personal computer - to date - is capable of doing this easily and quickly. I’ve tried to get around this obstacle, without success.
As explained in the tutorials, I’ve decided to “take out” the algorithms for dynamics processing, and then “leave the hand” to Cam16.
See tutorials :
https://discuss.pixls.us/t/paris-olympic-games-pont-alexandre-iii-tutorial/41895
https://discuss.pixls.us/t/another-tutorial-color-appearance-truck-under-a-tunnel/41947
And as a reminder parts 1 and 2 of “Scene-reffered and Display-reffered”:
https://discuss.pixls.us/t/scene-reffered-and-display-reffered-part-1/42076
https://discuss.pixls.us/t/scene-reffered-and-display-reffered-part-2/42087
In terms of results, I’m attaching an image processed with the Cam16 module. I used several sliders (which are actually curves) to force the use of Ciecam: Brightness (Q), Contrast (Q), Colorfulness (M) with relatively high values.
- No artefacts, no out-of-gamut colors, no blatant color drift;
- The “past” Dynamic Range (DR) corresponds roughly to 25 or 26Ev by calculation, and around 25Ev visually, including almost +15Ev in positive values, which corresponds to very high luminance values, well over 50000cd/m² (an affordable HDR monitor passes just 500 cd/m² - some very rare ones reach 5000cd/m2), and a standard SDR monitor around 120 to 200cd/m²).
- Of course, I used several “upstream” settings (Log encoding, gamma, Smooth highlights…) to achieve this result.
- As a reminder, today’s best cameras pass 15 to 16 Ev at best. And when we combine images with HDR software, we arrive at values of around 20 Ev or more, or less.
- So there’s no problem using this “Cam16” module on high-dynamic images.
- If I had to choose one tool among all those in Local Adjustments, this is the one I would choose.
Is it Scene-referred or Display-referred ? It is at least both.
TIF File : Sweep_sRGB_Linear_Half_Zip.tif (23.9 MB)
What about using Lab?
Lab was originally conceived, almost 50 years ago, as an easy way of measuring color differences (deltaE). Its use has spread far beyond this concept, and has become a standard.
I’ve chosen to use Lab as a support for Local Adjustments, as it easily takes into account deltaE, which is the basis of “Local Adjustments - LA”.
Within “LA”, depending on the module, we use Lab, RGB, XYZ, Ciecam conversions and their reciprocals, of course.
I didn’t notice any losses, apart from tiny differences due to 32-bit or 64-bit calculations, which are totally invisible.
Lab is sometimes criticized for a number of things:
- Low dynamic range: this is true in 8-bit mode, but (and this is not specific to Rawtherapee) it only concerns screen output, especially with LCMS-driven ICC profiles. In 32-bit mode, Lab easily passes the test, passing at least 25Ev . Example: https://rawpedia.rawtherapee.com/Local_Adjustments#Image_with_Local_Adjustments_-_Log_Encoding
- Color drift when luminance and/or saturation are changed. This is well known and pronounced for reds/oranges and blues/purples, and less so for other colors. Rawtherapee’s LUT-based correction (Munsell) avoids these drifts, making them almost imperceptible - the increase in processing time is very small.
- Lack of gamut control: in Lab mode, it’s “easy” to increase the luminance and chromaticity components. Whatever the working profile (Prophoto, Rec2020…), it’s easy to generate imaginary colors. Rawtherapee’s gamut control makes it easy to overcome this problem. The cost in terms of processing time is reasonable.
What color models are used in Rawtherapee?
- For all Raw data, either RGB or XYZ are used in linear mode, with no (or exceptional) use of curves or other model.
- One important exception, in the “Exposure” module for Raw images, is the use of the “Auto-matched Tone Curve”. This curve allows the Raw image to have the appearance of the JPG Camera… This is a considerable plus, but it sometimes brings in out-of-bounds data (gamut) that will need to be processed.
- The part where user actions are clearly visible, “Lab adjustments”, “Exposure”, “Shadows/highlights”, etc., often associated with curves, are generally in Lab or RGB mode, sometimes HSV…and in Ciecam mode.
- As previously mentioned, the « Local Adjustments » module is basically in Lab mode, with RGB, XYZ, Ciecam… conversions.
- Linking all these modules and tools in the pipeline does not lead to any noticeable reduction in dynamic range, or color drift in general.
What’s missing?
Of course, the user may wish for additional modules and tools that are more user-friendly, simpler and more ergonomic (GUI), but these are other problems.
We also need to reduce bugs and bad behavior.
But if we want to move towards the visible exploitation of high-dynamic images, we need a module to drive HDR peripherals (monitor, TV, projector, etc.) as « PQ », « Log Gamma », etc.
Today, the cost of these peripherals is high - a monitor with a peak luminance of over 3000cd/m² is exorbitantly expensive (more than 10000€). If someone wants to give it to me, they can send me a personal message so that I can give them the delivery address. 
Jacques
