You are right, I just noticed my mistake. If I mask all the values of the srgb-export, that are either 0 or 255 in any color-channel, the mask is similar to the softproof out of gamut warning:
So it seems all correct, except that the RGB values of the histogram are not updated correctly, this seems to be a bug.
The relationship between the histogram and the RGB picker of the image viewer is complicated:
Remember also that the DxO Wide Gamut working color space isn’t presently available for RGB files. DxO seems intent on improving that, but who knows if that will include the properties of the image viewer (which is in need of an overhaul)?
Hi maderafunk,
checked with the referred tiff-file, and yes, with a sRGB capable monitor you have a lot of out-of-gamut warnings for the monitor (blue overlay) as well for the sRGB softproof (red overlay). From your screenshot both seem to be identical.
And as @Egregius noted, TIFFs are not yet supported by DxO’s Wide Gamut WCS (see your screenshot), which means, your ProPhoto file is handled in AdobeRGB colour space, just like in PL5.
About the indicated values – no idea. If ever, I’m looking for the histogram to check what RGB channel might be necessarily treated first hand.
[Checked in old PS, where I can set a ‘marker’ on the pic to read out & indicate the values – no, they don’t change with softproof. ]
Just one more thing to mention, when I wrote …
Everything ‘outside’ the Destination target’s colour space gets crushed (oversaturated) – and in the case of a print as far as the paper can hold (inkjet) or reproduce (‘photo paper’) the colour.
→ Oversatured colours will look brillant on your monitor and all is fine – as long there is no important texture.
Hi George - - In relation to your questions, please note Keith’s disclaimer right from the start;
So …
“PSCA” is a label that Keith and I invented ourselves … to describe the DxO proprietary algorithm that’s applied to retain colour and details where the process of converting colours in the Working Color Space to the target color space could cause them to be “clipped/lost” (not meant as a technical explanation).
As for where/when the PSCA is applied (?); see the diagram; #6 & #8
You will not find “PSCA” mentioned in any DxO manual … See above.
I’m not clear on what you mean by “for display” … but, just to clarify;
As to your surprise at this behaviour - I was initially surprised too, which is why I’ve been “banging on” about this issue for so long !! … Note, however;
John
Actually, no - The very purpose of the PSCA is to ensure that that is not the case.
According to the explanation we were given during Beta testing, saturated colors that will not “fit” (my term) into the target’s colour space are processed by DxO’s algorithm in order to best retain detail and color … via a proprietary process, (conceptually) somewhere between Perceptual & Relative intent.
In regards to the Color Management pipeline diagram - as published with this post;
However, the concept of the “PSCA” (other than the name/label we gave to it) is NOT just something invented by us …
John
True - we don’t know if it’s also applied when converting from the Legacy/Classic WCS - but I’m guessing not, because;
During the Beta testing stage, we were advised the PSCA is applied when the destination is one of the RGB profiles; sRGB / AdobeRGB / DisplayP3 … (but only when SP=ON, or when Exporting-to-Disk)
Yes - that’s absolutely the take-out for me too … Such that, counter-intuitively;
(WYSIWYG = What you see is what you get)
For more on this, George; note the “4 distinct scenarios for soft-proofing”, as described here.
John
I already mentioned it’s wonderful you made a diagram of the workflow. It makes discussions much easier and minimizes a wrong understanding of whet is written. I do hope my posts are seen as constructive.
No, it’s called protect saturated colors on automatic.
I think that’s exactly what @asvensson meant. Why not on during editing?
I think it’s all due to the larger working place in which the corrections to the output working place are much bigger. But now we’re discussing the behaviour of pl, not your diagram.
Still I think the conversion from soft proof gamut to output gamut should be an essential part of that diagram.
George
Exactly this: they’re applying an algorithm at export that they’re not applying to the what I’m seeing on my display unless I enable SP. I don’t see in what case this is helpful/desirable when SP isn’t enabled.
If I export an image with my display profile as custom profile then I would expect the resulting file to render identically (well, modulo PRIME) to the image I see when editing, without having to enable SP to target my display profile. It sounds like there’s no guarantee because of this additional algorithm that I don’t see without enabling SP. That’s a problem by design if it’s really the case.
(Not that I would export with my display profile, but whatever they’re doing should be consistent with this case as well.)
That’s not the same thing, George … that reference is to the slider setting for Color Rendering;
… 
We invented the PSCA acronym to stand for DxO’s proprietary Protect Saturated Colors Algorithm - - it’s a similar name for a similar function - - but, not the same thing.
I cannot answer that question, George … all we can do is alert fellow PLv6 users to its behaviour.
Meanwhile, the simplest work-around is to always have Soft Proofing activated … I have done so via my personal, automatic preset.
John
PS.
Absolutely, George - I see this discussion as the ideal way to explain this issue.
Yep ! … and that’s what I’ve been attempting (with barely any success whatsoever !) to alert my fellow PLv6 users to via my proposal here.
Interestingly, that’s exactly how I first discovered the impact of the PSCA - - I exported for the ICC Profile of my own specific monitor - and then I was puzzled as to why the result (on that same monitor) did not look exactly the same as what I was seeing (on the same monitor) within PL … and then I found that this could occur (with certain images - especially those with saturated colours) if Soft Proofing was NOT activated … All else came from that simple observation !
John
Good find. That’s a major design blunder, or a juicy bug if we’re generous.
Has DxO even acknowledged the problem? They certainly don’t participate much here, and Support often isn’t helpful in my experience.
My assessment is that this behaviour is most likely an unintended consequence … Our understanding of it might be the catalyst for change in a future version (?)
John
All of the above takes me to the conclusion that the interdependencies of colour rendering, working colour space and softproofing for a “true” representation of the image…should lead to a “wysiwyg” mechanism that sets sensible combinations automatically, be it in a new colour tool or with the current set of tools…and a setting that enables “wysiwig” or not. This could prevent combinations of customising settings that will lead to unexpected/unforeseeable results. After all, DPL is also about ease-of-use, which has suffered with the introduction of the new colour engine and features.
Yes, in the FAQ referenced above and during the early access testing period. It is self-evident that the PSCA is in the export pipeline which requires soft proofing to see. I think it should be in the ordinary preview pipeline also, but can imagine that possibly leading to other problems. Just leave soft proofing on if you’re exporting to the same color space as your display.
Can I just jump in and say something?
Until all this colour management “stuff”, I was totally happy working with PhotoLab 5 (and previous)
Everything just worked and I got perfect (to my mind and eye) prints.
Now, I am under the impression that I have to keep on thinking about soft proofing, pipelines, profiles, usage cases, etc.
If I’ve read correctly what @John-M and co have been writing (for which DxO should be grateful), I now have to do all sorts of contortions, just to export to a disk file.
I have two output options that I use -
3. Occasionally export to DNG for for further processing
In PL5, all I did was select the output file type, sRGB for JPEGs and ProPhotoRGB for TIFF and press the export button.
Everything “just worked™”
Do you know what? I think I’m going to stay with PL5 
That’s exactly what I’m doing, and I bought PL6. The more I read of all this color management here the more my head hurts. It’s just not worth it to me now! I do though really hope that DXO will be able to get their new color space working in a similar manner to the previous, ie simple for me. 
I remember something like this has been reported. But all of my exports are in AdobeRGB, whatever I choose.
I did choose a b/w profile, the image was exported as b/w but the color space mentions AdobeRGB.
Exiftools says uncalibrated. There was something with that but I forgot.
@John-M
Equal exports with sp on or off are different.
George
George
For what it’s worth, I’m churning out finished photos faster with PL6 than I did with PL5, despite the bugs and new color rendering pipeline in PL6. For my Olympus camera RAW files, the new working color space seems to make it easier to get the results I want, not harder. Many people don’t understand what PL6 is doing differently or what soft proofing is all about (not their fault), and they rightfully wonder why they have to work harder to tame saturated colors (particularly red). The simplest answer I can come up with is this: with the legacy working color space, PhotoLab brings all the color data into a smaller color space early on in the pipeline so that you can simply work within those confines and not get into much trouble. You do lose some quality in the process, but you’re not likely to miss what you don’t know is missing. With the DxO Wide Gamut WCS, we tend to get more saturated colors from the start, and some of these can be out of gamut for our destination. What new steps does this require from us? For me, to tame reds requires a bit more use of the Color Rendering and HSL adjustments. That’s all. Previously, I’d just raise the protect saturated colors slider in Color Rendering. That isn’t enough with the wide-gamut WCS - but so far I’ve been able to get good gradients and balance without any unusual color-manipulating gymnastics. And I like the rendering I’m getting with DxO Wide Gamut more than with the Legacy working color space for the same photos. PL6 is preserving more color detail and allowing for smoother adjustments.
Keeping Soft Proofing on is not a problem for me. But DxO is going to have to address the confusion surrounding its own implementation. Terminology and technique need to be clarified. We need DxO to fix color rendering bugs quickly and provide better documentation that isn’t scattered all over dxo.com and doesn’t require a careful search to locate.
The EXIF specification requires that the ColorSpace tag be either sRGB or uncalibrated. Is that what you’re looking at with Exiftool? Did you export with the setting “As shot” in PhotoLab, or with a custom ICC profile? Is there any embedded ICC profile data that conforms more to what you’re looking for?
A specific icc profile or as soft proof. I tried also a simple sRGB and still it mentions AdobeRGB in IrfanView. I’ll check exiftools in this specific situation. Camera is always on sRGB.
George
This was in one of the more recent posts. Two tags, one set to 1 means sRGB, if set for (can’t remember), the second tag names the profile.
This means that apps should check the second tag for the profile if the first tag is not set to 1