Thanks folks for the changes made here.
I was just trying it. Interesting. Will be very helpful in evaluating pictures I think.
For example, if I understand correctly, I can see at the press of a button the difference between sRGB and “adobeRGB” by
The buttons change very little when pressed, could they stand out more? (Not a new behaviour, I know)
The button press appearance is controlled by the theme, so you can customize it pretty easily.
Could someone explain about how the cyan OOG marking works please?
I opened an RT_sRGB Jpeg thinking there would be no OOG marking, but there was, and quite a lot of it. This was with RT_sRGB output and monitor setting. So I guess the marking starts before the limit is reached, like over-exposure I suppose. But the question is, can you the dev(s) give a feel for how soon it starts to register. I tried reducing saturation and changing hue (LAB adjustments) and it took large changes to remove or minimise the cyan in some jpegs. One was nearly a black-and-white before the last cyan disappeared, I was surprised!
I suppose what I’m asking is around this - you want to have a feel for what you can get away with re. OOG colours, which I appreciate doesn’t have a simple answer, but it would be good to know how the cyan marking works.
Thanks, yes, TooWaBlue sorts it!
If you have “soft-proofing” turned off, the OOG pixels are relative to your monitor profile. So it might happen that even if you have a RT_sRGB image, you get some OOG pixels because your monitor doesn’t cover 100% of sRGB. FYI, the screen of my old thinkpad T400 covers about 50% of sRGB…
I had RT_sRGB as my monitor profile, so it’s surely nothing to do with a custom monitor profile for a less-than-perfect screen. That is, image, output and monitor were all RT_sRGB.
hmmm, then I don’t understand what’s going on… I’ll take a look. (RT simply delegates to LCMS for oog indicators)
a possible explanation is that the soft-proofing/oog check happens after the conversion from input to lab profile (going through the working profile), so perhaps this pushes some colours out of gamut. but this is just speculation, I haven’t tested yet
Thanks to @agriggio, and @Carmelo_DrRaw’s code, the new Out-Of-Gamut function now looks good, at least to me. It’s in its own branch currently.
