RawTherapee's CIECAM02 module

@Elle
You are true :slight_smile:
In fact white balance in a majority of software is quite wrong. People think they are true while changing temperature (and or green), but they forgot adaptation (CAM). Our eyesight and our brain are more complex than a computer

In an other way, I am working on two complex things

  1. local White balance, to adjust WB to local changes : shadow mix with sunlight, tugsten mix with others, etc. I think now algorithm is good, but I’ll work on multiple spot.

  2. automatic WB. The actual WB is simplest, based on grey world just before demoisaicing. In this way many software used this algorithm
    I work on various algoritm (about 5 or 6), I found on University works… But what is certain is to think that the perfect automatic WB is possible. In fact the problem is mathematically indeterminate, all we can do is find the least bad

And with these 2 approaches, I’ll add a) after demoisaicing, b) with or whithout Gamma sRGB, c) with or whithout CAM

It’s complex, and requires a lot of tolerance and patience from the testers. The world did not happen in one day

1 Like

@Morgan_Hardwood, @Elle

I will check what I can do this weekend.

@Morgan_Hardwood @Elle

Here’s a new test theme (remove .txt from the file name)
TooWaGrey-GTK3-20_.css.txt (45,6 KB)

That’s the best compromise I could do. I didn’t find any way to change the color of the double lines. I also had to change the TooWaBlue main theme. If the theme is OK for you I’ll create a PR.

@Morgan_Hardwood
I want to keep the Bright theme, 'cause @heckflosse and me are using it. I changed the name of the new theme to TooWaGrey, 'cause most parts are now grey. :slight_smile:

@TooWaBoo great!
May I suggest making the dark pane backgrounds less dark, to lower the contrast? Just a bit.

To change the color of the separators use this:

