Question for DxO - regarding the new Working Color Space

You clearly feel strongly about that. But is it possible that your understanding of how the internal working color space relates to an sRGB output is incorrect? At the moment, I’m not seeing the problem you’re seeing. In fact, in PL6 you can always select the Legacy working color space instead (which is Adobe RGB), but honestly I don’t see why one would want to just because the output/export color space is sRGB.


But that’s precisely what PLv6 allows; image

… and, to automate your choice of specific preference (New Wide Gamut OR Classic/Adobe RGB) - simply assign that WCS setting in your default Preset.

John M

1 Like

Hi John

It seems that a very interesting link has disappeared from the help page


1 Like

I can only add to the speculation. I think by using the wide gamut option, the algorithms can preserve more and work with more before it’s converted to the display space or the selected output space on export.

It could also help in preserving the color information in very bright parts, and might also help in handling colors and brightness more to how our eyes are used to interpreting color.

This can help things like the color wheel, but also ‘smart lighting’ and other modules to better handle color under different lighting conditions.

Darktable has made major strides in debunking the older, known ‘perceptual’ color spaces.
But, they also think / know that linear rec2020 is perfectly fine as a working space these days, so why would DXO not just use that?

Having a quick look at the OKLab website can also help. You don’t have to understand the maths, but it will quickly demonstrate what is wrong with older attempts to separate color from brightness.

Your hard at work!:sweat_smile:
I think this new colorspace is all about pipeline.
Like using pipes on water flows.
The faster you end up in narrow pipes the slower the water flows per liter.
(edit, in this case your losing faster nuances of color in a earlier stage.)
Most of the users are fine with AdobeRGB as export and probably working colorspace.
Why would you work in a wider colorspace and let algorithm automatic squeeze the cake in a smaller box if you can bake the cake in the same size?

Fact 1
Saturated color protection tool works from rawfile to demosiaced image in working colorspace. (read this as when the colors are calculated from rawfile they wiggle all data inside the working colorspace.)
Fact 2 i stil don’t know for sure if changing a color by shifting exposure is shifting that color calculated out rawfiledata and is before outside colorspace is untouched moved inside or that they simply modify the earlier calculated color to it’s new spot in the workingcolorspace.
So a plus for the Wide ganut is then not much needs to be recalculated when your in development modes. It’s all in there. (saves calculation power.)
I minus is it’s compressed towards your monitor gamut so it’s stil a fantomcolor you see. (which we already had with AdobeRGB so who cares?)

Pipeline shows that if you use toggle wgcs vs legacy in the end of your colorgrading edit you can use “sun and moon” too as visual check for clipping on edges of colorspace.
And montitor button as a quick check for clipping on sRGB.

In short if your not in to very professional printing WGCS isn’t realy needed but it helps you to visualize the differences between colorspaces and there related influence on your image.
Same as softproofing. It helps you to learn to understand and see what’s in the deep dark forrest behind the trees so you can walk more straight with out the danger to get mucked by wolves :yum:

In practise most of us are safe and fine editing in AdobeRGB(Legacy) most of the time until you managed to capture a stunning sunset or some other magnicifent colorfull picture. That is the time you switch to WGCS and squeeze all the juice out of your rawfile in order to have the best optimasation to let it be printed in a lab.

1 Like

G’day, Peter … Yes, I’m hard at work trying to comprehend the benefits vs gotchas of the new WCS.

Regarding benefits of the new WCS; I’ve seen the following explanation (which I originally posted here).

If you have a sRGB monitor:

  • In PL5, colors outside AdobeRGB were modified so that they can fit in the AdobeRGB color space. Then, when converting them to sRGB, it was converting a modified version of the original color.

  • In PL6, colors outside AdobeRGB will be kept because it now uses the DxOWideGamut. Then, when converting them to sRGB, it converts the real original color (not the modified one).

I reckon that’s a good reason to use the new WG-WCS - even if our intended target is just sRGB.



but crucially it does not allow control of the rendering intent from either the new wide gamut or from the classic (Adobe RGB) gamut to sRGB.

Not allowing such control that is a major failing of what is supposed to be a top flight RAW converter.

1 Like

Yes that is the pipeline principle. The more adjustments and steps of adjustment the more variables are rounded each time.
My point is if the DR and colorrange of your Raw-image is inside the AdobeRGB, which you can see by toggling colorspaces wile sun and moon (highlight and shadow clipping) is active and looking at the saturated color protection in auto modes there is no real advantage working in Wide Gamut.

Dxo staf could be answering the bottonline question of in which part the colors are most natural rendered (less damage).
From rgbg to working colorspace AdobeRGB and edit to jpeg sRGB.
Or rgbg to working colorspace WG and edit to sRGB.

Aka a 2 step pipe diameter reducing or a 1 step significant reducing the pipe diameter.
Which type causes more turbulence?
With water i know the answer but in colorspaces i gues it depents on the amount variables that are rounded and thus lost for the next step.

