Color space.... again

Hi Peter,
now I understood what you did (never watched that functionality) :slight_smile:
addendum …

  • something irritating:
    one can activate this protection slider also w/ output files,
    but unexpectedly it has no effect ( → tested by comparing saturated VCs … )
    while it does – as soon one applies Color Rendering / Film … *)

And yes, you might be right that the “Protect satured colors” magic wand
acts in conjunction w/ AdobeRGB colour space

  • as this is PL’s internal color space
  • and can avoid some oversaturation
    – otherwise covered by a wider colour space ( ProPhoto, Melissa, ROMM RGB … )


  • it’s neither an out-of-gamut warning
  • nor has it to do with softproof

both realized e.g. in LR – and (also) helpful when using sRGB monitors

have fun, Wolfgang


From → here … I got a test pic in ProPhoto RGB colour space

set my monitor to AdobeRGB colour space,

started old LR 5.7

and put LR in Softproof mode → sRGB / relative colorimetric

note – don’t judge the colours from those screenshots
(the Forum’s software doesn’t support any profiles)

*) Protect saturated colors (from the manual)

1 Like

Hi Peter, almost forgot about …

Following the video by Andrew Rodney, I realized that Keith Cooper now has a couple of videos online.
Ever since I made (and make) use of his informations and especially the well documented test pics, which are not only good for printing → see here / here.

The Datacolor test image is available in AdobeRGB color space → download …
Screen Shot 07-14-22 at 03.17 PM
and also in sRGB → download …

but with it’s variety of scenarios → check … it is much more useful
than the (next) Fuji sRGB test image, used for Fuji’s Frontier System.

And you find → other test pics there too.



my small test shows that if i saturate red/pink until the saturationwarning (blueisch spots) and export then in AdobeRGB 16tiff and sRGB 16bit tiff you see in the adobe tiff the same warnings again. (workingspace over saturation is clipped but border of full saturation 10%/5% from 100% is usually the blinkies activation level) wile in the smaller colorspace of the sRGB tiff the warnings much more visible are: perceptual intention squeezes the outer values more inside => more pixels are 95% isch saturated.
This shows that the saturation warnings are based on workingspace only and not based on your display colorspace settings.