separator {
	background-image: image(#ffcc00);
}

I use 3.22.16, I get the following warnings:

(rawtherapee:21989): Gtk-WARNING **: Theme parsing error: gtk.css:68:35: The style property GtkButton:child-displacement-x is deprecated and shouldn't be used anymore. It will be removed in a future version

(rawtherapee:21989): Gtk-WARNING **: Theme parsing error: gtk.css:69:35: The style property GtkButton:child-displacement-y is deprecated and shouldn't be used anymore. It will be removed in a future version

(rawtherapee:21989): Gtk-WARNING **: Theme parsing error: gtk.css:70:34: The style property GtkCheckButton:indicator-size is deprecated and shouldn't be used anymore. It will be removed in a future version

(rawtherapee:21989): Gtk-WARNING **: Theme parsing error: gtk.css:71:36: The style property GtkCheckMenuItem:indicator-size is deprecated and shouldn't be used anymore. It will be removed in a future version

(rawtherapee:21989): Gtk-WARNING **: Theme parsing error: gtk.css:73:46: The style property GtkScrolledWindow:scrollbars-within-bevel is deprecated and shouldn't be used anymore. It will be removed in a future version

(rawtherapee:21989): Gtk-WARNING **: Theme parsing error: gtk.css:76:30: The style property GtkExpander:expander-size is deprecated and shouldn't be used anymore. It will be removed in a future version

(rawtherapee:21989): Gtk-WARNING **: Theme parsing error: gtk.css:83:29: The style property GtkStatusbar:shadow-type is deprecated and shouldn't be used anymore. It will be removed in a future version

@Morgan_Hardwood
Thanks for the tip “background-image”
The Gtk-Warnings belongs to the Adwaita theme “gtk.css”
Changed the dark part from rgb(78,78,78) to rgb (85,85,85)
If the dark part is too dark or bright, tell me the rgb values you want, please.

TooWaGrey-GTK3-20_.css.txt (45,6 KB)

One possibility is to make the “dark” parts the same as the middle gray parts:
@define-color bg-dark-grey rgb(120,120,120);
@define-color accent-color3 rgb(120,120,120);

I tried that just now, and the theme looks very nice, well, at least I like it quite a lot, can’t speak for others :slight_smile: .

For my taste this is too much. :slight_smile:
But you can use it like you want. When the update is done and you downloaded and installed the new build. Make a copy of the TooWaGrey theme, rename it e.g. Elle-GTK3.20_.css and make your changes.

EDIT: Set @define-color accent-color3 rgb(120,120,120); too @define-color accent-color3 rgb(135,135,135); to get a different highlight color for the thumbnails.

Hello

Can I merge branch “ciecamout” in “dev” ?

Jacques

@jdc better to first create a pull request so that the code changes can be reviewed:
https://github.com/Beep6581/RawTherapee/compare/dev...ciecamout

Hi @jdc ,

If ciecamout is merged into dev, would it still be possible to make changes to the CIECAM02 module?

Currently RT CIECAM02 is set up “asymmetrically” such that moving the “Scene” chromatic adaptation slider to 0 always changes the image, even if the input and output sliders are set as nearly as possible to the exact same settings. This puzzled me quite a lot, so I’ve been spending some time experimenting with the old PhotoShop CIECAM02 plug-in to see if I could figure out why.

The PS plug-in provides symmetric input and output sliders, including Chromatic Adaptation sliders and Color Temp choices for both input and output. As long as the input and output sliders are set to the exact same settings, the image remains unchanged. In this sense the PS plug-in is more generalized than the RT CIECAM02 module, and so provides more flexibility for making color temperature changes, and also for experimenting with CIECAM02. But it doesn’t provide temp/tint sliders, doesn’t handle large images (and in general isn’t exactly user-friendly even if one were open to the idea of using non-libre software into one’s workflow, which I’m not).

For RawTherapee CIECAM02 it would be wonderful to have a complete and symmetric set of sliders for “scene/input” and “viewing/output”, defaulting to settings appropriate for “scene/viewing”, but allowing the user the option to change the sliders to settings suitable for other types of uses.

Elle

All is possible :slight_smile:

Nevertheless, your proposal will lead, for a “normal” use, to an additional complexity.
At least :

  • 3 additional sliders: temp and green for “scene conditions” and another for adaptation CAT02
  • A further choice in the combo-box “WP-model”

But I do not agree to make the system symmetrical by default, because almost never, we will have “scene luminosity” and “viewing luminosity” at the same value, as well as for all the settings …The Cliff Rames plug-in is one thing, Rawtherapee is another thing.

But I’m prepared to make those changes. For this I need other opinions :slight_smile:

Jacques

The enhancement made by @jdc to allow changing the output device’s temperature, green and Yb are now in dev .

@Elle

I just push a change in a new branch “ciecamenh”

Now you can

  1. select temp and green for “scene”. You must for this select in “WP model” = free

  2. use CAT02 for “viewing conditions”

Jacques

Hi @jdc

Thank you so much! I just built ciecamenh and it looks really nice. I’ve been experimenting with using the CIECAM02 color temperature adjustments to bring an image closer to what I remember, after first making a “to neutral gray” white balance using “Colors/White Balance”, and I suspect the additional CIECAM02 sliders will be very helpful.

When there is a branch for white balance algorithms, I would very much like to help with testing. Something about results of white balancing raw files has always seemed a bit odd to me, but I’m clueless as to why. Are there studies/papers that you could recommend?

Here some links for “white-balance auto” not exhaustive :
http://ieeexplore.ieee.org/abstract/document/6395096/?reload=true

http://www.csie.ntu.edu.tw/~fuh/personal/AutomaticWhiteBalancewithColorTemperature.pdf

https://www.researchgate.net/publication/266341203_A_Color_Balancing_Algorithm_for_Cameras

http://ieeexplore.ieee.org/document/1649677/

https://www.eee.hku.hk/optima/pub/misc/0800_SSI.pdf

If you want to test !
Branch : “autowblocal”
Then “Color” - it is after “white balance”

Actually

  • “auto iterate temperature correlation” does not work at all
  • for testing in full image, you must put the spot in the center and delimiters at the limit of preview and “transition” to maximum
  • settings for “spot” does not work…you can use only one spot
  • I don’t think “auto wb” for local is a good idea…but I cannot said that before !!

I’ll work on “auto iterate temperature correlation”, I think it is the better. This algorithm is mine, I took idea in various texts. It is quite complex, and perhaps it will not work. But now it is vacation with my family.

After:

  • I will separate “White balance auto” incorporated or not in “white balance” and “local WB” with several spots
  • I will optimize : “gamma”, “cat02”

But at least we can test :

  • local WB : exemple for shadow in sunlight image
  • principle of each algorithms

Algoritms mixed or not:

  • auto grey demosaic : based on grey word but after demoisacing
  • auto edge : edge are enhanced in grey word…
  • auto robust : iterative WB
  • auto standard deviation : image is divided in 12 area, for each we calculate mean and std deviation
  • auto iterate temperature correlation : to improve ?

Jacques

Hi @jdc

I’ve been reading and experimenting with ciecamenh and made a list of possible changes to the user interface that I think might make the module more useable for general cases, and also perhaps easier to use:

My apologies in advance, it’s a long list!

  1. An easy way to reset sliders to their default value:

Some of the sliders have a checkbox, some have a “reset” arrow, some have both, and some have neither. Checking the box returns the slider to the default value and also disables using the slider until the box is unchecked.

I think it might be more convenient if none of the sliders had the box, and all the sliders had a “reset” arrow that would reset the slider to the default value.

It also might be nice to have a “master” reset arrow or box that would allow to reset everything at once to the default settings. This would allow people who are experimenting with CIECAM02 to get back to the original settings without having to guess or do a lot of clicking. Perhaps a “per submodule” box would also be nice. This way, for example, the user could leave the “Image Adjustments” sliders as set by the user, while having the option to reset the Scene and Viewing sliders.

  1. Conserving screen real estate:

With the extra sliders enabled in the Scene Conditions, it would be nice to have the option to “fold up” the individual submodules, to allow the contents of the remaining submodule(s) to be visible without scrolling.

  1. Scale of Scene/Input luminosity vs Viewing/Output luminosity:

The current “scene luminosity” scale goes to 16384 (2^14). The current “viewing luminosity” scale goes to 1000.0.

For the particular use of preparing images for display in a room with normal or dim room lighting, these scales cover what users would likely need.

But for other uses - such as when a user really only wants to use the “Image Adjustments” module, or if a user wants to make “aesthetic” adjustments via a CIECAM02 chromatic adaptation - it would be nice to allow the viewing/output luminosity to go just as high as the scene/input luminosity. This would allow the user to accurately set the Scene/Input luminosity, and then also be able to set the Viewing/Output luminosity to match.

  1. “luminosity” vs “luminance”:

A lot of image editors use “luminosity” to refer to various units of measure connected with “how bright/light” something is. But technically speaking, “luminosity” refers to the energy output of astronomical objects (Luminosity - Wikipedia). It seems to me that when image editors use accurate terminology, users have an opportunity to learn “correct stuff” - imagine if a user tries to look “CIECAM02 luminosity” up in a book or journal or on the internet.

It took me awhile (and a fair amount of reading) to figure this out, but RT’s “Scene luminosity” and “Viewing luminosity” refer to absolute luminance, out there in the real world. So for these sliders it would be nice if “luminosity” could be replaced with something like “luminance (abs.)” or “absolute luminance”.

Yb is relative luminance (more reading) and so is a percentage. I think it might be helpful to users who want to “dig beneath the surface” of the RT CIECAM module if Yb sliders show a percent sign, and maybe the labels could mention relative luminance, with an on-hover tool-tip that explains a bit about what Yb is - with unfamiliar terms and concepts, tool-tips are greatly appreciated!

  1. Access to Scene Yb, and sliders for Scene and Viewing Yb:

Currently Scene Yb luminance is only available under Preferences/Color Management. It’s hard-coded to Yb=18/L=50, or else to “Automatic” (there is no slider to set some other value), and the comments say the image must be reloaded before changes take effect.

Could Scene Yb be made available from the CIECAM02 module, with a slider that goes from 0% to 100%? And could the Viewing Yb scale also go from 0% to 100%? Of course the extremes are unlikely and even unuseable! But including the extremes allows the user to experiment freely.

  1. Surround:

Currently the surround option for Scene is limited to checking or not checking the “dark” box, which doesn’t seem to exactly equate to the Viewing option of “Dim” or “Dark”. It might be nice to have the same options for Surround in both Scene and Viewing.

  1. Access to LCH or JCH color picker values:

The RT color picker reads out LAB and RGB, but ideally needs LCH - or even better JCH - when used in conjunction with the CIECAM02 module.

For example, I was trying to use the RT CIECAM02 module to move the JCH Hue of a photograph of the moon to something like 105, and the only way currently this can be done is via color picking combined with using something like ArgyllCMS xicclu at the command line, and then making compensatory adjustments, color pick again, etc, until reaching the desired Hue.

LCH is not a substitute for JCH as the Hue angles don’t exactly line up. But LCH is probably easier to put in the RT color picker than JCH, and also probably “close enough” for most uses, though down around Hue 270 things diverge quite a lot, and I have no idea what happens when the full CIECAM color adaptation model is being used. In an ICC profile color-managed editing application, I suspect “everything relative to D50/L=50” is the best thing for a color picker.

  1. Temp/tint and also presets for choosing the white points:

Temperature/tint allows for a great deal of user control when setting and modifying the Scene/Input and Viewing/Output white points. I think it might be useful to also have access to presets (sort of like in the Colors/White balance module), including perhaps these presets:

A
D50
D55
E
D60
D65
D75

plus whatever is appropriate for known display devices such as projectors.

Elle

1 Like

@Elle
1 2 3 4 5 6 are now in RT

For 8, it adds complexity, for an Illuminant D or A , I have add a Tooltip: select Tint (green) = 1. and D50 = 50001K etc… I think it is suffisant

@Hombre
For 7, I don’t know how to do :slight_smile:

But now, I have suppress all simplification I have done 5 years ago. :slight_smile:
It is not difficult, no change to main code, only GUI.

I have open a Pull Request for Ciecamenh
Jacques

1 Like

I built the autowb branch this morning, having last night taken some photographs under mixed lighting (indoor lighting from various sources combined with strong back-lighting from the setting sun, coming through a large window and filtered through green leaves). I’m looking forward experimenting with the new algorithms. Thank you! for the links to the articles.

Thank you, thank you! Pulling and compiling, it looks really nice!

I was hesitating to suggest 8 because of added complexity in the UI. It might be nice to put a table in the RawPedia with equivalent Temp/Tint settings for various presets, unless maybe there already is such a table? Rawpedia covers a lot of information!

I looked for the little arrow icons - I think I know what you mean as darktable has arrow icons for hiding/unhiding various panels. But I don’t see such arrows in the RT interface. I did figure out that the keyboard shortcut “L” closes and opens the left panel, which helps a lot. Also, I finally discovered that clicking on a module does close the module, leaving just the header for the module visible. This is so convenient! Somehow I managed to use RT for years without discovering how to hide modules, but this page does give all the information:
http://rawpedia.rawtherapee.com/General_Comments_About_Some_Toolbox_Widgets

I change behavior of the 2 sliders “La”.

Now, it is as “temp” non linear, because most of values (especially for Viewing conditions) are between 0.01 and 100) on a scale 0… 16384

:slight_smile:

IEEE Xplore seems to require a membership before allowing access to the text, otherwise just supplying an abstract. Here are alternative links for the two IEEE articles:

https://www.researchgate.net/publication/266341203_A_Color_Balancing_Algorithm_for_Cameras

The researchgate website brings up suggestions for related articles, so I ended up reading several other articles, mostly just scanning quickly.

One method of auto white balancing that was mentioned in one of the articles - that maybe isn’t in the RT autowb branch? - is making the chromaticity histograms line up, which can be “sort of” done in GIMP (well, in GIMP-CCE) by outputting the image in the camera input color space (assuming a well-behaved linear gamma input profile), putting a 50% gray layer over the top using LCH Lightness blend mode, making new from visible, and then using Levels to push the Red, Green, and Blue channels around until their peaks line up.

This “match the chromaticity histograms” approach seemed to produce reasonable colors in one of the two test images that I’ve been experimenting with. This image is of a pond with lily pads, shot under bright sunlight. For some reason using “Daylight” white balance in RawTherapee (and all the other raw processors I’ve tried) turns the lily pads to magenta. There are some blown-out areas in the sparkles in the water around the lily pads, but not in the actual lily pads.

Another approach that was mentioned in some of the articles has to do with “dark” something or other (sorry, I forget the exact phrase) - is this like white balancing by moving the raw file black points? Or by looking only at dark areas in the image, on the assumption that shadows are usually neutral in color? Or something else altogether? - obviously I was scanning quickly instead of paying attention!

