@TooWaBoo it looks good. Could you also make the double-lines (between the Filmstrip and the preview, and between the History and the Snapshots) #4b4b4b (75,75,75)? We could then replace TooWaBlue-Bright-GTK3-20_.css with this one.
@TooWaBoo - That is very nice! Thanks!
The only thing I would change, and this is a case where aesthetics might contradict complete usefulness, is the darker shade of gray in the left panel. I’d change those areas to match the middle gray surrounding the image.
As shown in the above screenshot, the image is surrounded by middle gray. But when zoomed in so the image areas are right next to the darker area in the left panel, dark areas on the left side of the image will appear slightly lighter than equally dark areas on the right.
I’m saying this based on staring at side-by-side images that I knew beyond any shadow of doubt should be identical, and yet one looked lighter or darker than the other, and puzzling for long minutes until realizing, yet again, that the surrounding colors make a difference. Or looking at shadow detail that “just yesterday” was perfectly clear, but “today” is hard to discern, and the reason turns out to be, yet again, that the surrounding colors aren’t the same.
@Elle
You are true 
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
-
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.
-
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
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.
@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 
.
For my taste this is too much.
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
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
Jacques
The enhancement made by @jdc to allow changing the output device’s temperature, green and Yb are now in dev .
I just push a change in a new branch “ciecamenh”
Now you can
-
select temp and green for “scene”. You must for this select in “WP model” = free
-
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!
- 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.
- 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.
- 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.
- “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!
- 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.
- 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.
- 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.
- 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
But now, I have suppress all simplification I have done 5 years ago.
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