Good point. Keith’s diagram doesn’t make it clear that PSCA is only for conversions from the DxO Wide Gamut working color space. You’re right - I can’t say exactly how PhotoLab’s handling conversion to other color spaces besides sRGB, such as a CMYK space or a custom ICC profile. Does their extra PSCA come into play? I think it could if colors are out of the export gamut, but if you manually adjust to eliminate out-of-gamut warnings (which is the procedure DxO gives us in the user guide) you’d never know. The important point for me is that Soft Proofing takes PSCA into account (which is part of the export pipeline) whereas the unassisted preview without Soft Proofing (the pipeline for monitor display only) doesn’t. Yes, the soft proof preview in the export color space must pass into the monitor display pipeline, but I have doubts about what that actually looks like if sketched out.
Hm, I do not quite understand honestly. I took for example a tif image from this website, it is saved as pro-photo, with many colors out of gamut for srgb.
Now, when I look at the monitor gamut, almost everything is out of gamut. The same goes for the srg-softproof warnings.
However, when I check the rgb values of the individual pixels that are out of gamut, they all lie far below 255, no matter if soft-proofing is activated or not. Should they not be clipped without soft-proofing, if you say that PSCA is not active? Also the values do not differ in soft-proofing, even if I switch from srgb to prophoto. On the output file after export with corresponding profiles, they clearly differ though.
Just out of interest, I exported the srgb and prophoto 8-bit images. The prophoto has no clipping at all, the srgb image has a bit of clipping, but only in the red channel. The following images shows the values of 255 in the red channel of the srgb image. Why is that mask different than the out-of-gamut warning during soft-proofing?:
Ok I have just noted, that the histogram RGB values do not adapt at all to the soft proofing.
Here is the original TIFF, with SRGB softproofing on. The RGB values read by the histogram, which are supposed to be out of gamut, read 184,94,34.
Now I export that image as SRGB, and the histogram reads these values correctly as 255, 75, 0.
So we cannot rely on that histogram at all?
Oog colors are not at the bright side but on the dark side of the image.
Also be aware saturation is the relation between the dominant channel and the other two channels. If a red color is saturated and out of gamut, then it concerns the other 2 colors.
George
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).
- Note: We did not “invent” this behaviour tho (only the name we gave it) - This behaviour was clearly explained to use during beta testing … and it’s also explained here, in PhotoLab FAQs.
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;
- PSCA is applied to what you’re seeing within PL only if Soft Proofing (SP) is activated
- PSCA is always applied during the Export-to-Disk process … which is why SP is highly advised.
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;
- I do not argue against application of the PSCA … it’s an excellent PL-specific feature
- BUT, it can catch-out users who are not taking it into account (by not having SP=ON)
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 …
- It’s easy to demonstrate (with an image containing saturated colours) - See the references provided above, by Greg
- Its behaviour was explained to us during the Beta testing stage.
- An example of its behaviour is explained here, in FAQ on the PhotoLab support site.
John
True - we don’t know if it’s also applied when converting from the Legacy/Classic WCS - but I’m guessing not, because;
- I’ve seen no evidence to suggest that it is … whereas, when converting from the Wide Gamut WCS - it’s easy to find such examples … See here, for example.
- And, more importantly, I reckon that DxO would have been keen to retain behaviour for the Legacy/Classic WCS to be the same as it was for PLv5 (and prior).
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;
- Even a PLv6 user with an sRGB monitor - exporting-to-disk via the sRGB profile - and consuming the result on that same sRGB monitor - and/or sharing with other common/typical users with sRGB monitors - and/or posting to the interwebs, etc ; where the expected color space is sRGB
– that is, the most common/typical user configuration …
– should have Soft Proofing activated if they expect WYS-is-always-WYG behaviour.
(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 -
- Export to TIFF for printing to a printer that I have profiled
- Export to JPEG for putting on a web page or sending to a friend.
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. 