The best “auto white balance” I’ve seen for the “lily pads” image is the result of using GIMP-CCE’s “Levels/Auto Input Levels” (the reason I specify “CCE” is because in default GIMP there are issues with getting Levels to operate properly on images that aren’t in the sRGB color space, and additional issues with getting Levels to operate on linearized sRGB, if the image is already an sRGB image, plus sRGB isn’t a good color space for white balancing an interpolated raw file).

The other test image that I’ve been experimenting with is a grey card held half in direct sunlight, half in deep shade (very sunny “clear blue sky” day). As might be expected, the “edge”-based algorithms fail badly on this image.

Auto iterate temperature doesn’t actually work yet, yes? Leastways it produces bright orange on both of my test images.

So currently, at least when Transition is at maximum, I think the white balance set in the White Balance module doesn’t yet affect results?

From testing, it seems the gamma/cat02/etc options aren’t yet supposed to be working? Do they require also activating the CIECAM02 module?

I couldn’t figure out how to add a second “control point” - I think this is what you mean, using two control points, one for sunlight and one for shadows? This would seem difficult to use in images where shade and direct sunlight are intermixed, but maybe I don’t understand the UI.

Are the various auto-white-balance algorithms and modules activated before or after the image is interpolated?

I can provide my two test raw files if they might be of use. They are from my Canon 400D, so only about 10 megs each.

Elle