Thank you a million times!
I’ve been compiling RT from git using the “origin/dev” branch. If there will be a new branch for adding the sliders to the CIECAM02 code, then I’d be very happy to switch branches and test changes as they are made, if that would be helpful.
Hi Andrew,
Changing the color of the light illuminating a scene is an example of chromatic adaptation. Making a chromatic adaptation between different light sources is something that CIECAM02 is supposed to be really good at doing. Making the adjustments in the current RT CIECAM02 module is easy to do for the available presets, and having “temp/tint” sliders will make it easy for any reasonable destination “color of the light”.
As you suggest, I could have got the colors I wanted by adjusting various parameters in RT, simply because I had the lamp already available for comparing what’s on my screen with what the real lamp looks like.
What about situations where you don’t have “the real thing” available for comparison? Most of us have very poor memory for colors, and our eyes so very quickly adapt to what’s on the screen - we accept the oddest colors as being somehow believable. Which is why, IMHO and regardless of one’s actual artistic intent for a given image, it’s extremely helpful to have the CIECAM02 module, and also important to use one’s own eyes (I love the clarkvision diatribe against making the moonless night sky blue: Color of the Night Sky, Clarkvision.com), and also helpful to learn a bit about colors and color appearances under various lighting conditions, as both starting points and reality checks on the color modifications we make in the digital darkroom.
As an aside, based on the RT Custom white balance on the plastic lid the color of the light from the lamp is a couple hundred degrees away from the RT Tungsten preset, and although I think the CIECAM02-modified color is pretty close, it could be even closer. So I’m very interested to see what will result from having Temp/Tint sliders for making CIECAM02 chromatic adaptations.
I just push a change in a new branch “ciecamout” 
Now you can
To prevent confusion, I have modified “Preferences” with these seetings and write “Settings in main menu”
It seems to me we increase complexity, because in most cases there is no necessity to change these values. But there is a demand, and the customer is always right
jacques
@jdc - Thank you! that was fast!
The new code compiled without any problem. I ran into an issue where disabling the CIECAM02 module did strange things to the image’s white balance, and the cursor seemed “stuck” on setting a new white balance whenever trying to move the image in the viewing panel, even when not on the Colors tab. But this might be a problem with left-over configuration files, or maybe a user error of some sort. I’ll try again after deleting the configuration files. Plus I’ll compile the main branch and see if the “stuck on white balancing” issue is also in the main branch.
Elle
hi Elle, thanks for the comments. I see your point about getting reasonable colours when the real thing is not available. I liked the clarkvision link and milky way picture, really interesting to see how all the colours can be justified and are correct.
Brilliant that @jdc has done changes already! OMG, people will be demanding enhancements done overnight!
I clean “Preferences” and some Tooltip
I’ll not be at home during 2 weeks
jacques
How does GTK3 bring a dark image outline by default? Do you just mean the fact that the RawTherapee default GTK3 theme is dark?
It seems that for maximum usefulness with the RT CIECAM02 module, really there should be an RT theme with an L=50 background. The lightest theme currently supplied by RT is TooWaBlue Bright, which is around L=37.
Is there a way the user can modify the current dark colors in the RT default theme? Perhaps a file to open?
Maybe Preferences > Default Theme > “Crop mask color/transparency” is enough.
If not, see:
and
https://github.com/Beep6581/RawTherapee/blob/dev/rtdata/themes/TooWaBlue-Bright-GTK3-20_.css#L45
@define-color bg-grey rgb(128,128,128);
@define-color bg-dark-grey rgb(100,100,100);
For me, if we want not to have CAM problem, the best solution is to have a theme surround about Yb=18 (as in my very old Photoshop). In another word with a grey luminance L=50
I modified the default theme colors, replacing every instance of #484848 and #363636 with #777777 (actually #777975, but that’s another issue), and recompiled RT, and ended up with almost every color in the user interface as L=50, including all the backgrounds in the file browser apart from sliders and text.
Unfortunately the background behind the actual image is still very dark, as is the background behind the histogram and navigator.
What’s the actual line of code in the css file for the background behind the image in the central panel? So far I’ve made 5 separate modifications/recompilations/test runs hoping to hit the right line in the css file, but obviously I’m not finding it. Or else something else is going wrong. Sigh.
@Elle changing the canvas background is outlined in the first part of my previous reply, and the rest of the UI is set by the specific lines in the second part. The default “RawTherapee” theme’s code is messy and more difficult to target. @TooWaBoo’s themes are better maintained.
You don’t need to recompile RT after changing CSS files, you don’t even need to restart RT. If you edited theme X and your running RT is using it, then just toggle the theme to Y and back to X.
Hi @Morgan_Hardwood,
Hmm, I’ve read and re-read your previous reply and I don’t know what you might mean by “first part of my previous reply”. Yes, @TooWaBoo’s themes seem better maintained and easier to modify. But there seems to be a bug in the “Bright” theme that causes the scrollbar in the right panel to partially cover the letters on the right edge of the right panel, until the panel is made a bit wider. As the panel is already quite wide, making it even wider isn’t something I want to do.
As an aside, currently neither the left nor right panel can be narrowed from the default width (the top thumbnail panel can slide upwards and out of sight. Is this a peculiarity of my current operating system/desktop/settings? Or is this by intention?
Good to know I can modify the theme itself in the folder where the compiled code resides, thanks!
Hmm, my mistake, that “seems to be a bug” in the “Bright” theme is also in the default RT theme. I’m not willing to say it’s an actual bug because since switching from Gentoo to OpenSUSE I’m running into an awful lot of issues with GTK3 code. But I think this might be an actual RT bug.
Oh, and replacing a few more “background-color” with #777777 finally made the actual image background middle gray. But I don’t know which particular item was the key.
Can you show us a screenshot of the scrollbar, please?
@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)
