Yet more colour space confusion


The main track leads from the Source Image to Live Screen output

  • Items in blue are more or less under control of DPL
  • Colour conversions take place in three places
    C1a → colour conversion when the source file is copied to the latent image
    C2a → colour conversion depending on WCS and Softproofing settings
    P2a → display profile (calibration and native) DPL might know about it

The second track leads from the source image to the Target Image file

  • green dot → CM info based on export options

The third track corresponds to directly printing with DPL.


  • I suppose that we can see histograms of target image, the direct print image and live screen image. Which histogram is displayed depends on how we set soft proofing
  • I suppose that what’s shown in the histogram is derived from the latent image, modified by softproofing settings…which means that the arrows pointing to the histograms are showing what the histogram represents rather than the actual data flow.
  • As of now DPL can not show the source histogram directly.

Items in purple are not under control of DPL.

Who said things were simple?

Link is blocked

If by “output device” you mean the monitor being used when you’re working within PL (and you don’t mean the exported target file) then there’s a step missing for when SP=ON

  • there’s an additional (“hidden”) process included in your “Conversion to output ICC-Profile” step.

  • it’s an algorithm designed to “Protect Saturated Colors” in the conversion from W-G to the target ICC-Profile. Obviously, the “strength” (my term) of this alogorithm is specific to the target’s ICC-Profile.

  • This additional algorithm is applied when SP=ON - and when actually exporting to an external target.

  • However, it’s NOT applied within PL if SP=OFF.
    – For the implications of that, see here: Request/Suggestion: Fix to avoid being caught-out if NOT using Soft Proofing

  • It’s always applied when actually exporting to an external target regardless of whether SP=ON or OFF.

John M

the second is with sp.


Ok … but it still seems you’ve missed a step.

My latest post over here may help, George.


My diagrams are supposed to gain some understanding to what you see. Not how they get to look like that.
It explains the strange behaviour that within soft proof when you change color gamut the image doesn’t change but the histogram does. On my, and many with me, sRGB monitor.

I don’t understand your diagram. I count 5 histograms.
Your source image histogram is derived from the source image, file. If you mean the disk file, I 'm not aware of any histogram showing that.


It’s a fairly generic histogram that shows relations and flow/processing. It is both a logical and physical diagram.

The leftmost histograms cannot be seen in DPL. A RAW histogram can be seen e.g. in RawDigger. The histogram of the latent image is there for completeness. The histograms we see are always shown on our screen, but they depict different interpretations. Normally, we see the Live Screen Histogram, with soft proofing, we can see, on our screens, the histograms of the target exports, be it an RGB image file or a CMYK print. All images (screen, export) come from the latent image, which again is a result of whatever DxO does, including the allocation of a colour space.

We see quite a bunch of colour transformations

  • C1 level is from raw data to latent image - including the legacy vs. wide switching as well as all processing that results from what we select in the colour rendering tool
  • C2 level is, whatever DxO does in DPL - including soft proofing and output gamut switching, which does not currently reflect back into the histograms
  • C3 level is happening when an image is output on someone else’s screen or printer.

The profiles (P2…) for the (calibrated) screen and the printer reflect into the dataflow through the OS or the application.

The latent image might be virtual or exist within DPL, depending on how DxO designed processing.

That means that 4 out of the 5 histograms don’t exist in PL. And I miss the sp histogram.


Before an image is physically “realized” (that is, printed or displayed), the RAW data of that image are submitted to a great number of various computations. Such calculations should be as accurate as possible. Each of these calculation must be done with the highest possible precision. If the result of a given calculation is rounded before being submitted to the next one, the final result will be less accurate than if each computation is as accurate as possible. That’s true for any engineering calculation.

So, that’s why image computations made in 16-bit mode in a wide working color space are always more accurate than computations made in 8-bit mode in a narrower working color space. Even if the final output device doesn’t support 16-bit mode or a wide color space, the result will be more accurate than if the computations were made in 8-bit mode and in a narrow color space from the very beginning.


Except that gamut and bit depth are 2 entirely different quantities.
A 16 bit AdobeRGB is more precise as 16 bit profoto.


See this interesting discussion :

If you want a larger gamut then AdobeRGB and want to remain minimum the same accuracy, then you must use a bigger bit depth, 32. So for the sake of accuracy don’t use a larger gamut then needed.
2012, a long time ago. But he is saying the same as me. I don’t know what he has to learn more about color management.


I’m not talking about TIFF files, I’m talking about computations made in the working color space. Once these computations are done, the results obtained when exporting to whatever type of output you need will be better than if the computations made on the image representation in memory were made with less accuracy. Of course, I wouldn’t use 8-bit mode along with Prophoto.

It has always been recommended to work in the widest color space and with the highest bit-depth as long as possible until the image is realized. I’m working in Prophoto in 16-bit mode in all the editing software I’m using except with DOP/DPL, until now. Realizing the image is another thing and for example, I wouldn’t publish Prophoto RGB images on my web site, of course.

1 Like

I’m not talking about TIFF files either.
Let’s say the green color in Prophoto is 1.5 times larger as in AdobeRGB. So range ProphotoGreen = 1.5AdobeRGBGreen. So the minimal steps made in ProphotoGreen are 1.5 times bigger then AdobeRGBGreen, or 50%.
Further the larger the working color space is then the destination working space, the bigger the correction there has to be done.
One thought more. I’ve a sRGB monitor, so everything I see is in the color space. I do my edits based on that information. Where does a super large color working space helps me to do a better job?


w/o having read everything following yours … it does on my monitor ( → setup to sRGB ),
but there must be some ‘brilliant’ colours, otherwise I don’t see it either

Thank you for your diagram and explanation. They have given me a much clearer understanding of the process.

That’s due to the rendering

Sp set to sRGB.


This area is where the oog colors occuren. A saturated red with oog colors has these oog colors due to the colors on the left side of the histogram. The bigger the difference in gamut, the bigger the difference in result.

This histogram is sp set to prophoto.

Look at my former diagram. With sp is on the histogram and image are based on that sp-layer. The less difference between the used gamuts, the less difference between the images.

On a wide gamut screen you will see less differences.


Thanks for some more insight. :slight_smile:
( had not watched the histogram so closely )

When toggling SP → sRGB on/off, I also could see a clear difference in the preview.

[ btw, to change the monitor’s colour space from AdobeRGB to sRGB, I choose one of the custom calibrated profiles and restart PL to ‘pick up’ … ]

Playing w/ available (and imported) SP profiles and Destination gamut warning on showed, that
SP is independent from not related to the monitor colour gamut,
→ which allows to work on a out-of-gamut pic (like the one in question) on a sRGB capable screen and export to the wider colour space, while of course the screen’s rendition limits what one sees.

Try your monitor icc profile. Then you will see no differences. Look at my diagram again.

In this photo of @Joanna it is said that the saturated colors cause an oog situation. I don’t know if you or the others know what saturation means. I must confess it’s new to me too. Saturation is the ratio between the dominant color and the other two colors. The bigger the difference between these, the more staturated the dominant color. But that also means that the other two colors are getting oog since the oog colors are on the lower side of the gamut.
Search for the formula of saturation.


I know (applying a custom monitor profile), but I’m interested if/what I see in SP. :slight_smile: