@Elle the side panels have a minimal width beyond which they cannot be shrunk, but they can be hidden using either the little arrow icons or the keyboard shortcuts. Ctrl+f this page for “visibility” http://rawpedia.rawtherapee.com/Keyboard_Shortcuts
As for the canvas background, my previous reply was off-topic. What you’re after is adding a line such as this to your theme:
#BeforeAfterContainer frame widget {
background-color: #ff0000;
}
Thanks for the screenshot. The culprit of the scrollbar problem are the length of the labels. The toolbox will expand until all labels are fully shown. If the toolbox container is set too small the scrollbar covers the toolpanel. Redusing the font size and/or changing the Font will help.
@Morgan_Hardwood - you are right, the @TooWaBoo theme is very easy to modify 
Setting lines 34, 44, 45, and 46 in the TooWaBoo Bright theme to rgb(119,119,119) produces roughly L=50 background. These colors are for the bg-image, bg-light-grey, bg-grey, and bg-dark-gray.
Then there were three issues: There is no visible dividor between the left, center, and right panel, the text has too little contrast with the background, and the bright blue sliders and such were a little too bright. So I changed a few other colors and came up with what’s shown below (still no visible divider lines):
I’m not sure how it came to be that so many image editors ended up with very dark themes. At least Krita, GIMP, and Blender also provide middle gray themes, which is nice.
If one’s goal is to edit an image that will be displayed on a web page with a dark background, or on a projector or screen in an otherwise dark room, and with a dark surround around the displayed image, then the dark themes are logical choices. But in RT, there is already the CIECAM02 module to take care of such situations .
If the intended background against which the image will be displayed isn’t really dark, a really dark theme surrounding the image while editing doesn’t make any sense at all.
Completely agreeing with Desmis - it seems to me that if there’s only one default theme, it’s best to have that theme be middle gray, L=50. As much as can be done using CIECAM02, I’m not sure that asking the CIECAM02 module to also compensate for a very dark background around the image while editing in RT, is a particularly good use of the module.
@desmis - Thank You! for coding CIECAM02 for RawTherapee. I’ve been wanting a better understanding of CIECAM02, but at least for me, without software to experiment with, all the technical descriptions in the world are just so many words. I hope other imaging software developers will follow your lead.
It seems to me that when the artistic goal is capturing the color of the light, the chromatic adaptation portion of the CIECAM02 color appearance model is a very important tool in a photographer’s toolbox. I think digital painters also could benefit from having access to CIECAM02. Consider painting a scene, and then wanting to make a version of the scene under a different time of day/different lighting conditions, as per Monet’s haystacks (Haystacks (Monet series) - Wikipedia) or Hiroshi Yoshida’s sailboat series (handprint : color temperature). Editing and painting colors of course is ultimately based on looking at the real world, combined with artistic evaluations of what looks right on the screen while editing/painting. But it doesn’t hurt to have a tool that helps get the image at least partway towards a desired change in the color of the light.
The Temp/Tint sliders in the ciecamout branch are very nice. One thing that was missing from the “presets only” version of the CIECAM02 module was the ability to account for the tint. For example when white balanced in the Colors module, my tungsten lamp image has a strong magenta component on the tint slider, and without the CIECAM02 tint slider, there was no way to add back in the magenta component.
At first I found the “auto” option for the degree of chromatic adaptation to be puzzling. But after experimenting with the sliders, and if I understand correctly, in reality our eyes don’t always chromatically adapt to changing colors of the light “all the way”. Sometimes there are two or more light sources that might have different colors, which leads to being partially adapted to one or the other light source. And for some light colors, such as tungsten or even early morning direct sunlight, I think maybe we don’t ever adapt 100%, or maybe it just takes a long time (which amount of time of course isn’t available for early morning direct sunlight as such light is fleeting). This is something that I think everyone knows implicitly, but I hadn’t thought about explicitly. Someone please correct my observations if I’m completely off base here !
I made a quick change for the theme. Perhaps it fits your needs.
After downloading remove the .txt extension from the file name.
TooWaBlue-Bright2-GTK3-20_.css.txt (3,2 KB)
@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
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 :
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