News from Cam16 - A processing challenge is coming up

Software RawTherapee
1

Hello

I’ve just made a series of changes to the “lacam16n” branch. They are of 2 types.

Techniques:

  • As I’ve said several times, Ciecam is very powerful in colorimetry (I won’t go into detail about its features, which are explained in several posts and tutorials), but it’s very difficult to integrate complex “external” functions into the 6 variables used (Lightness, Brighness, Saturation, Chroma, Colorfullness, hue).
  • That’s why the “Source Data Adjustments” module was added - with global processes, located before Ciecam. These included: Log encoding (RGB), Tone Response Curve & Midtones, Primaries & Illuminants.
  • In the middle of the Ciecam code, I managed to set up a call to 2 functions familiar to users, but which have the particularity of using only the Q (Brightness) variable, instead of RGB :
    ** “Log encoding Q”, which - compared to its “brother” in RGB mode - will require more attention to settings, but will be more respectful of colorimetry overall.
    ** “Sigmoid Q” , which isn’t aimed at processing high-DR images, but rather at making them easier to use than curves and sliders.

User interface (GUI);
In “Basic” mode, the aim is to provide the simplest possible interface, with the minimum number of settings to resolve 90% of the most common cases.
Advanced" mode, on the other hand, offers full functionality, but with numerous settings and a less-than-readable interface. You can’t have everything.

In summary, the “Basic” mode:

  • “Scene conditions” is reduced to 2 to 4 settings, with “automatic” mode by default.
  • “Source Data Adjustments” includes only “Tone Response Curves & Midtones”. This module, combined with “Surround” (scene conditions), handles 95% of difficult images (high DR, deep shadows, etc.).
  • “Cam16 Image Adjustments” includes only the bare essentials: Lightness (J), Local Contrast, Contrast (J), Saturation (s), Red & Skin tones protection.

As you can see, there’s no “Log encoding”, no adjustment of Ev (Black , Whites,…), no Sigmoid, no Graduated Filter, no masks, and so on.

Of course, if you select “Standard” and a fortiori “Advanced”, you’ll have access to more and more settings and algorithms.

I’d like this module to be validated by users before being merged into the current application (Dev). This will be the subject of a processing challenge, which I’ll present shortly.

Thanks in advance.

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

Jacques

1 Like
2

Confirmed ! :wink:

I noticed twice a little bug, see attachment. The lighter part disappears when zooming in or out, but after saving the photo it’s still there.

DSC_8478_1800px
DSC_8478_1800px1800×1192 226 KB

DSC_8478.jpg.out.pp3 (19.5 KB)

3

Hello Paul

Thank you for testing.
(c’est sympa de te retrouver :wink:)

I upload your pp3

Yes, there is a bad behavior, but it must be old and on old versions at least 2 years ago(to be checked).

You tried with “Jzczhz” as your choice, it’s a really experimental branch, but which is not concerned by this evaluation. I haven’t changed anything in this part (Jz), but perhaps a side effect, because the GUI is common (plus ZCam, not displayed)

What I want to validate is “Cam16”.

I will have to confirm in the future processing challenge which has not yet started.
You’re like Lucky Luke, faster than your shadow :grinning:

However I will check…

Thank you again.

Jacques

4

I tested with “dev”, no problem.

It’s definitely a side effect. In Jz, (lacam16n) the Cam16 module is “also” activated… Which is not normal.

But it is a big “bug”… mix code…
Realy, a very big bug…But only if you activated Jz…

Thank you

Jacques

5

Paul

I just pushed a change, to 99% of the GUI… There was indeed a possible “mixture” of the 2 codes.
In my “defense”, the GUI code is complex, due to the fact that I maintained the possibility of using Zcam, which is neutralized. Researcher’s work, not at all up to date.

Be careful, you have to put it back to “neutral”…
In any case, thank you very much for finding this anomaly, there is someone who would have tried… and found it like you.

I hope I fixed everything.

Merci, à toi, pour avoir trouvé cette grosse anomalie

Jacques

6

Salut Jacques,

The anomaly seems to be gone now.

Two things.

When I open the module ‘Recovery based on luminance mask’ it says Mask disabled (Mask & modifications). I have to open that last one to enable the mask. That wasn’t clear to me at first glance. Shouldn’t the Recovery module be placed after Mask and modifications?

Source Data Adjustments. Enabling Log encoding and Log encoding Q results in a white image without any details. Is that intentional?

Regards, Paul.

7

Salut Paul

Merci pour ta validation.
I’m going to push a change with a “cleanup” of the code by removing all references to ZCam… which doesn’t work (or I have poorly adapted the work of the researchers). This will lighten the code and make it clearer - hopefully I don’t do anything stupid. :smiling_face_with_tear:

In all the tools (Color and light, Denoise, etc.), it’s in the same place… before mask. This seemed more logical to me, because the mask menu is cumbersome. They will tell me that this must be made automatic…(or another thing…)

