Colour Management in PL6

@Guenterm thanks for the link to the tutorial, there is some useful new information there that I can use to update my diagram :slightly_smiling_face:

Sorry, you don’t get it.
The working color space is a color space where in the calculations are done . If that image is send to the monitor it has to be converted to the monitors color space. Also when you send it to the printer it has to be converted to the printers color space. This can be done directly as shown in figure 26.1 or it can be done as shown in figure 26.2. The last one is the easiest, especial when dealing with more color spaces.
Beside this, I think PL is using the color management system of the os.

George

1 Like

I wasn’t aware Windows OS had a colour management system? Unless you are referring to the newly introduced colour management option in Windows 11 2022 Update “Auto Color Management (hardware accelerated system level colour management), which ensures that all colors across all Windows apps, whether or not they are colour-managed, appear accurately and consistently on every supported display”?

Windows has its color system. And again as far as I know, PL is using that. But I think all editors.

See “operating system level”

George

Hello Keith,

When you update your diagram please don’t make it too complex so that my head doesn’t explode.

Reading all the posts I always get the feeling that from time to time terminology gets jumbled up, which doesn’t make it any easier, but I’ll just ignore that now.

However, I do wonder what DXO was thinking when they introduced the DXO colour space instead of sticking to established procedures and using ProRGB or similar. Then there is also the unimplemented soft proofing
all this doesn’t make it any easier.

I referred again to the 12-part series on colour management for photographers by Eizo where everything is explained well, in my opinion, even for people who are dealing with the terminology for the first time. In the last chapters on the programmes LR and PS you can also see how a logically structured workflow and the implementation can work. Perhaps the developers should also take a look at this.

The whole area of colour management and printing is simply not implemented well in DXO, which can be seen in many posts that either say not to use DXO PL6 or to use software from printer suppliers such as Epson or Canon for printing.

Perhaps everyone will take the time to read the Eizo series at their leisure.

But also a big thank you to you and the other comrades-in-arms who are trying to cut a path through the DXO thicket.

4 Likes

Our biggest problem is that DxO tries to provide a backwards compatibility in colormanagment.
The old AdobeRGB workspace has a different input, (more compressed rendered) and thus a different color changing effect when you edit tonality. (because the edges of the workingcolorspace are more effected by the compression of Protect Saturated Color algorithm.)
We never noticed that as a problem because we did think it’s as it is.

Now we have two latent images
1 as converted in AdobeRGB
2 as converted in Wide Gamut.

The wide gamut’s colorspace edges, the near saturation, are less visible due the fact you export often in a much smaller colorspace so the relative or perceptual rendering smooth out that effect of there PSC.

I hope that the raw to working colorspace choice get converted to choice of clipping area.
Like a soccerfield for adults and inside a smaller soccerfield for kids.
You adjust only the lines of end of playingfield not cut of the grasplain.

By creating a choice how histogram, clipping tools as sun and moon are reacting, and a manual PSC tool like the softproofing has you can edit a image down inside a large colorspace towards your choosen export colorspace.
(when you activate softproofing for AdobeRGB and create a virtual copy which you edit down until all the “RED” alarmplanes are gone you do exactly the same only without visible preview WHICH channel is fully saturated/clipped.)

By having one raw to working space convertion algoritm and PSC the change of color shifting is much easier to tackle because of one pipeline and not two different starting points.

Exporting old rawfiles who are editted in say v3 don’t look the same anyway as the first.
New denoising, better microcontrast plus and other new tools.
It’s an illusion that backwards compatible of sidecars like dopfiles are flawless in recreating the export image again a few versions later.
And with this workingcolorspace size jump that got extra visible.

Editing.

George

Windows may have a colour management system in the code but it doesn’t use it at OS level. Even the Windows desktop isn’t colour managed. Mac has colour management at OS level.

I believe it’s an API different programs can use.

Don’t ask me further about it. :worried:

George

1 Like

