LA Color Appearance Cam16 – improvments Sigmoid Q, Log encoding Q, mask: branch lacam16

[Desmis]

Purpose of this change – lacam16 branch Make the LA module "Color Appearance", for the moment for its part Cam16, more efficient (the last important modifications date from summer and autumn 2021):

• especially for difficult images (strong dynamics, deep shadows, etc.) by optimizing the processes already in place, Log Encoding Q, and Sigmoid Q;
• by allowing the masks of this module, an extension to all the attributes possible to date.
• later extend, if necessary, some of these improvements to JzCzHz and the Log Encoding module

Two major difficulties: 1. Cam16 and the 6 dimensions A point of programming is necessary to understand certain difficulties and constraints of working with Cam16 (it is identical with Cam02). During the development of Ciecam, around 2011, 2012, it quickly became apparent that unlike working in RGB, XYZ, or Lab* mode which requires declarations of 3-dimensional variables, Ciecam requires 6 dimensions: J luminance, Q brightness, C chromaticity, S saturation, M colorfullness, h hue. This implies a considerable memory occupation and significant processing times. The choice was made to use these variables one by one and sequentially in a global loop, which limits the memory occupation, but has a major drawback: the optimization of a procedure called in the middle of the loop is almost impossible. As a result, optimizations of functions such as contrast, sigmoid, etc. are limited and global.

2. Peculiarities of Q

• By design Q (brightness) unlike J (lightness), L (Lab), and luminance calculations in RGB, HSV,... mode is calculated from absolute luminance and does not has no fixed limits (0..1, 0..65535). It is an 'open' variable.
• Q (when J is in the range [0, 1]) can reach values of 5 or 10, depending on scene conditions. This reality is a very strong constraint on the calculations of the references of the algorithms (average, thresholds, etc.) and makes it difficult to automate/optimize the algorithms.
• but Q results in a majority of cases, in a more natural rendering, closer to human perception.

Constraints that I imposed on myself

• avoid compatibility breaks with version 5.9, especially at the GUI level;
• reduce tweaks needed to make Sigmoid Q, and Log encoding Q work properly;
• propose a possibility to combine Sigmoid Q and Log Encoding Q;
• and of course try to get good results with the default settings, which is no small feat.

General principle

• improvement of the functioning of Log encoding Q (which can also be used for Sigmoid Q), in particular by taking inspiration from a function implemented in ART by Alberto - use of 'tanh' which looks like a Sigmoid - which he has had to adapt to "open" variables
• evaluate the luminance of the image before and after Cam16, in particular to take into account Sigmoid Q and Log encoding Q, by taking into account the mean and the variance before and after.
• minimize the impact on the GUI, both to preserve compatibility with 5.9 and to facilitate learning. Of course, this can be changed if necessary.
• The main actions to adjust the image in 'Sigmoid Q and Log encoding Q' or 'Log encoding Q' is the couple 'Brightness compression' and 'Compression threshold'

Summary Reminder

• as already mentioned Lab* (when using reals) is not a constraint for the 'dynamic range', except that it makes it difficult, but not impossible, to exploit HDR highlights.
• Cam16 is an excellent color management module allowing the simultaneous use of the notions of 'Source', 'Viewing conditions', 'Chromatic adaptation', 'Lightness and Brightness', 'Chromaticity, Saturation, Colorfullness'… and many others.
• integration with LA, in particular in 'Full-image' mode, allows the use of deltaE (not exhaustive). Depending on the images, by moving the Rt-Spot by a few pixels, we obtain different images, particularly in the distribution of shadows and lights… and of course colors.
• Sigmoid, Log encoding, or other available processing (wavelets, equalizer, etc.) are not the philosopher's stone. These treatments are to be used and dated on a case-by-case basis.

Provisional documentation in French is available (paragraphs marked « lacam16 » - 3.4 Utilisation de Cam16 et des fonctionnalités HDR). I do not provide 'test' images, there are enough on the forums... Depending on the case, you can use this module alone, or associated with other LA modules (equalizer, tone mapping, wavelets... ), or 'Abstract Profiles', etc.

Happy New Year to all.

And excuse my bad english.

Jacques

[Desmis]

Hello all

For those who are interested ... I made several improvements. https://github.com/Beep6581/RawTherapee/tree/lacam16

In fact, it's quite "curious" to see the lack of reactions on RT, of algorithms "similar" to those of DT which enthrall readers (of course you can tell me that my thing is less good, too complicated... ).

Jacques

[Desmis]

Some additional information: Optimizing the system so that the default settings are suitable in a majority of cases is a (very difficult) self-imposed constraint.

Reminder:

• using Brighness (instead of RGB luminance) is a high challenge because Brightness in Cam16 is not bounded and varies considerably from image to image and from setting to setting
• moreover the additional or existing sliders cannot be translated internally (code) by the same settings because of Cam (blackEv, WhiteEv, DR, Brightness compression, threshold compression, etc.)

I wanted to keep the settings in "Basic" mode to a minimum. The "advanced" mode allows access to advanced settings, which should only be optional.

I added a module upstream of Cam16, but in the "Color appearance (Cam16 & JzCzHz)" module, which is inspired by "Abstract profile" but simplified:

• a TRC - gamma and slope that allows to unblur shadows and change light tones: as a reminder on a very long debate 2 years ago, a Tone-curve will have a lot of difficulties to do the same thing.
• the possibility to set up " Primary Destinations " (simplified) which allows to restore the color dynamics of the image - taking care of the excesses.
• a chromatic adaptation of the XYZ conversion matrix (not to be confused with the chromatic adaptation of the white balance - Cam16 - Ciecam).

This module has principles (in terms of results and language) to Filmic or Sigmoid or new color management in DT. But the code, its principles have a very limited relationship with DT... This does not mean that it is better or worse... It is different.

jacques