Your remark on “Log encoding” clearly shows that this tool is capricious, it depends on each image…In some cases the image without any adjustment will be almost black or in other cases almost white, or in other cases it will be difficult to obtain a correct result, or for certain images it works perfectly with few adjustments .
But it’s a “fashion” :wink: I put it, because it is found elsewhere and there are people who believe (not me) that there is only this tool to process DR images. The code is simple and only has a few lines.
You will say that other software for the image that concerns you, comes out better… there is also the opposite. It depends in particular on how we calculate Mean luminance -Yb - (ciecam vocabulary), the gray point for others, and how everyone has designed their positioning and amplification.

Look at the behavior of the various tools (all in Local adjustments) to deal with the Dynamic Range:
https://rawpedia.rawtherapee.com/Local_Adjustments#An_evaluation_of_the_dynamic-range_capabilities_of_tools_in_the_%E2%80%9Clacam16%E2%80%9D_development_branch

Hence my position of putting it in “advanced”…For me, from a personal point of view, it is a difficult system to master, like all “log” tools, whatever their name. On the other hand, it is the only one that allows processing images with a DR greater than 20 Ev. No camera is capable of providing this (at best it is 15 Ev).

When I proposed the TRC (Tone Response Curve) 3 or 4 years ago… we found this tool “curious” - to say the least - what a weird idea - (and it is curious that it is not in the other software, if not at the margin).
The code (in my opinion) seems weird, especially when we say we’re creating a virtual ICC profile inside the code that modifies the data.
But it works in almost all cases (to be verified) and is quite intuitive, and of course we can associate it to change the primaries and illuminants (in advanced mode).

Merci.

Bonne journée

Jacques

8

I pushed the change to remove Zcam (big change). I hope I didn’t do anything stupid

Jacques

9

OK. then I suggest to change the line
Mask disabled (Mask & modifications) in
Mask disabled (Enable in Mask & modifications), for clarity.

10

These are easy changes to make, I do it right away

I just push this change.

Jacques

11

I tried it to raise the shadows on that shot and it worked pretty well, I found the controls to be pretty intuitive too. Comparing to just raising the shadows with Shadows/Highlights I think it does a better job preserving local contrast and colors, although the difference is not huge.

before
before1611×1368 2.05 MB

after
after1603×1368 2.63 MB

1 Like
12

@jdc
There is a big difference in change from going from slope 0.99 to slope 1.00:
Slope 0.99:

Slope 099
Slope 0992807×1698 351 KB

Slope 1.00:
Slope 100
Slope 1002777×1652 267 KB

13

@arturoisilvia

This is a known, almost insoluble dysfunction (If this is one ?), when I presented this in 2020, this is one of the (first) things that was stated. I think (to verify) that it is in the documentation.

Indeed a profile with a slope=0 corresponds to gamma=2.2 (Adobe) or 1.8 (Prophoto), but the system does not recognize, when you want to connect a parabolic dish of power “n”, with a straight line of slope "s ", that the values starting from s=1. Below the equation is impossible to solve.

Either I start at 1, it’s very easy, but we won’t be able to do a pure gamma (by the way, why do it?), at least in this case (or by selection in a list… ). In other words, between 0 and 1 the behavior is erratic (except for the 2 limits)

1 Like
14

Hello

You can also use one of Ciecam’s special features, the “Surround” function.

Examine an image, activate Ciecam : either Color Appearance & Lighting - Tab advanced, or Color Appearance (Cam16). Don’t touch anything. Activate / deactivate. You’ll see the image brighten up a little. This is the “Surround” function. Hence the name “Color Appearance & Lighting”.

This function takes into account phisiological effects (eye-brain link), notably the Stevens effect.
https://rawpedia.rawtherapee.com/CIECAM02#Introduction_-_history

As the software has no intelligence, it can’t tell the difference between luminance differences between light and shadow due to shooting circumstances (bright center on dark background) or a lack of dynamic range.

So if you ask Cam16 to take into account a larger gap between highlights and shadows, it will. The system is complex and does not boil down to either a “log something” or a “shadow something”…
it tries to take into account :

  1. what you ask it to do;
  2. absolute luminance;
  3. achromatic response to white;
  4. complex equations based on the Cam16 conversion matrix and the notion of LMS
  5. other parameters

The algorithm will take these parameters into account and lighten the shadows by adjusting the colorimetry (saturation, chroma, colorfullnes, Lightness, Brightness , Hue).

You have 4 settings levels : Average (default), Dim, Dark, Extremely Dark.

You can find it in “Scene conditions”.
image

It couldn’t be simpler… Then, of course, you can (must) adjust the settings (local contrast, etc.) and noise (if any) with LA, and or complete with “Tone Response Curve & Midtones”

Note that there is a symmetrical “Surround” in Viewing conditions to adapt the image to the viewing environment.

Jacques

15

What does this mean?

I’m asking because I find adaptions (CA&L > Automatic symmetric > Illuminant, Local edit > Viewing conditions > Chromatic adaptation) have exaggerated impact on whites.

16

@nosle

I certainly should have avoided this technical term. Nowhere will you see it in the software.

This has nothing (or very little) to do with chromatic adaptation. This is part of the algorithm that ensures respect to color with reference to white and also for surround effect (and other effects).

This effect (surround here) takes into account in particular, 3 coefficients: f, c, nc. When you change in RT, “Surround” these values are for example for “Dim” : f=0.9, c=0.59, nc=0.9, for “ex Dark” f=0.8 c=0.41 nc=0.8, etc.

I attach a link to the old “Ciecam02” on Wikipedia, which is obviously a little different in Ciecam16, but which explains well what Ciecam does. It’s probably this link that I should have put and not my comment, which is a little incongruous.
https://en.wikipedia.org/wiki/CIECAM02

Excuse me for this jargon which does not add much, other than to say that it is very different, better or worse, it will be up to you users to evaluate, from Log encoding, Shadows/highlight systems, Tone Response curve, or other algorithms… the objective is not the same.

Once again my apologies for this mistake (of speaking about this) on my part :wink:

I complete this morning:
Some additions that are not written in Wikipedia. Some are choices I made for RT.

  • For “Absolute lumiance La”, I use exif datas (speed, aperture…)
  • Fo Yb - Mean luminance - I use same calculation (LA Cam16) that to find the gray point used to determine DR (data located just after demosaicing)
  • When we speak “white”, In LA Cam16, it is D50, in Color Appearance & Lighting, you can choose
  • In Color Appearance & lighting , there are 2 chromatic adaptation, the first between “Scene” and white, the second between white and “Viewing”. In LA Cam 16, only one.
  • Wikipedia does not mention that it takes 3 processes “Scene”, Image adjustments, “Viewing”…and all equations and matrix are inversed.
  • When the user changes something in “Image adjustments”, for example “Brightness”, systematically the 5 other basic data (Lightness, Saturation, Chroma, Colorfullness, Hue) are updated.

Jacques

1 Like
17

Hello

Thanks to Paul’s tests @paulmatth (thanks to him) I’ve made a few adaptations to the code, especially to the GUI, so that there’s no more interference between the “Cam16” and “JzCzHz” modules (I hope they’ve all disappeared).

Jz module
As a reminder, about 2 years ago I introduced the researchers’ work on “Jz”. At least in theory, it provides a real practical response to HDR processing. The problem of output to a monitor has not been solved by this module, but it seems that international bodies are working to replace Lab by Jz in ICC profiles for monitors. Of course, this will also have to be translated into changes in RT (LCMS, etc.).

This module was developed (2 years ago) with the help of extensive testing by @Jade_NL and @Wayne_Sutton thanks to them.
Following my review, it has undergone few changes, apart from an extra level for “Surround” and a slider to adjust the local contrast.
For your information, JzCzHz (or Jzazbz) is not a CAM (Color Appearance Model) - any more than Lab or OKLab - and does not take physiological effects (simultaneous contrast, etc.) into account. As you can easily see, if you deeply modify Jz, the other 2 dimensions Cz and Hz remain unchanged.

The parts I’ve added to the code (Absolute luminance, Surround settings) are only partially taken into account. In addition, there’s no “Viewing conditions” module. it includes many personal adaptations to make it work (nothing that calls into question the principle).
The algorithm requires double precision and my code-writing capabilities are limited, so I can’t take full account of OMP (multithreading) or SSE instructions. So the code is slow and consumes a lot of resources. Nevertheless, the CIE classifies it as “very good” in terms of colorimetry and “HDR”.

Change to “local contrast”
I’ve noticed some anomalies - in rare cases - with “Local contrast” implemented in “Cam16”. I’ve chosen to replace it with “Unsharp mask” (without FFTW - Fourier Transform ), as it takes into account the level of shadows - and therefore the surround effect. It’s totally transparent to the user - still a single slider that hasn’t changed. Maybe the default settings are “a little strong”, with the same slider setting I tried to take into account, empirically “Surround”

Executable ‘lacam16n’:

The processing challenge is coming up… soon.

Jacques

4 Likes
18

Salut Jacques, they haven’t disappeared, see screenshot. This is with the JzCzHz module.

To be honest, for an amateur photographer like me, this module is way too complex.

You stated that you are implemeting researchers’ work, but that makes me wonder: who is your “target audience”? Color scientists only?

I even doubt that professional photographers can (or are willing to) deal with this complexity, they need quick results because clients are waiting…

dump_527
dump_527696×461 58.6 KB

DSC_8093.jpg.out.pp3 (19.4 KB)

1 Like
19

Hello Paul

For me, it’s above all to understand. If you look at the posts on colorimetry in DT, RT,… elsewhere, you are told that “Jzazbz” is the future.

I wanted (personal challenge) to try to make this thing work, almost not documented. I know that others have tried, and have achieved more than mixed results.

It is obvious that the interface is complex, and the code is complex in terms of colorimetry.

I will look with your pp3. But tell yourself (I am like that, and I think after all these years that you know me a little) that developing this kind of thing interests me, even if it doesn’t interest many people.

I see your pp3. I do not have this file DSC_8093.jpg, but DSC_8078.NEF when you went to Marseille. Can you (also) put the DSC_8093 (NEF and or JPG)

Thank you very much.

Jacques

20

Yeah, I know you a bit ! :wink:

Here’s the NEF.

DSC_8093.NEF (18.7 MB)