1 Like

Can you elaborate ?

Yes, please elaborate, because the rendering intent selection is in the Soft Proofing module, which should always be used if you want more precise control of how PL6 renders an image in sRGB or anything else. That said, DxO does do some automatic operations in the export or soft-proofing stage to protect out-of-gamut colors regardless of rendering intent: does this bother you?

Rendering intent (perceptual / relative /etc.) controls, for want of a better expression, how colours in a wide gamut that are outside a smaller gamut are ‘folded’ into that smaller gamut.

Not being allowed to choose how PL does that is, in my opinion, a failing. Affinity Photo’s internal working space is ROMM RGB (aka ProPhoto) and it allows the user to set their preferences for rendering intent.

These rendering intent options are separate from the rendering intent required for soft proofing.

DxO envisions that we will use its Soft Proofing module for all output purposes - all kinds of rendering. Printing, export to file, and even output to the monitor (which surprised me). So for each we create a virtual copy, have soft proofing on, and specify the rendering intent and make other adjustments as needed to correct out-of-gamut colors.

Where else in DxO’s rendering pipeline does rendering intent need to be specified, if the working color space is large enough for all input color data? I suppose it might be desired if using the Legacy working color space, but that’s a novelty isn’t it? Why not just use the DxO Wide Gamut working color space for which no folding is needed until actual rendering for output?

Maybe I’m confused, but I just don’t see the need for more than what DxO is providing via Soft Proofing. It might be weird to use soft proofing for a smaller-gamut display as well as actual export, but I guess DxO wanted to create a multi-purpose tool such that rendering intent doesn’t need to be specified in more than one place?

It all lies in the difference between the actual colors of the exported files and what I see in PhotoLab. PhotoLab works with a wider color space, my monitor shows me these colors because it supports them, but when exported the colors change slightly (because they are converted to sRGB). It’s a waste of time… with over 100 photos I process every day, that’s a lot of wasted time…
I would not like to limit the color space of the monitor because there are times when I get files in AdobeRGB.
I will gladly pay for software that saves me time. But when I waste my time sooner or later I will have to give up software whose design I generally like. In short: “Nothing personal, just business”.

I need to be able to select sRGB for workspace…

…which seems to be impossible (in DPL) according to what @wolf wrote in January 2019:

If the input image is a RAW image, independently of the color space you selected in your camera, the raw input colors are neither in AdobeRGB nor in sRGB, but in the native color space of the sensor of your camera. In that case, PhotoLab converts the sensor colors to AdobeRGB and uses that as working color space. This cannot be configured. During export, you can choose between “as shot” (which converts to the color space you set on your camera) and converting to sRGB, AdobeRGB, or any other color space explicitly. Note that for AdobeRGB, no conversion takes place.

1 Like

The problem is easy to solve

  • allow the user to determine the default WCS – DxO Wide Gamut or Classic-Legacy.
    While it does not give the option of a sRGB WCS (see the explanation by @wolf),
    everybody happy with PL5’s solution will be so with PL6.

  • If needed, the user now can also softproof before exporting to sRGB IEC61966-2.1

  • or try & decide for DxO Wide Gamut …

E.g. in PS one has all options and I don’t think, it’s unprofessional to give the user the choice.

I just noticed something unexpected with this new wide gamut.

If you use wide gamut and export a raw file directly to jpeg using srgb profile and then take the exact same raw and export the file to tiff using prophoto color space and then export that tiff as srgb jpeg.
Then compare the 2 jpegs. They can be significantly different which i didnt expect.
I have a flower photo with predominately orange and when you export using wide gamut directly to normal srgb jpeg it seems to remove a lot of yellow compared to going via tiff…
Dont think i like this wide gamut for srgb exports at least…

Just tried what you described with two different pics, both w/ critical oog colours – no serious difference between those exports. Parts of their histograms changed slightly, but no by a bigger margin.

(Eizo CG2730 / set up to AdobeRGB)

On some images there is little difference as you have said but on others the difference is not acceptable.
Have a look at this link with 4 images and the raw.

Images were taken exported with dxo standard profile with smart lighting off as srgb jpegs

The jpegs are
A. Classic legacy gamut export straight to jpeg
B. Classic legacy gamut exported to tiff with prophoto profile and then exported to jpeg
C. Wide Gamut export straight to jpeg
D. Wide Gamut exported to tiff with prophoto profile and then exported to jpeg

Why is there such a difference between C and D?
What has wide gamut done with the yellows… looks desaturated.

…creating the D JPEG involves more colour transformations. They contain all kinds of (nonlinear) calculations, which makes results different for colours that linger around the edges of a gamut.

Just because the result of processing A is a JPEG does not mean that a JPEG done with processing B should be the same…even if both come in sRGB.

In order to “fit” OOG colours into a gamut, such coulours need to be “moved” towards the center of the gamut…which desaturated the colours.

1 Like