Bug: PhotoLab shows the clipping overlay RGB values instead of the ones from the image

I noticed this as well, it is a little annoying, but so easy to work around…

+1 . This behavior appears to be illogical.

I’m sure Svetlana will ask you to open a ticket.

This limitation has always been known.
The mouse gives you informations on the pixel from image displayed.

I personally never understand why the mouse cursor didn’t not a target form to be more precise.


Hello guys,

There is no need to create a bug for it.

As we have a story to improve Shadow/Highlight clipping in the new viewer and we’ll see what can be done.

Svetlana G.


Good to hear it. As I interpret it, the Shadow clipping indicator now combines the tonal clipping with out-of-gamut indicator. It would be a good idea to decouple those two bits of information because they serve a different purpose (one is shadow recovery, the other is predominantly an oversaturation issue).

While I’m at it I have a question for you, Svetlana. The out-of-gamut indicator is based on PhotoLab’s internal / working colour space (Adobe RGB), right? I don’t see it mentioned anywhere in the documentation.

Good morning,

RGB coordinates are based on what you select here (ICC profile for display):

Svetlana G.

I see – that explains why the Shadows clipping mask corresponds to Lightroom’s Soft Proof gamut warning for Adobe RGB profile in my example. So it’s not a working space gamut warning but display gamut warning. It would be useful to have both (and also output profile gamut warning), like in Lr.

Another comment on the ICC profile selection in the Settings: the option to choose Adobe RGB as ICC profile for your display might be confusing people who don’t know much about colour management. The setting only works well if two conditions are met: 1) you calibrate/profile your wide gamut monitor to Adobe RGB space and 2) your wide gamut monitor has a gamut which completely covers Adobe RGB in all hues. My wide gamut Eizo covers 97% of Adobe RGB but its volume exceeds Adobe RGB at 107% (i.e. it goes beyond Adobe RGB in some hues but does not cover all the hues of Adobe RGB), so choosing Adobe RGB in the settings would be wrong for my monitor. The default option is the best and shouldn’t be changed, in my opinion.


That ICC profile used for display does not exist on macOS, right ?

No idea. It’s better to ask Mac team about it.

Svetlana G.

Hi Sankos - Thanks for this discussion/info on display vs working space gamut - esp. as I’d put myself in the category of one of those “who don’t know much about colour management”.

By “default option”, do you mean Current profile of the display device … or the Generic profile (sRGB) for display device ?


Hi John, in my opinion the “Current profile of the display device” option covers the most bases because it caters not only to the needs of people who perform hardware calibration/profiling of their monitor, but also to those who never venture into the Color Management options (by default Windows sets sRGB as your generic display device profile).

1 Like



I see – that explains why the Shadows clipping mask corresponds to Lightroom’s Soft Proof gamut warning for Adobe RGB profile in my example. So it’s not a working space gamut warning but display gamut warning. It would be useful to have both (and also output profile gamut warning), like in Lr. … …

Thank you to pull up this old thread.

Yes, when preferences set to < Current profile of the dsplay device >, the clipping warnings react accordingly to the user’s screen … and in case of commonly used sRGB monitors limited to sRGB colour space … ( special thanks to @sankos for your findings ! ).

While this behaviour might have been intended for ‘ease of use’, it should be mentioned in the online-help.

Similar to Lightroom 5 (I’m still on that old version) users of PL’s Elite editon should have the option to choose ‘pure’ clipping or showing the restraints of colour space – another difference to the basic version, while attracting professional users. :slight_smile:

have fun, Wolfgang


Yes - that’s an excellent suggestion :+1:

John M

I just noticed this issue is still present 2+ years later.

It’s not a problem for me as such, but I noticed it because the photo I was working on had blown highlights on a corrugated steel building so moving the mouse over this area caused a wild disco light effect on the colour patch as it switched from browns to a bright cyan and back over very short distances.

I you want the real pixel values zoom in, your mouse pointer on the desired place and toggle with CTRL-W. That short cut de(activates) the highlight mask and warning.


1 Like

This is one of several long standing issues with details that could (and should) be corrected…
Since Svetlana has mentioned a “new viewer” more than two years ago: when might that be released finally?


Good morning!

Well, as the strategy was to provide the users with the new features, the integration of the new viewer was postponed. I’ll let you know when it’s done.

Svetlana G.

Hello Svetlana,
thanks for your answer.

However, to me exactly that “strategy” appears as a big problem. Focusing only on new features obviously is a very safe method to simply forget/ignore all those long standing issues - even if they have been promised to be fixed.

While I, personally, am not interested at all in new features like DAM or keyword editing (they are completely useless for me), I really miss fixes and corrections to other issues that are long overdue.

(Of course I really like other new features like DeepPRIME, for example. I’m just complaining about the apparently complete loss of working on older issues.)

Just two other examples from the list:

As a long term user of DxO (OP+PL), I must confess I am somewhat frustrated about this.



Hello Svetlana,

now it’s four more weeks - and there still was no official statement on the mentioned long-standing issues. Thanks for your “like”, however that alone won’t change or correct anything in the software…

Now that the current EA period is reaching its end and PL5 will be anounced soon, I’m pretty sure these issues won’t be addressed (again). That makes yet another year of waiting for these (sorry) stupid bugfixes.

I simply don’t understand that attitude.