Local adjustments - Cam16 and Log encoding improvments

I have been waiting for 5.10 to start evaluating this new version. However, if this lasts too long, this evaluation could begin now.

This page is a copy of that of the PR.

Main changes brought by this PR

The changes affect 2 LA modules:

  • Log encoding
  • Color Appearance – only Cam16

For the 2 modules I introduced:

  • the notion of “whites distribution” and “blacks distribution” that allows you, in Automatic, when the dynamic range (DR) of the image is high, to change the distribution of lights in whites and deep blacks. Can be used with Log encoding or Sigmoid with Black Ev and White Ev enabled. The algorithm does not change the basic data, but acts on the components necessary to calculate the Dynamic range, Black Ev, White Ev and the Gray point
  • the notion of “Brighness compression” (partly inspired by ART). This concept is simple to implement in “Log encoding” because the data used to calculate the DR and that used in the code are the same. This is not the case with Cam16. Indeed, on the one hand, when we use “absolute luminance” the data are not limited, and on the other hand Cam16 modifies the distribution of tones in particular the “Gray point” necessary for the calculations.

In the case of Cam16, I introduced the notion of “Sigmoid Q” - already present in previous versions - but which now works significantly better (at least I think so).

  • this addition of Sigmoid in Cam16 was in no way a necessity, because the Cam16 tools (brightness, lightness, contrast J and Q, curves, etc.) make it possible to deal with the situations. Rather, it should be seen as a personal challenge – the code is simple.
  • the improvement lies in the evaluation of the inflection point which cannot be a simple interpolation. These problems are due to 2 difficulties :
    ** the code can hardly be called again, because it implements 6 dimensional variables.
    ** in principle the absolute luminance values are variable.

I also added upstream of Cam16 an ultra-simplified “abstract profile” module allowing before Cam16 to modify, if necessary, the distribution of shadows and lights (TRC) and the primaries.

I also revised the GUI to make it more consistent, notably by including Sigmoid and Log encoding in Cam16 image adjustments.

Additionally, mask contains more tools.

Note that the notions of “scene conditions (reference)” and “viewing conditions (display)” have been present in RT for more than 12 years.

jacques

3 Likes

Just a quick post. Firstly i find the TRC “abstract profile” in cam16 very useful. It’s good to have this feature in the cam module. Makes for adjusting DR much easier. I previously often used the abstract profile in conjuction with cam16 but it was bad ui to have to go all the way down in the colour management tab, where the option is also quite hidden.

I have also played around a bit with the “Brightness compression” which will probably be useful. I haven’t edited any real things with it yet but the effect is nice.

1 Like

I just added a functionality, still upstream of Ciecam.

Until now the “TRC” checkbox allowed you to act on the tones, but also a very simplified version of ‘Abstract profile’ with only the choice of primaries (remembering that the working profile is not changed).

Now you can act on each of the components of the primaries : Red X , Red Y, Green X, Green Y, Blue X, Blue Y.
I did not choose the possibility of modifying the white point, nor a gamut control, nor having a graphical interface acting on the CIExy diagram (of course, it must be possible to do so).

This addition, in “advanced” mode only, allows you to use LA functionalities (transitions, deltaE) either on the entire image, or locally for example to modify the gamut of flowers.

The functionalities are essentially the same as ‘Abstract profile’ in ‘Color Management’.

https://rawpedia.rawtherapee.com/Color_Management#Abstract_Profiles

jacques

1 Like

I updated the “lacam16n” branch. Now the functionalities of “TRC & primaries” are almost similar to those of “Abstract profiles” with less of the default automations, and simplified GUI.

You can modify the white point with possible values : D41, D50, D55, D60, D65, D80, stdA

You can choose the primaries with possible values : Prophoto (default), Beta RGB (which best corresponds to human vision), WhiteGamut, ACesP1, REc2020, AdobeRGB, sRGB, JDCMax.

You can personalize primaries and white point with the choice “Custom LA (sliders)” and of course TRC (gamma and slope).

A checkbox allows Gamut control (XYZ), and you can choose the “Matrix adaptation” between ‘Bradford’, ‘Cat16’, ‘Cat02’, ‘Von Kries’, ‘XYZ scale’.

The CIExy diagram display allows you to see the changes of the 3 primaries and the white point.

As a reminder, during the development at the beginning of 2021, “Abstract Profile” did not receive an enthusiastic reception (to put it mildly), perhaps through incomprehension… However, it is interesting to see other software venture towards the primary track. Remember that an ICC profile generally has 3 components: primaries, white point and TRC (Tone Response Curve).

Reminder: use with LA allows you to personalize these 3 components, for example for a sky, a flower, without touching (if desired) the background.

The rest of Cam16 is unchanged (at the level of this branch) and has taken as a principle for a long time the notions of “Scene conditions / reference” and “Viewing / display conditions / reference”.

I just made 2 modifications for Cam16

  • The first concerns the “Log encoding” method. I have been trying for 2 years to make Log encoding work with Q (brightness Ciecam). But faced with the complexity and mixed results, I moved this module to the ‘upstream’ part of Ciecam which is much simpler (it works in RGB mode)
  • the second is the addition of gamma and slope with the possibility of adjusting the midtones upstream of Ciecam

In summary, you have a module integrated into the Cam16 GUI, which allows you to act just before Ciecam and retouch the image so that it is easily modifiable by Ciecam: Dynamic Range, Tones, RGB primaries.

I called it “Pre Ciecam”

To facilitate the evaluation of this PR, I have activated the provision of “Pre-dev builds” for Appimage and Windows. You thus have the executables without needing to compile

Thanks to @Lawrence37

https://github.com/Beep6581/RawTherapee/releases/tag/pre-dev-github-actions

A possible example of use

Today 17-12
I updated the GUI with an Expander which replaces the Frame and the checkbox. This seems more “clean” to me.

I also “merged” with the main branch (dev) and cleaned up the GUI code a bit.
Same link for the pre-dev build

1 Like

I improve Sigmoid Cam16

1 Like

I made new changes to the PR regarding the “lacam16n” branch.
https://github.com/Beep6581/RawTherapee/pull/6861

Executables:
https://github.com/Beep6581/RawTherapee/releases/tag/pre-dev-github-actions

These changes concern the “Pre-ciecam” module of “LA Cam16” and its equivalent in “Abstract profile”.
I also added a new “working profile” “JDCmax stdA” which has the same primaries as JDCmax, but a white point moved from D50 to stdA.

You will find in the 2 modules associated with the primaries:

  • a gamut control, which is particularly useful for significant changes in primaries.
  • a chromatic adaptation which may be necessary when changing primaries with the choice between Bradford, Cat16, Cat02, Von Kries, XYZ scale
  • a “Refinement color” which acts on what some call “purity”, on the gap between the white point and the colors. I voluntarily left the maximum action possible even if it is not always necessary.
    We find some of these similar principles in ART 1.21 and in Darktable where debates took place.

One of the differences is that RT acts on the XY coordinates of the CIExy diagram (Rx Ry, Gx, Gy, Bx, By) accompanied by visibility on the CIExy diagram as well as the white point, while the others cited use coordinates polar (rotation, attenuation).
Other differences are linked to the design, in RT you can also act on the TRC (Tone response Curve) and the illuminant (stdA, D50, D65, etc.).

1 Like

Hello

I made various improvements to this PR (lacam16n branch), both in terms of:

  • GUI by preventing (hopefully) bad behavior in certain situations
  • for “Pre-ciecam” by adding some features (shift x and shift y in CIE xy diagram)
  • by improving the behavior in the case of images with very high dynamics, both for “Log encoding” and “Cam16” (in this case the result is a little different). Note I added 2 controls - White and black distribution"
  • ensuring compatibility with “Abstract profiles”
  • others small changes.

Example with “Log encoding” in “Local adjustments”
https://discuss.pixls.us/t/who-is-familiar-with-log-tone-mapping-in-art/41339/36
Executables
https://github.com/Beep6581/RawTherapee/releases/tag/pre-dev-github-actions

Jacques

3 Likes

Hello
Now, without changing the functionality, the GUI interface for Cam16 is simpler and more intuitive.

Thanks to @Wayne_Sutton for his advice

Jacques

3 Likes

That’s a very good improvement!

I noticed a thing or two about the log encoding checkbox (source data adjustments) though.

  1. The checkbox has an effect even when the Source Data Adjustments power button is off. I would expect the power button to disable everything in it’s scope.
  2. The effect, always visible when log encoding is checked, is different with or without the power button on.
  3. A very minor thing but In basic mode the brightness compression setting is hidden leaving the log encoding checkbox in an odd looking state sitting on a frame with nothing in it.

@nosle

Thank you very much for testing.

You are true…I think with the change now, all must be fine.

I change also others things, as sensibility of white distribution, and behavior when scope=100.

Executable are in progress

Thank you again.

Jacques