I’ve read your posts a couple of times …
Your screen is 100% sRGB capable, which means the display also plays back in AdobeRGB colour space – but only to a certain degree (roughly as far as sRGB is contained) → see graphic
I do not understand your explanation about “Protect saturated colors” (below your camera’s Color Rendering), while of course OFF with an exported TIFF-file.
The blueish complementary colour is nothing else than an overexposure warning and the clipping indicates some overload in the red colour channel → too bright.
Similar to when taking a photo from an object with a brigthly lit, predominant colour.
There also might be oversaturation, but there is neither a gamut warning nor a softproof capability
– if not introduced ‘secretly’.
Did some experiments with my ColorChecker and adjusted the raw-file’s (black &) white point
with the Tone curve, just shy of the clipping warning.
Export as 16bit TIFF-file w/ AdobeRGB colour space didn’t show clipping
inspite of the histogram moving slighty when compared to the adjusted raw-file.
Export as 16bit TIFF-file w/ sRGB colour space showed some clipping (as your example)
and a slightly expanded histogram, ‘touching’ the (black &) white point.
To solve that ‘issue’, I just took down the Tone curve by 1 point (255 → 254).
BTW, all exports were done with monitor set to AdobeRGB as well as sRGB colour space
(changed custom profile preset & restarted PL) → no display profiles involved !
When exporting a file, at present DxO uses the rendering intent perceptual.
– Say, you have a file in AdobeRGB colour space with some colours, which when exporting to sRGB colour space would land outside the target’s range. The perceptual rendering intent takes care of that and all (not overexposed) colours are moved into the target’s colour range, so that the perception of the present colour renditon is kept. – While simple and userfriendly, all colour values change to some degree, depending on how much ‘outlandish’ has to be stored in.
As already said, with a screen like yours the ‘best’ solution is to export in sRGB colour space
– and even better when your screen is properly set / calibrated.
Should you have a special project, you export as AdobeRGB and reduce to sRGB later.
→ The way back doesn’t work, as you don’t get the ‘extra’ colours back.
And do yourself a favour and try some of the mentioned test pics.
have fun, Wolfgang
addendum The above test was done with “Protect saturated colors” ON.
After digging into that topic (and some understanding), I switched “Protect saturated colors” OFF and repeated the test (5) – but no change w/ the clipping indication, independent if the monitor was set to AdobeRGB or sRGB colour space → no display profiles involved !
Comparing the histograms of the equivalent output files, I could see the influence of that saturation protection switch, now leading to some ‘sligthly’ higher saturation values in the 3/4 tones (the bright side).
If you have the magic want active this slider starts to clime, from 0 til 100%, if the saturation of colors are passing the boundery’s of AdobeRGB. It "protect’s your image from clipping colors due desaturation of the full saturated colors in that image when you change contrast and such.
So in order to have saturation warning in AdobeRGB. I just pushed saturation until i saw the protection starting to be active. Just for the test not as editing skill.
3 and 4, i was earlier in a search about the color indication’s and dxo doesn’t have that specific explanation as FRV has,
It’s over brightning or over exposure of the rawfile and saturation of one or more of the channels. I think they used this:
About gamutwarning, it’s as far as i can detect pure based on there working colorspace AdobeRGB. And fixed on that. Soft proofing is adjustable between colorspaces.
So dxo has no softproofing.
I know and agree.
Which test pics?
The perceptual intent rendering give DxO the wiggling space to let the warnings just be done in AdobeRGB. Workingcolorspace. During export all colors are squeezed inside sRGB equally spread out giving a natural look.
My proposal is creating a easy userinterface with some softproofing capability’s.
A side by side image view one in working colorspace as always AdobeRGB and one depending on the choosen export colorspace.
Marking the oversaturated/clipped colors with colors and maybe the same kind as FRV has a channel separated underexposed and over exposed Percentage.
I always have fun working in dxo. It’s a hobby
I think what you see on your screen is in the color space defined in the preferences. In my case sRGB. So also the clipping warnings.
If you want to see the underlying pixel values of your clipping warnings, set the mouse pointer on a warning and switch with Ctrl-W or Ctrl-B. You’ll also see that clipping warnings for highlights start at a value of 254.
now I understood what you did (never watched that functionality)
→ addendum …
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
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 …
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.
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.
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.
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.
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.
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.
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.
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.
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.