Question for DxO - regarding the new Working Color Space

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

There’s a lot you’re not telling us that might be influencing the final rendering. What are the settings in the Color Rendering palette when using Classic WCS? When using Wide Gamut WCS? What are your export settings in PhotoLab? Did you try Soft Proofing to see if that changes the rendering in the image viewer?

One way to clarify settings would be to repeat the test with the original file and three virtual copies.
Once done, attach the .dop sidecar file and we can check for hidden traps.

Sorry, missed the RAW file. So I downloaded it and played with it a bit.

The rendering of the flower petals in the Classic working color space is more yellow. But red is very clipped - that is, out of gamut. With the DxO Wide Gamut WCS, raise “Protect saturated colors” in the Color Rendering palette. That will reduce red enough to see the yellows. Especially if you use DxO Camera Profile and not Neutral color, realistic tonality. (The former converts the color data better for a display that isn’t wide-gamut such as sRGB.) I’ve concluded that this approach lets PhotoLab do most of the work in converting a very saturated image for a smaller color space.

If you don’t do this, then red has to be managed through other adjustments. Turning on Soft Proofing for sRGB will tame it a bit, but not as well as if you use the Protect saturated colors adjustment in the Color Rendering palette. To see what I mean, turn on the destination gamut warning, select the red channel in the HSL tool, and lower the saturation.

The yellows aren’t as vibrant as with the Classic WCS, though. I’m still playing to see if there’s a way to more closely approximate the Classic rendering for sRGB. But it isn’t straightforward.

UPDATE: I raised the Rendering intensity in the Color Rendering palette to 200 (with Protect saturated colors set to an intensity of 67). This made the flower more orange (taming red), but darkened the background. Weird as it is to set the intensity so high, I think the overall tonality and color preservation are now far superior to the Classic WCS version. Give it a try and see what you think.

It seems using the HSL to try to intensify orange or yellow doesn’t work, because it’s the red that’s the problem.

downloaded your raw-file and played with it
(smartlighting off, but highlights reduced from 255 to 253)

  • when you set PL6 to Classic-Legacy you lose a lot of saturation in comparison to Wide Gamut
  • now export that CL as ProPhoto.tif and you keep the same colour (converting from AdobeRGB to ProPhoto doesn’t add / bring back saturation)
  • export the CL → ProPhoto.tif to sRGB IEC61996-2.1 and you get almost the same colour, just a little flatter / darker – and interestingly the same as from the direct export CL to sRGB IEC…

  • did the same in WG, where the export as ‘true’ ProPhoto.tif is much closer to the ooc file
  • comparing the direct export from WG to sRGB IEC… with the one via ProPhoto.tif
    shows a stronger loss of saturation, which I image imagine could be due to handle more oog colours at once than when exporting from the intermitting ProPhoto.tif

btw – all softproofs looked very close to their equivalent exports

Thanks all for the input all, i’ve played around with the file some more with some suggestions and realise this image is tricky with its over saturated colors. the protect saturated colors does help but not great. using the color picker on the yellow orange helps a little as can clearview and some tone changes but what has helped the most is changing the profile to canon 1dxmk2… for this image it improves the yellow and the orange petals to how it should look. So maybe its in part an affect of the A7M4 profile along with over saturated colors and the wide gamut interaction.
I wonder if the camera color profiles have been reprofiled with the wide gamut?
The good news is that on some more normal photos the wide gamut looks fine but I still wonder about the way dxo is handling over saturated colors.

Why is Time Machine film simulation using the legacy gamut instead of the dxo wide gamut? For example “2000er” “Fuji Velvia 100”.

I don’t think so. Imo, camera profiles are “absolute” and not tailored to a user dependent working colour space. If that’d be the case, we’d have several profiles per camera. One each for sRGB, one for AdobeRGB etc. and every picture style (portrait, landscape et.).

Be careful not to confuse working color space with color rendering or output color space. The rendering can be different with a wide gamut working color space, necessitating a different preset, but the output to the monitor can also require color conversion.

Sorry guys
did I miss someting with the soft proofing?

I’m on Windows at the moment and can’t choose to simulate Paper and Ink
image

Thanks

As the mouse-over tooltip (should) tells, that’s coming soon :slight_smile:

1 Like

Thank you…it’s very well hidden
image

That’s quite well hidden indeed. On my machine the tooltip is aligned with its left side directly under the mouse pointer. The header of the other section being (almost) the same color doesn’t help :smiley:

A bit late to this thread, but I’m also interested in this, John7. Hopefully we’ll read/ hear more about it, but I’m afraid DXO still doesn’t support 10-bit colour editing (like Photoshop does).
Wait and see….
But maybe you got more information about this since Oktober?