i don’t want to play pinpointing and nitpicking (not at all, i am not in the position to do so in this area.
Just get the things clear and recalibrate my knowledge on this.

quote from someone who knows what he’s talking about:

Gamut: This is the area in which the color producing object (a led, paint toner, ink, de sun) all redisch, blueisch, yellowisch, greenisch and all color around can produce.

i miss interpreted it a bit maybe.
but colorspace and gamut are the same if i am right:
So out of gamut warning could be based on your display ICC profile or just from AdobeRGB/sRGB.

Colorspace: a defined area in which a color-range is mapped for reproduction.

Notice the ProPhoto colorspace which over steps the visible gamut of the human eye.

Reply Digidog: **You’re showing the color gamut again, differently but yes. The container (with or without any pixels) defined by (in the case of your illustrations) the plotting of their primaries: red, green and blue.

That is what i allways try to remember: Gamut is the maximum capable colorrange a device can produce wile colorspace is a more structured defined colorrange. (like mine monitor has a bigger gamut then sRGBcolorspace.)

DxO is lacking any form of softproofing other the exporting “downsizing” from workingcolorspace to sRGBcolorspace wile using perceptual intent rendering . And unless they add a userinterface which holds a from of control (settings) in which colorspace is rendered in an other and on which device/paper we can speak of no soft proofing. :slight_smile:

Saturation warning and blown/noisefloor warnings triggered by the moon and sun ikon are as far as i understand based on two things:
Saturation of channel(s) in color and luminance level/brightnes (which is totaly different from “exposure” which is only connected to the rawfile’s “gamut/colorspace” and in pixel RGB-modes it’s a mapped kind of saturation depending on the used colorspace.)
the RGB based colorcone. max value on all three RGB means you get “white” turn green off and you get magenta like purple fully saturated.

thanks i will read and watch it.

I think this is to quick. I did your test and I must say it’s fun to play with it.
Switching between the two tiff files also shows a little movement in the histogram. In my thoughts the RGB image will be expand to AdobeRGB working space and then back again to sRGB monitor space, in my case. The extra clipping you see is a difference in pixelvalue of 1 or 2. Not much for 2 transformations.
But the movement in the histogram is more interesting.
Oh, clipping starts at 253.


see → my last Addendum …

  • The blue overlay shows a warning about the monitor’s colour space.
    – If that’s my display profile (AdobeRGB in this case, optimized for grey scale) or the native monitor color space (indicated to cover 99% AdobeRGB), I don’t know.

  • The red overlay shows a warning about the chosen target’s colour space,
    in this case sRGB w/ rendering intent relative colorimetric.

What matters in the end, if the monitor does show what you are working on.

1 Like

yes, depending on image content (technical, not subject) as shown [here].(Color space.... again - #53 by platypus)

I think the movement of the histogram between these 2 files is due to the rendering intent. When a sRGB file is loaded the file is transformed to the AdobeRGB color space. Since this is a bigger one only the pixel values are changed to gain exact the same colors. But once in memory what is seen is sRGB. That same file is now transformed to sRGB using perceptual rendering intent. All the colors are shifting a little. And to the right of the histogram.


@OXiDant and others,
Did you check my theory? It’s becoming very quite. :unamused:


Sorry, i was off to hunt for bathroom furniture, someone wants to renovate the badroom…
drove more then 300km yesterday in order to select some things. (yes i am oldfashion i want to see and feel the product because i am the one who places the stuff so if it’s rubbisch it’s not bought.:-).)

If perceptual is used then the squeezed colors from adobe to srgb could be restored in the proces of srgb to adobergb.
see cambridgeincolors link above. its reversible.
and if the sun and moon warning colors are “set to file colorspace-index” sRGB in this case then the restored colors could be “out of gamut” which explain the more warning indicationcolors on the flower.

  • One can convert sRGB to AdobeRGB – and at best the present colours are kept intact,
    but one doesn’t get any out-of-gamut colours back (if there were – not every subject has such colours).

  • The question by @George could be answered by DxO (avoiding speculation).

1 Like

I did load the sRGB tiff and exported it as sRGB tiff. They where exactly the same. No movements in the histogram. Based on my theory that would mean that the conversion sRGB->AdaboRGB->sRGB didn’te change the end result. And that would mean that my original assumption didn’t concern two renderings but only one.
I tried to figure out what was the maximum difference on these clipping colors, I did find the maximum of 4. In the non-clipping areas it was more. Clipping appears above 253.


please read

The clipping indication (over 253) is not necessarily bound to oversaturation, but indicates “too bright”,
which also can be caused by saturation, but …

Another distinction is that perceptual does not destroy any color information — it just redistributes it. Relative colorimetric, on the other hand, does destroy color information. This means that conversion using relative colorimetric intent is irreversible, while perceptual can be reversed . This is not to say that converting from space A to B and then back to A again using perceptual will reproduce the original; this would require careful use of tone curves to reverse the color compression caused by the conversion.

So automated restore is not going to happen i think. you have to manual recontruct.

in Silkypix you have

i can set it myself:

98% is 249,9 from 255. and 5,1 so 253 and 4? is alright.

One other thing you should keep in mind is if you have smartlighting active this tool is also active in squeezing dynamicrange inside a smaller range. a smaller range means or smaller steps between black and white, no colorcontrast and saturated colorcontrast or LESS steps in shades.

So unles DxOstaff is stating otherwise my conclusion is:

  • Sun and moon is always working on AdobeRGB (workingcolorspace) if the file is raw,adobergb based tiff/jpeg/dng. not display colorspace depending nor export colorspace depending.
  • importing a sRGB based file it sets sun and moon to that colorspace. (it just looks at the saturation/brightnes numbers which are inside the mapping of the file. pixels which have a channel which holds 0-5 is underexposed warnings and 250-255 means overexposure/saturation warnings)
    no fancy rendering of working colorspace to displaycolorspace and back to export colorspace of the file.
    there isn’t any soft proofing so they can’t work like that.
    they have AdobeRGB which holds every demosiaced pixelfile (jpeg,dng,tiff and preview of raw) with a whitebalance and lumination mapping(tonalrendering) Every editing in exposure(lumination), contrast or colortoning is done inside this AdobeRGB profile. (screendump(your visual view on the screen) is just a icc-icm correction convertion based on your made calibration or factorysetting icm.and no “colorwarnings” are activated by it.)

When done and you choose 8bitsRGB for export and then the perceptual rendering re-maps all data into this container and colorspace. again no real softproofing only narrowing shade-steps so it fits inside the 0-255 steps of the RGB channels based on the sRGB space. In colormetric it would be just clipped. and the remaining colorshade’s renumbered?

(the fact we don’t get much response from dxOStaff could mean they can’t peak openly about this.)

I don’t know Silkypix, I’m on Photolab. But you can ask yourself the same question: where is the histogram based on? On the working space or the output space.
And did you check the total movement in the histogram between your AdobeRGB and the sRGB tiff files?


We have bin in this rabithole earlier.
Histogram is based on a pixel based colorspace.
If the file is pixel based it showes the colorspace it is stated in the exif data.
If it’s a rawfile like file it takes the biggestcolorsoace it can handle.
AdobeRGB. So the histogram is mostly in AdobeRGB.

or buy a wide gamut monitor with self calibration inside :-)…bit more expensive…but effective.