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.)
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 !
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 (?)
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.
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.
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.
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.
I fully agree with this statement and am very happy with my results.
EXACTLY! And don’t forget that it is only with your highly saturated photos that you will notice any difference in your rendering when using the new colour space.
What I do is as follows:
Always use the new wide gamut colour space
Look to see if my photos has any out of gamut (OOG) colour and be aware of them.
Edit as normal (soft proofing off)
If I have OOG colours then I do a quick check with soft proofing on and make adjustments as necessary
Export as desired and check the result.
Re-edit if necessary.
Like Greg, I find the colour rendering of PL6 more pleasing than previous versions along with the ability to work with a wider range of colours.
Everyone will develop their own way of working and I believe that photography is not an exact science and the result you produce is your own interpretation of the image you captured. If you achieve the result you are after then you should be happy. Use the tools you have to achieve the result you want. There is no right or wrong way as long as you achieve your desired result.
Finally, being aware of how PL6 and colour management works will help you achieve your results in a more consistent manner.
Yes, and that’s pretty much why I’ve been “banging on” for so long about this (and now, finally, I’m pleased that it’s getting some recognition) - That is;
We on this forum are interested in properly understanding how PL works, in order to get the best out of the new Wide Gamut WCS … Therefore, we make the time & effort to test, explore, debate, etc
However, I’m pretty sure that does not describe the majority of users(!!) - who expect PL to “just work” - and to just work “like it used to” (such that WYS-is-always-WYG).
But, with the DxO Standard preset now setting WCS = Wide Gamut by default for new images - these “innocent/naïve” users may not always enjoy the WYSIWYG experience they previously did.
Despite there being no direct involvement by DxO in this discussion, I’d be surprised if they’re not monitoring it - and, accordingly, we may see some refinements coming to PL to do as Mr. P suggests (?)
There are some other, related, things I reckon should be fixed too (again, in the spirit of protecting the “innocent/naïve” user from implications that they probably do not understand);
The DxO Standard preset (as applied to newly encountered images), assigns WCS=Wide Gamut - but leaves Soft Proofing un-activated … That’s setting-up unsuspecting users for possible surprises.
The default ICC Profile setting on Export-to-Disk is “As shot” … which comes from the camera setting, which an “innocent/naïve” user may have set to AdobeRGB (because someone told them that’s better than sRGB) … again, setting-up unsuspecting users for possible surprises.
Another export ICC Profile option is “Same as Soft Proofing” - - but, Soft Proofing is un-activated by default … which is rather confusing !!
I reckon the default should be “sRGB~~” - as that’s almost certainly what an “innocent/naïve” user would need… and the rest of us understand enough to know when/if we need to change it.
Actually, I don’t reckon all this is too complicated at all - - It’s just that, with PLv6’s current default behaviour, it can catch-out the “innocent/naïve” user … in which cohort I certainly do not include you, Joanna !
For the rest of us, it’s easy to deal with;
In this case, you know what you’re doing - just keep doing it … now, with the benefit of being able to apply your corrections with Soft Proofing = ICC Profile for your printer (and, “soon” too, ability to simulate the target paper and ink)
Again, no real difference - just have Soft Proofing activated, with ICC Profile = sRGB (probably)
I detailed four different Soft Proofing scenarios (that I could think of) up above.
… 