Windows’ most fundamental problem, right there. An inability of Microsoft to cut ties with the past.

Ha! Maybe. But backward and forward compatibility can be a good thing too – no? If it’s clichĂ©s today, how about this one? Stay within Apple’s walled garden, everything just works. Step outside that walled garden, better call Microsoft. Just kidding, - really - it’s all good.

1 Like

Hello all,

I have updated the diagram to V1.2 where the Soft Proofing section has been changed to better reflect what we believe is actually taking place. Some other wording with regards to PSCA has also been updated.

Thanks again to @John-M for his valuable input.

3 Likes

Dear Keith,

thanks for all the work you and all the other members have done to explain how it could be :grinning:

The part that always leaves me undecided is the branching around the “Working Image” with the “For each edit”.

The “Working Image” is displayed completely with the corresponding monitor profile on the monitor.
If you edit the image, it will not be converted to the monitor profile again.

Or do I see and understand this wrong?

Wouldn’t the sequence “Open Raw File in PL” - “Convert to working space” - “assign Monitor Profile” - Show File in Standard Preview on assigned monitor" be better?

And what happens if you move the image from monitor 1(default) to monitor 2 which may use a different monitor profile? Then nothing is changed in the image, but another profile would have to be assigned, whereby of course the color space used remains identical.

Please let me know if I am completely off the mark :crazy_face:
best regards

Guenter

Hi @Guenterm ,

let me try and explain why I believe this is how it works (I may be wrong but we have no way of knowing for sure because DxO has not published how it actually works).

The Working Colour Space (WCS) is where the image sits while being edited. In other words, all edits are applied to the Working Image (WI) which is in the WCS. The whole idea of the WCS is to preserve as much colour information as possible while editing.

In order to “see” your edits, the image must be displayed on your monitor which cannot display all the colours in the WCS. So in order to see your edits the image must be CONVERTED (most likely in a separate image space for display purposes only - lets call it the Display Image (DI).

In order to show your edits which are done in the WCS, you need to convert it into the monitor profile and display it via the DI. So for each edit made to the WI you need to convert to the DI in order for you to see your edits.

Evidence for this procedure is the presence of the Monitor Gamut warning button in the Histogram.

No, edits are done on the WI which is in a different colour space to the monitor, so for each edit you make you need to convert to the Display Profile again in order to display the image, as explained above.

Assign Profile and Convert to Profile are two very different procedures. Assign simply associates a profile with an image without changing any image data, even it there is out of gamut data. Convert actually changes out of gamut image data to fit within the profile being converted to.

The Colour Rendering settings will also need to be applied when converting to the DI. The Colour Rendering settings control how the image is changed from the WCS to the DI and ultimately to the final output which is normally an even smaller colour gamut.

I have this exact setup where my Laptop display is P3 and my other monitor is slightly better than sRGB. PL6 reads the display profile set in the OS (I use Windows and have calibrated my displays and assigned their profiles in Windows settings) and uses these as the display profiles to convert to when displaying your edits. I do know that you have to restart PL6 if you change profiles and assume this is also true if you want to work on the second monitor.

I have tried to test this using the Monitor Gamut Warning and can see slight changes but cannot be sure that the second monitor’s profile is being used.

I hope this helps explain my thinking for the diagram and clears up some of your confusion.

2 Likes

There was a typo in the third PSCA box of the Key which has been corrected - “to” has been changed to “on”

And this also happens with the soft proof. With the same arguments. :grinning:
Except that I don’t think another image is created first. I think the conversion happens ‘on the fly’. But I’m not sure.

George

Yes, probably rendered straight to video memory.

Good morning Keith,

Thank you for taking the time to explain this to me.

I’ll take my time over the weekend and hope to be a little less confused :upside_down_face:.

A nice rest of the week wishes you

Guenter

You’re most welcome :slightly_smiling_face:

PL6.3 now provides “support for color profiles in multi-display setups” acording to the release notes. I don’t know how this is implemented because no additional info is given :thinking: