Colour Management in PL6



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:


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.


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


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.


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.


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


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:

You can check this with a file containing out-of-gamut colours and move it (PL6) from one screen to the other with Monitor gamut warning ON.

→ seems to work ←

1 Like

I do not own pl6 :grinning:

Yes, I can confirm this :grinning:

Hi all,

here is an updated diagram with the latest information on PL6.3 and the two white papers released by DxO with PL6.3. The usual disclaimers apply :slight_smile: -)

I hope you find it useful and as usual, comments are welcome.

1 Like

Then you don’t have to confuse yourself.
You have only Legacy Working Colorspace.

Yes, but I’m following the thread with interest to know what works and what doesn’t, and I’m hoping for a complete, clean implementation including softproofing and a technically proper explanation of the technical background as would be expected from a “global player” in the field of graphics software. :smile: