Hi John,
I have no problems w/ VCs – except after a while I don’t remember, what they were meant for
and try to find out with
This is where you need the Windows version to get the Mac feature of being able to rename virtual copies. It is so useful
4 Likes
Currently, with PLv6, if you expect what you see within-PL in your Step#2 (Edit Image) to be always, consistently & reliably exactly what you see in your Step#3 (Look at the result and share with others) - then you will need to have Soft Proofing = ON. … … … Why? - - - See above.
And that’s pretty much the point of my proposal, Joanna
-
For those who don’t want to even think about Soft Proofing … including those who don’t understand why they should need to - I reckon PL should always work with WYSIWYG behaviour, by default.
-
Instead, with PLv6’s current implementation, sometimes (but not with all images) that will not be the case; it will be mystifying to the average user, and that will impact confidence in using PLv6 …
If my proposal were to be implemented (or one of the variations of it, as suggested by @maderafunk and @KeithRJ) then we could all go back to ignoring Soft Proofing until we really needed it for some specific purpose … such as printing or export to different color space(s).
That is the result I’m aiming for.
Yes - If you’re expecting the WYSIWYG behaviour we enjoyed pre-PLv6, in all cases.
- It’s incorrect to assume that SP is needed ONLY for printing.
- This is the precise issue that this proposal is addressing - - I reckon PLv6 should “fail safe” … instead of setting-up unsuspecting users for a (probably mystifying) surprise.
Why? - - - See above.
And now, with PLv6, SP=ON is advisable in all cases - including for simple export to digital files … NOT only for printing. Why? - - - See above.
They’re all good points, Wolfgang - but, that’s not the issue under discussion here. My concern is that PLv6 sets-up unsuspecting users - who, in good faith, adopt WCS=WG - will eventually get caught-out if they do not apply Soft Proofing for all images they’re processing — NOT ONLY for printing.
Unfortunately, that’s no longer the case … Why? - - - See above.
Keep the questions coming … I feel we’re “getting there” !
(Apologies for my repeated referral to the background info above; but I reckon it’s best that I don’t confuse matters by continually repeating the explanation).
Sounding good, Keith - as seems it would address both our concerns (Win/Win 
)
But, I’m still not quite sure what you mean by; {Make PL6 behave exactly like PL5 …}
- Could you elaborate a bit more (again), please Keith … In what way "Same as PLv5 " ?
John
Quite simple actually:
- If SP=Off then make PL6 fully WYSIWYG as with PL5 no matter which WCS is used. This includes the ability set your monitor profile that was removed from PL6
- If SP=On then make PL6 behave as it currently does. This must include adding compare against the original image WITH the SP profile applied but no other corrections other than currently selectable options (with/without geometry) to the compare button.
Hope that clears things up.
OK - I reckon I’ve got it now - finally !! … (Apols for my slow take-up - In retrospect, it was obvious).
But, let me paraphrase to be sure I’m truly on-the-same-page with you …
-
With SP=ON - no change is required to PLv6 bahaviour.
-
With SP=OFF - then the following changes are required to PLv6
-
Re-instate ability (in preferences) to specify the ICC Profile of one’s monitor
- - as it was with PLv5
– with “Current profile of the display device/monitor” as the default. -
When SP=OFF, the additional Protect Saturated Colors algorithm (that’s currently applied only when SP=ON and also for the Export to Disk process) is applied for the ICC Profile specified in Preferences.
– This ensures the “holy grail” of consistent WYSIWYG
Plus some additional, essential, refinements;
-
When using the Compare option, regardless of whether that’s with Geography or without, the same behaviour as above (1. & 2.) must also be applied.
-
In the Export to Disk dialogue, the ICC Profile option should default to “Same as Soft Proofing” (rather than “As Shot”) … as another “fail safe” step in protecting unsuspecting users who may have their camera settings = Adobe RGB, without appreciating the unintentional impact).
If that’s what you mean then I’m totally on-board … this would solve all current issues. 
… Thanks for your help in getting this across, Keith … Hopefully, my proposal will now attract many more votes 
John M
I have not yet upgraded to PL6.
But having worked in the printing industry for decades - soft proofing is a simulated view on how the current page/image/photo will look like after it’s been printed or processed.
It’s temporary preview which one can toggle o or off for a quick view on how the final resume will look like.
It’s nothing that should be permanent, included in the files or otherwise affect the production.
If that actually occurs in PL6, then DxO is either using the term “soft proofing” wrong or their color management is processing the profile simulation incorrect.
That’s all completely true of PLv6 too. There’s nothing about PL’s implementation of SP (in and of itself) that’s permanent.
However, for the new Working Color Space = Wide Gamut, when PL exports one’s image to disk (via Export to Disk) …
-
it applies a “secret sauce” algorithm to ensure that colours from the WG color space fit “appropriately” into the target color space (such as when exporting to sRGB - but equally to any Color Space inferior to Wide Gamut) … Ditto when exporting for printing.
-
this additional algorithm is applied in the cases above - and when SP=ON … to ensure that what-you-see (WYS) in Soft Proofing mode is what-you-get (WYG) with the exported image.
-
however, this additional algorithm is (currently) NOT applied when SP=OFF … – and this is the issue I’m aiming to resolve - because, in this case, WYS (is not necessarily) WYG !!
– as explained in a LOT (!) more detail here.
John
Hi @John-M
Sorry to be so persistent but, despite all your excellent explanations, I find myself entrenching more firmly in the camp for not upgrading to PL6.
When I used to use Photoshop (CS3) all I did was setup the default working space for all images to be converted to on first reading - I used ProPhoto RGB.
This meant that all images were converted to that colour space and I didn’t have to care any more.
When I printed directly from PS, all I did was tell PS to manage the output profile and selected the appropriate profile for the printer/paper/ink I was targeting.
No soft proofing, no nothing, but every print came out as expected. I can only assume that the default viewing mechanism took care of mapping because I never had to dow anything explicit to get my prints right.
Now - all of a sudden - PL6 dictates that I have to complicate my workflow and virtually insists that I do soft proofing, even if all I want to do is export to an sRGB JPG file.
Yes, I am a total techie nerd, a computer programmer who has written extraordinarily complex code and an LF film and digital photographer who has held exhibitions.
You are also equally experienced and techie minded, otherwise you wouldn’t have participated in the beta test to try and help DxO find bugs.
But, what about those people who just want to take the photos of their family and friends or holidays and distribute them on the web? Are DxO really saying that they have to get into all this colour space “stuff” just for that?
I know perfectly well I have enough trouble teaching PL5 to members of our club photo, without having to now sit them down and explain about having to use soft proofing, just for web sharing or emails.
All most folks want to do is use a transparent process to open, edit and export their photos, as they see them whilst editing. Why should they have to go through the contortions of making a virtual copy, turning on soft proofing, fiddling around to eliminate OOG warnings, etc, etc, just for that use?
If it were my proposal, it would be to simply be able to preset the default workflow and, if that implied soft proofing, then just allow all editing on the soft proofed version by default.
A.A.Milne, writing for Winnie the Pooh said
“When you are a Bear of Very Little Brain, and you Think of Things, you find sometimes that a Thing which seemed very Thingish inside you is quite different when it gets out into the open and has other people looking at it.”
There are a lot of us who are “bears of little brain” who really don’t want to have things more complicated than they already are.
5 Likes
That is not possible on a Mac. As far as I can tell, the default is always AdobeRGB.
Seems that DxO have mixed something up.
Soft proofing should never affect anything being output.
When going from a larger color space to a smaller one - like aRGB to sRGB - there’s two way of doing this.
The hard transformation way.
You convert/compress the larger color space to the smaller which causes the final file to be within the smaller space. This without any need on embedding any color profile or force the system on which it’s viewed on to display it a certain way.
The soft transformation alternative.
You do not compress or convert the larger color space to a smaller one. You simply embed the profile of the larger space into the exported image and let the receiving system do the transformation. The receiving system will then transform the larger color space defined by the embedded profile into it own or targeted system defined or chosen smaller color space.
This soft way ensures and enables the image to be output to different target systems with different quality or color spaces.
But it put some demands on the system to have a color management and force the users to manage it properly.
So according to your description DxO is doing a hard transformation from wide gamut to smaller one. That’s perfectly fine.
But they seems to be mess it up when the soft proofing profile is enabled and used.
There’s the bug as I see it.
2 Likes
They have created a problem and not a solution that most are willing to mess about with. Some users will have just a few images to output others large number. I usually have between 10 and 30 and to work on with the cumbersome process we are expected to fallow isn’t workable. So poorly thought out that DxO haven’t even had soft proofing opened in a virtual copy but leave you to do that. As said above the poor work flow of the current virtual copy adds even more to doing all this. I have 6 and am thinking of going back to 5 and if DxO don’t get it sorted I fear it would be the last version of PL I will be paying for.
2 Likes
Dear John,
but I think only then when this setting is implemented?
1 Like
I just did a list of “new” features that are supposed to make PL6 worth upgrading to:
-
DeepPRIME XD
- OK but, so far, I haven’t needed anything more than DeepPRIME
-
WGCS
- Until DxO announced it, I never knew I needed it. Maybe it’s useful but…
-
Soft Proofing
- Never needed it in over 15 years of processing and printing alll sorts from scanned LF film to digital images. Still not convinced it adds anything.
-
ReTouch
- Looks good - if it wasn’t so bugged.
-
Colour Labels
- I use an external DAM and use macOS Finder tags, which are far more flexible.
-
More Metadata
- I use an external DAM so this doesn’t interest me. I am still convinced that the DAM functionality should have been deployed as a “plugin” like FilmPack or ViewPoint
-
Project Organisation
- I use an external DAM for organisation and selecting images from one of the DAM searches automatically creates a temporary project in PL5.
So, all in all, for me, very little value in an upgrade from PL5
4 Likes
Yep - that’s a quirk of the impact imposed by that additional PSC-algorithm being applied (except when SO=OFF). I doubt very much that this was a “design feature” … more like an “unintended consequence”, that I’m proposing be fixed.
This is precisely the problem that I’m proposing be fixed, Joanna - - as I doubt very much that the “average” user will have any inkling at all that Soft Proofing is advisable in the simple scenario you describe !
- Note: It’s not that it will always be the case that “WYS(is not) WYG” … it’s image dependent (for images without saturated colors, it may not even be noticeable) - - But, it’s exactly that variability that will probably surprise and perplex users … 'cos it will be fine - until it isn’t !
That’s all I want too - - and my (refined by “crowd-sourcing”) proposal aims to return us to exactly that experience - as we enjoyed pre-PLv6.
- Note: The VC contortions, etc will still be required if we are SP-ing for printing purposes and converting color spaces … but that’s not applicable to the majority of PL users.
Excellent; we are “as-one” on this then … 'cos that’s exactly the aim of my proposal.
{That is not possible on a Mac} - I was advised by a DxO engineer that this is do-able.
- Was that not a Preferences option with Mac-PLv5 ? - If so (= not a v5 option) then Mac-PL must be determining the ICC-Profile by some other means - as it’s required to be able to do-its-thing.
{As far as I can tell, the default is always AdobeRGB.} - All Mac monitors are Adobe RGB ??
- If that’s so then it still doesn’t change anything; All that’s needed is for PL to understand what the ICC profile is for the current monitor, so that it can apply the appropriate PSC algorithm - even when SP=OFF.
PS. I truly hope I’m not coming across as just pedantic & defensive - - the reason I’m addressing every point raised is that, by doing so, I’m aiming to have this issue well understood (and fixed).
John
True - as we have already agreed: The point of SP is to emulate the result we will see when we export the image - so that WYSIWYG.
Let me address your concern with a different approach;
-
If you have processed & tweaked your image (within PL) and are now ready to export for printing, or for conversion to a different color space … Would you expect to need to use Soft Proofing ?
– I’m guessing you’ll say; Yes, of course ! -
Alternatively, if you just intend to export a digital file to display on your own monitor, of for sharing with others, or posting on-line … Would you expect to need to use Soft Proofing ?
– I’m guessing there would be a lot of users who would say; No … or, “what’s Soft Proofing ?!”
– and those are the very users who will be (eventually) caught out.
– Why? - - - See above.
Unfortunately, not with current PLv6 behaviour … See my response to @Required … just above.
Also, see here.
John
Don’t bail-out just yet, John … This issue is proving to be tricky to explain - - but it’s just a matter of getting some basic PL behaviours sorted out … … … … Please help out by voting.
I’m still a big advocate for the new Working Color Space (WCS); because …
John
Don’t worry @John-M : Since when are many votes guarantee for changes within PL? 
Funny thing: To use SP with my printer and my papers, I’d need to put a list somewhere to decode the cryptic profile names. Epson must employ some geniuses, as they allow me to define output profiles with clear names, preferably the ones on the paper boxes instead learning another naming system.
If I look at this list, I just feel unnecessarily overwhelmed. Who on Earth would softproof for the own monitor profile? Edit: On the Epson list only printable media appears.
2 Likes
The image we will see where? You image on my screen? Hardly, as you don’t have my monitor profiles. So I think it’s important to narrow that general statement down to “what somebody else will see when using a device I had the profile for or looking on my printed images.” And then the question still remains “in which light? with which brightness setting?”
“Proof”, as far as I’m aware were used in the old days to emulate the outcome of big magazine printing machines without needing to stop the expensive device. Instead having a proof printer which was closely calibrated to the results the big expensive machine would produce. By Softproof the emulation idea goes on step further and tries to simulate the outcome of a printer on a screen. So, two different ways of lighting the image will always show little differences. Emulation can’t fully simulate the experience of seeing the finished paper print. But it gets a s close as possible.