I doubt that. Soft proof converts to the soft proof color space and that’s send just into the regular pipeline to show images on the screen. See Soft Proofing - #27 by George and read the comments under the diagram.
Maybe when perceptual is used the result might be the same, but non perceptual on the first conversion is changing the input of the second conversion.
From what I read in the manual PSCA is part of the demosaicing process in the standard preset. I don’t see any reference to the export, yet
Hi Greg,
thanks for jumping in. – Everyhing was tested on a sRGB monitor (Eizo CG2730, here specifically set up to calibrated sRGB colour space to be comparable).
Going through those screenshots …
The pic (screenshot 3) is out-of-gamut, but the sRGB screen can not show the full colour range.
In screenshot 4 the Monitor out- of-gamut warning (blue overlay) indicates the area with affected colours, but it does not say by how much they are ‘off’. It can be from just clipping to really ‘off’, while the sRGB monitor limits what we see. In fact, the saturated blueish green is affected.
Screenshot 5 shows the same pic with some green reduced (until the Monitor out-of-gamut warning went off). Comparing 3 and 5 shows (some of) the difference, but best is to try out oneself. The blue overlay from 4 hinders to compare instantly.
.
“The grass is greener” example comes with “Do I need this extra ‘colour information’?”
For sure, I don’t. The grass is green (enough) and just being the ‘background’, but saturated it may look nicer. – Just to remember the ‘hype’, when Fuji introduced their Velvia film emulsion.
Screenshot 6 shows the softproof to sRGB IEC61996-2.1 with Destination gamut warning (red overlay), which again indicates the area with affected colours – similar to #4 …
Screenshot 7 shows the pic with the same green reduced by the very same values (now causing the Destination out-of-gamut warning to go off) – similar to 5 …
. The softproof to sRGB (6 and 7) triggers to apply DxO’s‘automatic’ rendering → PSCA.
Of course it is the same rendering as with the equivalent export – otherwise it wouldn’t be a “softproof”.
The screenshots 8 and 9 repeat the same thing, but with softproof to the Destination paper profile.
Toggling between them shows the different coverage between the sRGB monitor colour range and the paper profile – approximately indicated in 2.
. But different to before, we have a‘manual’ rendering application, where I chose the RI relative colorimetric.
Toggling between perceptual and relative colorimetric clearly showed a difference.
general notes
With the use of DxO’s Wide Gamut mode, we get a different result from out-of-gamut pics than before in PL5 (or now in PL6 Classic-Legacy).
The ‘need’ to put on softproof or not depends on the colour gamut of the source file (how far out-of-gamut my pic is compared to the Destination → shown here with softproof to sRGB or a paper profile), … which means, also on a sRGB monitor it can be necessary (it is advised) to put on softproof to ensure WYSIWYG, simulating the export output.
The colour gamut of my monitor with the applied display profile determines, what I can see from a given file. That is, on a wide gamut monitor I can see a wider colour range, but have to softproof just like that to see & judge (correct) how the file will come out in a smaller colour space. – And the same thing goes for printing …
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.
Right. That “PSCA” is something else. As far as I can tell, DxO hasn’t created any documentation yet to explain why you’d want to enable Soft Proofing when both the monitor and destination are the same (typically sRGB, as this color space is small enough to consistently require decision-making by PL or by us concerning out-of-gamut colors). I haven’t seen any mention of the PSCA in the manual or elsewhere on dxo.com. I’ve only seen it mentioned in the forums, but its effects are obvious in cases where it makes a difference. So we know it exists and that it’s part of the export rendering pipeline that Soft Proofing lets us see.
We are waiting for DxO to explain that publicly. But see here for the discussion and a request to change the behavior:
But that is specific about wide gamut. And with a restriction for he upper group of color gamuts in the tool. The self imported icc profiles are treated different.
One thing is for sure. Pl is not open for what they are doing and making a mess of it.
But the soft proof image goes back in the pipeline to the monitor.
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.
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?:
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.
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)
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 …
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.
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.
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.)
