[Solved] CIE model 2002 causes blue to become black

Sometimes when boosting color saturation a bit using the “Color curve” in CIE Model 2002, blue colors will “wrap around” and become black. It happens especially often when the white balance has a low value (typical for incadescent light). My guess is that some signed integer value wraps around. There is a full description and example files here:

http://rawtherapee.com/oldforum/viewtopic.php?f=1&t=5643

I run into this problem on a regular basis these days, because colored LED lights are becoming more and more common, and I often have to give up on using CIE becuase of this, which is a shame because the CIE color processing is generally superb.

I searched for this bug on github, but it doesn’t seem to be there. Are there any plans to address this?

@JoaCHIP
Weird things happen with highly saturated blue in the CIECAM02 and as a general rule you should make sure you’re using an input profile suited to LED lighting when working with it, and possibly change working space from ProPhoto to sRGB.
But blue turning black was a bug fixed long ago.

  1. Which version of RT are you using?
  2. Start with the Neutral profile and enable the minimal amount of tools to reproduce this, then share your raw file and PP3.
  3. What happens if you set saturation to -1 or change working space to sRGB?
  4. Related links:
    CIECAM02 turns white areas dark · Issue #1607 · Beep6581/RawTherapee · GitHub
    CIECAM02 turns white areas dark · Issue #1607 · Beep6581/RawTherapee · GitHub
    CIECAM02 turns white areas dark · Issue #1607 · Beep6581/RawTherapee · GitHub
    pure prophoto blue rendered black · Issue #2125 · Beep6581/RawTherapee · GitHub
    pure prophoto blue rendered black · Issue #2125 · Beep6581/RawTherapee · GitHub
    Perceptual curve problem with blues · Issue #2889 · Beep6581/RawTherapee · GitHub
1 Like
  1. I’m currently using v4.2.976 (but I was at a much earlier version when I first noticed this).

  2. Okay, did that, turned saturation -1, enabled CIE lab, and did a curve for the saturation (usefule feature btw), and here are the files you requested. The light comes from a flash behind some blue plastic: http://www.robotplanet.dk/f/rawth/blue_light_v4.2.976.zip

  3. Saturation -1 does help a little bit, but depending on the other settings such as white balance and such, I can provoke the problem with saturation values as low as -30. Changing working color space to sRGB has an effect fur sure, but it does not prevent this problem from happening.

  4. Yes, it’s marked as resolved in 2015, but I still get odd colors when there’s too much blue and when using a color curve the way you’ll see in my .zip file.

I really hope this will help someone figure out why blue colors sometimes become black when you mess with boosting color saturation in CIE mode. I love CIE mode. It looks so much better than RGB based manipulations, and I even prefer it over Lab / YUV operations when trying to make my D600 reach those “Fuji colors”.

Bonus info: It’s even reproducable using a simple PNG file. The problem seems to be easiest to provoke when doing a color curve on the CIE “Chroma” or “Colorfulnes”. It does not happen when selecting “Saturation”.

http://www.robotplanet.dk/f/rawth/colorfades.png.pp3

Becomes:

Ping @jdc could you take a look?

I committed a fix from Ingo.

Hello again,
Will this fix be in the official version at some point? I just tested version 4.2.1148 and the problem remains.

I can’t reproduce the issue with your png file using your pp3 file in master branch. Didn’t try with gtk3 branch

New discovery: The choice of “Input profile” under Color Management has a large impact on how much this happens. Maybe this is a clue to where the problems reside?

Regarding this “gtk3 branch”: I’m on Windows, so I’m only referring to the builds available on RawTherapee’s web page, currently running v4.2.1148. I’m not compiling anything myself.

I’ve just retried using the same png, and yes, I still see the odd color bands show up when enabling CIE color + curve on that .pp3 file. I’ll include the whole screenshot so that you can see what I’m doing.

And then I enable the CIE switch, and it happens:

This is something that happens a lot when I work with photos taken at concerts where LED lights have become rather popular lately. They exhibit a rather high gamut, which is something Nikon D600 doesn’t handle anywhere as well as Fuji. In any case, this is something that does happen in real life situations, and that’s why I think it needs attention.

The reason I made this PNG is to show that the problem is not related to specific camera vendors, as you can see from this example which is constructed in Photoshop without the use of a camera.

If there’s anything else I can do to help you locate this, I’ll gladly help. I’m still a big fan of this software despite this little detail.

That’s strange. Here’s my result doing the same using master branch (gtk2)

Puzzling. Could you send me your .pp3 file perhaps?
Also, have you tried with different input profiles? That seems to have a huge impact on this.

The pp3 is the one you posted above. Which input profile shall I use?

@JoaCHIP Can you post the changeset of your rt version please (from Preferences/About/Version)

“Embedded” gives me one kind of wrong output, and “No profile” makes the left-most bar almost invisible. But if you’re using my .pp3 file, you’re already using the correct one. Something is up with my setup then.

Interesting. It appears I’m using gtk3. I’m pretty sure I just picked the “normal”/official download from the web page.

Branch: gtk3
Version: 4.2.1148
Changeset: 2bfb0acdd7ea202bb716e84585802d1875e41da4
Compiler: gcc 5.3.0
Processor: generic x86
System: Windows
Bit depth: 64 bits
Gtkmm: V3.18.0
Build type: release
Build flags: -m64 -mwin32 -mthreads -std=gnu++11 -mtune=generic -Werror=unused-label -fopenmp -Werror=unknown-pragmas -msse -msse2 -mwindows -fopenmp -Wno-aggressive-loop-optimizations -DNDEBUG -O3
Link flags: -m64 -mwin32 -mthreads -static-libgcc -mtune=generic -mwindows -s -O3
OpenMP support: ON
MMAP support: ON

@JoaCHIP A fix for this case was pushed to master branch on Aug 2. The version you use is from Jul 12. Please try RT 4.2.1234 or the newest build from here

1 Like

FIXED! :grinning:

I’m dancing now. Thank you!

1 Like