Btw. is fixed now with the first update.
“How should these OOG tones be addressed?”
Mostly like I do: by ignoring them. It’s good to know that some tones will not be reproduced faithfully when exporting to a smaller color space, and which areas will be affected. With PL5, you had no way of knowing.
And this may lead/entice the user to adopt a wider color space for export. I most often use sRGB for reasons of compatibility with customers/printing services (mostly books). But it’s good to know exactly where the limitations are, and to know how much improvement one could have by changing external printing service/personal inkjet printer/monitor with one that has a wider color space. But otherwise, don’t worry too much about it, and don’t desaturate your images to avoid “soft proofing warnings”: your images will look great even if (like I do!) you usually are forced to export to sRGB. It’s a simple warning that they would look even BETTER (and only in some very specific areas, shown by the blinkies, mind you) if you were able to export/print to a wider gamut.
2 Likes
Just to be sure we’re talking about the same thing.
I made 2 simple diagrams.
Without softproof.
And with softproof.
Any comments?
George
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.
Histograms
- 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.
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.
@platypus
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.
George
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.
George
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.
4 Likes
Except that gamut and bit depth are 2 entirely different quantities.
A 16 bit AdobeRGB is more precise as 16 bit profoto.
George
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.
George
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?
George
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.
George