I’m a big advocate for the new Working Color Space (WCS); as there are some significant benefits in using the new DxO Wide Gamut over Classic/Legacy - and it’s an important technical advance for PL.
However, with current implementation of WCS-related tools in PLv6;
It’s assumed that we all understand when & why we need to use Soft Proofing !!
– which, perhaps surprisingly to you (as it was for me!), is NOT just for printing.
Otherwise, PLv6 does not always behave in the What-You-See-is-What-You-Get (WYSIWYG) manner that we took for granted pre-PLv6.
Whilst it doesn’t take a rocket scientist to understand my proposal, the concepts around many of the new WCS-related tools/features in PLv6 are new to us … So, I have broken this post down into 3 parts;
1. Understanding when might we be “caught-out” if NOT Soft Proofing with the new WCS … and why. 2. An example where WYS(is not)WYG 3. My proposed solution … and why it is “elegant = fail-safe”
Do take the time to appreciate my proposal … and to vote for it, please
For those who do understand when & why we need to use Soft Proofing my proposal is not so relevant … for everyone else, it will avoid mystification when our WYSIWYG expectations are not fulfilled !
John M
Summary; for those who are daunted by all the detail below … TL-DNR !
When SP=OFF, PLv6 should retrieve the color-space details for the current display monitor, and apply the appropriate additional Protect Saturated Colors algorithm for that monitor;
which I’m advised is technically do-able.
then, no matter if SP= ON or OFF, we always enjoy the WYSIWYG experience we’ve always had
As an additional refinement, PL should default ICC Profile to “Same as Soft Proofing” … as it would then work equally for both typical and sophisticated users (with the latter free to change as they wish).
When might we be “caught-out” if NOT Soft Proofing with the new WCS … and why ?
Here’s a typical workflow scenario that we’d all be familiar with;
We apply all our corrections and artistic-tweaks using PL on Monitor-A.
We then export from PL with Export-to-Disk’s output ICC-Profile option set as follows; … the default option, which adopts the Color Space setting from one’s camera.
– Typically, that will be sRGB … (If it’s Adobe RGB then you’d better have an Adobe RGB capable monitor too - else, the exported file will look very “flat” on an sRGB monitor !)
Or, with … for explicit output to the sRGB color-space.
If it’s any of the other ICC Profile options then you probably know what you’re doing; in which case you will have set Soft Proofing = ON (Right ?!) - So, this “gotcha” shouldn’t be a problem for you
Finally, we display the exported image on the same monitor (Monitor-A) - or, on a monitor with the same color-space capability as Monitor-A (whatever that may be; eg. sRGB, Adobe RGB, P3, etc)
On the basis of WYSIWYG, we’d reasonably expect that what we see within-PL (in its main preview area) to be exactly the same as we get when viewing the exported file on the same monitor - Right ?!
That was always the reliable result, pre-PLv6 … If there were differences, they were so insignificant that we didn’t notice them.
However, that’s no longer necessarily the result with PLv6, for WCS=Wide Gamut & SP=OFF
When I encountered an image where WYS(is not)WYG, I was flummoxed for a while, until @RicardoS explained it as follows;
That is to say;
PLv6 applies an additional algorithm to Protect Saturated Colors (PSC) when exporting to disk.
This algorithm is also applied, within PL, when Soft Proofing (SP) = ON … but not if SP=OFF.
The reason given by DxO developers as to why this is so is that, with SP=OFF, PL does not know for which ICC Profile the PSC algorithm should be applied - ( … More on this later.)
Therefore, for an image containing highly saturated colours; what you see on PLv6’s preview (unless you have SP=ON) may not match with the exported result, even when viewed on the exact same monitor.
An example where WYS(is not)WYG … Note, especially, the rendering on the RHS of the crop.
After applying DxO Standard preset; here’s what I see (within PL) with Soft Proofing = OFF … this is NOT the result I get from Export-to-disk.
With unchanged settings; here’s what I see (within PL) with Soft Proofing = ON … now, this is exactly the same as the result I get from Export-to-disk (when viewed on the same monitor).
So, for an image containing highly saturated colours; what you see on PLv6’s preview (unless you have SP=ON ) may not match with the exported result , even when viewed on the exact same monitor
This is a potential problem in the following cases;
The default setting, as applied by the DxO Standard preset, is Soft Proofing = OFF
– which also suggests an interim workaround; to set-up your own default with SP=ON (which is what I’m doing, for now) … but, that doesn’t mitigate the next scenario
The user doesn’t really appreciate when & why Soft Proofing is needed - so, for whatever reason, they leave it set OFF, and/or they switch it OFF (from a previous default setting of ON).
The “smart / elegant” solution would be for PL to provide fail-safe behaviour - as follows;
If SP=ON then the additional Protect Saturated Colors algorithm will be applied (as now) and the PL preview screen will reflect the related ICC Profile (as best it can, according to its color gamut capabilities).
If SP=OFF (this is the requested behaviour; currently, the additional PSC algorithm is NOT applied when SP=OFF) then PLv6 retrieves the color-space details for the current display monitor, and applies the appropriate Protect Saturated Colors algorithm for that monitor (which I’m advised is technically do-able).
Now, with the Protect Saturated Colors algorithm always applied, the outcome is the same as with SP=ON - and, therefore, the exported result will always look just like the preview version, when viewed on the same monitor.
That works consistently , even for the user with no understanding of why & when SP should be used … The more sophisticated user can set SP=ON with no change to current behaviour.
That is, even with SoftProofing = OFF, we still get the WYSIWYG experience we’ve previously enjoyed - it’s a win-win, fail-safe solution.
Some additional considerations;
The Export to Disk UI asks for the ICC Profile (to be applied to the exported file); with default being “As Shot”, where that will be sRGB or AdobeRGB, according to in-camera settings → EXIF data.
For the typical user (having an sRGB monitor) that’s not ideal if EXIF data = AdobeRGB … which is how I once had my cameras set, wrongly assuming that that defined the RAW file
I reckon t’would be better for default ICC Profile = “Same as Soft Proofing” … as it would then work equally for both typical and sophisticated users (with the latter free to change as they wish).
Thanks for the detailed walkthrough. I have one question and one criticism of your proposed solution.
Question: are you using a monitor which supports a wider color space than sRGB (e.g. Display P3, or a monitor rated for “N% Adobe RGB” (where N is usually in the 90s)? Because if it’s an sRGB monitor I’m not sure why soft proofing with sRGB would show any difference.
Criticism: soft-proofing is an industry term and is generally understood as having no effect on your image or on conversions to your image when exporting it. Your proposal to apply specific color corrections on export depending on the state of the soft-proofing option contradicts this expectation. So it’s a negative vote for me.
Yes, I’ve considered that too … My proposal works equally with a monitor of any capability - because;
When using a monitor with capabilities beyond sRGB you probably won’t be caught-out as much - because you’ll not notice the difference as much (unless viewing the result on an inferior monitor).
My example, shown above, proves that it does … See link to RAW file to test it yourself.
Agreed - and that’s how it works in PLv6 too — only to simulate how the exported result will appear.
My proposal has no impact at all on that understanding. It does not change the current behaviour of
PLv6 … other than to have it function consistently and reliably even if the user does not appreciate when & why SP should be used.
That’s precisely the problem, Florens;
Currently, an additional (DxO “black box”) algorithm is applied when SP=ONand when Exporting … there’s no ability for the user to change this behaviour.
BUT, it’s not applied when SP=OFF … Therefore, in that case, the image viewed with SP=OFF does not always match the exported result - It’s image-dependant … but not always WYSIWYG.
– This behaviour has potential to catch-out unsuspecting users - and particularly sRGB users.
There is a much simpler solution. Give the photographer the freedom to choose any workspace they want. Look at Photoshop and think why Adobe has this market share and DXO’s market share is negligible.
The options that are set in the preference menu are extremely few for software that claims to be professional and has a price that matches Adobe’s prices.
If you take the initiative to set a random working color space I will support it. In this form, the proposal is not particularly interesting to me.
I have used PhotoLab since v1 and never had any problems preparing and printing exhibitions.
I would work in the default AdobRGB space and, unless I wanted a special film rendering, I would leave the rendering at the default “Neutral colour, neutral tonality v2”.
For printing, I would export to ProPhoto RGB and print the resulting TIFF file from Preview, ColorSync or Canon’s utility, using a custom ICC profile for my printer/paper/ink.
The results are wonderful. I never knew things could be any better and everyone who used my printing services were totally satisfied.
All of a sudden, I now have to have a bachelor degree in colour science in order to even work on an image, let alone print it.
Given that I have a profiled workflow, I have never needed soft proofing, so that is something I will more than likely ignore, especially since I won’t be using the abysmal PL print dialog to print directly.
Since DxO deemed it appropriate to release a version with a feature that is “coming soon” it hasn’t exactly encouraged me to use the new colour workflow, since it comes to a screeching halt at the point of trying to soft proof for printing.
So now, it would appear that I will now have to change my workflow one if I don’t want to use soft proofing.
I get a sneaking feeling, I might end up reverting to PL5 at this rate
The only improvement over 5 for me is the retouching update but that really is a very difficult to use addition. I managed to use it on two images but not sure if the effort was worth repeating.
As you rightly point out the printing module is near useless and has been known to be in need of replacing for years but marketing says a new feature gets more brownie points than getting an excising one to work. This would be main use of soft proofing for many to be part of printing, and when they get that part working, users will find the problems with the old printing module so give up.
Apart from printing I am lost as to what you can do with it, I have looked at a number of images with different profiles and really couldn’t see any use for it other than printing and the idea it would be made even more complex isn’t very sensible. To test my results I always export them as part of my work flow in the output, usually jpg, they will be used in and adjust from that output if needed.
The light room print works I take it better than the PL one with erratic margins? Until the PL print module is revamped to work properly soft proofing for it is of little point as I for one can’t print as the margins are uneven. I use Affinity and its soft proofing where its printing doesn’t have the PL problems.
I can’t say anything about that, because I have my prints made by the service provider. But I only want to do what is described in the video, and I get the profiles from the service provider.
And yes, I do it either in Affinty or in the old LR, which I still use as a DAM, which reminds me to set a reminder for December to catalogue all the summer pictures, including the reminder to order new wine
I think you’re making it sound much more difficult than it actually is. Not a lot has changed in-practice … just that one needs to understand when & why Soft Proofing is necessary … and (with the current PLv6 implementation) there’s a “gotcha” for those who don’t … I’m proposing to make it “fail safe”.
and …
Are you assuming you do not need to use SP if exporting to sRGB digital files ?
If so, you’re a candidate for being caught-out - - esp. images with saturated colours (See my example)
In which case, without my proposal, you’ll need to educate them on the need for Soft Proofing even when simply exporting to disk, and even for simply viewing the result on the same monitor.
Yes - I agree. I’m not arguing at all against SP. Most of us here will be fine with the new WCS - - 'cos we’ll understand why SP needs to be ON if we expect the exported result to always be the same as what we see within PL (when viewed on the same monitor).
However, PLv6 does NOT cater for those who do not grasp this. So, I’m posing a “fail safe” solution.
I’m not claiming to be an expert in colour management … but I was rather perplexed when I found that PLv6 could not be relied upon to always provide a WYSIWYG experience, as we enjoyed pre-PLv6.
In fact, it’s this lack of consistency that will catch-out users … as they’ll assume all is fine - just like PLv5 and earlier - until it isn’t. Then it will be completely mystifying for many !
It took me quite a while to work out why this was so … which, to briefly summarise, is because PLv6 applies an additional Protect Saturated Colors algorithm “behind the scenes” - but, NOT if SP=OFF.
Note: Reference to using SP for printing is irrelevant for this discussion … other than that it exemplifies the reason why this “gotcha” will likely catch-out so many; 'cos it suggests there’s not a wide understanding that SP is also necessary for export to digital images (and surprisingly to me; including if subsequent display is intended only for the very same monitor).
Apologies for the long dissertation above … but, as we’re finding here in this discussion, it’s not an easy issue to explain.
Shouldn’t it be easiest to define a Display working space in the Settings, that will be applied when Soft-Proofing is off? Then at least you know what is going on. By default that can be set to srgb.
before DPL6 you could choose the screen profile
now normally it’s like adobe LR:
photolab is supposed to automatically detect the screen profile (in windows) and therefore display the correct colors
… the default option, which adopts the Color Space setting from one’s camera.
… for explicit output to the sRGB color-space.
… More on this later.)
it hasn’t exactly encouraged me to use the new colour workflow, since it comes to a screeching halt at the point of trying to soft proof for printing.
