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.
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.
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.
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.
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.
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?
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.
Thanks for some more insight.
( 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.