No gamut warning when checking an L= 0 on a matte paper

[PhR]

This is probably obvious to many of you but I cannot figure out why the papers manufacturer's profiles of several matte papers that cannot obviously reproduce the complete black color  (L = 0, a = 0, b = 0) does not consider this black as being out of the gamut when checking this with Lightroom (4.4) or Photoshop (6.0).

Can someone enlight me ?

Thanks

[digitaldog]

For one, the OOG overlay in Photoshop and similar are both buggy and not very useful.
The Out Of Gamut Overlay in Photoshop and Lightroom

In this 25 minute video, I'll cover everything you need to know about the Out Of Gamut (OOG) overlay in Photoshop and Lightroom. You'll see why, with a rare exception, you can ignore this very old feature and still deal with out of gamut colors using modern color management tools.

YouTube: https://www.youtube.com/watch?v=00O-GTDyL0w
High resolution: http://digitaldog.net/files/OOG_Video.mp4
Having access to the profile might help in seeing it's construct but when the rubber meets the road, OOG is not very reliable.

[MHMG]

This is probably obvious to many of you but I cannot figure out why the papers manufacturer's profiles of several matte papers that cannot obviously reproduce the complete black color  (L = 0, a = 0, b = 0) does not consider this black as being out of the gamut when checking this with Lightroom (4.4) or Photoshop (6.0).

Can someone enlight me ?

Thanks

I can't speak for how LR implements gamut warnings, but one reason why many people think Photoshop's gamut warning is totally defective is at least in part due to the fact that it's interactive with your choice of rendering intent when setting up the custom proofing condition. Thus, if you want to see what colors are absolutely in gamut you have to set rendering intent to absolute.   Then you will see those matte black values appear as out of gamut. Otherwise, If you choose perceptual or recol/w BPC, PS gamut warning is now telling you that the profiling process has successfully remapped L=0 in the source file (which is in absolute terms out of gamut) into the actual printer/ink/media gamut volume (which might be L=15, for example, for max printable black on a matte paper). Same hold true for other colors...ie, what colors now are remapped to fit within the printer/ink/media/s realizable color gamut rather than what colors started out as out of gamut. I hope that make sense. It does if you think about it.

The 2nd caveat about the gamut warning overlay is that Photoshop has an allowance of approximately 6dE counted as within acceptable color gamut, thus if your printer/ink media combination prints to L= 5 or 6 at max printable black, for example, PS will consider a source file L value of 0, 1, 2, 3, 4, or 5 close enough to be counted as in gamut. Perhaps that's not accurate enough gamut warning precision for technical purists, but at a practical level, it's an acceptable judgement call for what people can easily notice, thus arguably not a functional failure of PS's gamut warning algorithm.

cheers,
Mark
http://www.aardenburg-imaging.com

[digitaldog]

FWIW, I don't think OOG is totally defective, just not very useful. Prior to actual ICC color management in PS 5, it was kind of useful to ”see” and edit OOG colors. We have now soft proofing and rendering intents.
LRs soft proofing is just a little better than PS due to the UI but that's about it.

[MHMG]

FWIW, I don't think OOG is totally defective, just not very useful. Prior to actual ICC color management in PS 5, it was kind of useful to ”see” and edit OOG colors. We have now soft proofing and rendering intents.
LRs soft proofing is just a little better than PS due to the UI but that's about it.

I find it very useful for certain things I want to visualize about the printing system (such as comparing gamut volume slices of two different ICC profiles along different hue plane or L* planes), but I agree that most people can probably live without it.

[PhR]

Thanks Andrew for this interesting video. I didn't know that the OOG display was buggy. You demonstrated this clearly.

About this :

If you choose perceptual or recol/w BPC, PS gamut warning is now telling you that the profiling process has successfully remapped L=0 in the source file (which is in absolute terms out of gamut) into the actual printer/ink/media gamut volume (which might be L=15, for example, for max printable black on a matte paper). Same hold true for other colors...ie, what colors now are remapped to fit within the printer/ink/media/s realizable color gamut rather than what colors started out as out of gamut. I hope that make sense. It does if you think about it

Thanks for this explanation but it is still unclear me. Any color of the image is, at the end, remapped to another one by the CMS to be printed. Whether we use perceptual or relative intent. So what are those color that are not remapped and marked as OOG ? Those that are not used in the target that was measured for creating the profile ?

[MHMG]

Thanks Andrew for this interesting video. I didn't know that the OOG display was buggy. You demonstrated this clearly.

About this : Thanks for this explanation but it is still unclear me. Any color of the image is, at the end, remapped to another one by the CMS to be printed. Whether we use perceptual or relative intent. So what are those color that are not remapped and marked as OOG ? Those that are not used in the target that was measured for creating the profile ?

With perceptual mapping or Relcol/wBPC, the rendering approach uses a compression mapping scheme to bring OOG colors into printable gamut. If that mapping scheme mapped all possible source file color values linearly from zero chroma all the way to the gamut edge of the printing process, moderately vivid colors would now look dull, so a non linear compression model must be used to reduce the compression effect on lower chroma colors. At some point the differentiation of the most vivid colors must also be sacrificed to preserve the fidelity of the more moderately saturated colors. i.e., OOG clipping must occur.  Thus, at a certain point in the remapping process, one has to decide where the clipping must take place so that extreme colors aren't competing with more moderate colors for in-gamut differentiation. This is especially true for color spaces that can encode imaginary colors (e.g., proPhoto RGB) because by definition those values don't represent any real color humans can see. The PS gamut warning overlay should flag these imaginary colors and also those extreme real colors which the remapping is by design going to try to pin somewhere to the gamut volume shell.  It's a visual trade-off as to where compression mapping starts taking place and by how much.  CMMs do not have any artificial intelligence (at least not today's CMMs) for altering the gamut compression algorithm on the fly depending on the nature of initial color values encoded in the source file. They merely follow a predefined set of instructions (i.e., the ICC profile vendor's "secret sauce").  Some profiles do a much better job of compression mapping very demanding images than others, but to avoid coming to false conclusions about profile quality, one should not choose evaluation images that have imaginary color values encoded in them.


cheers,
Mark

[digitaldog]

In addition to what Mark added, the OOG overlay (which is just an ugly image blocking, you are supposed to remove it manually construct) treats a tiny OOG color and those massively OOG the same. And again, what are you supposed to make of this? In the past, prior to the ICC color management we have today, the 'idea' was to take say the Sponge Tool set to desaturate and remove manually the OOG (which might be tiny or massive).
Adobe could update OOG to make it more useful. I don't think they ever will nor is it a good use of engineering. But products like ColorThink Pro have similar overlays that show differing colors based upon the deltaE (degree/difference/distance) and it would be more useful if Photoshop showed you as an example: Red is Very OOG, Green is moderately OOG, Yellow low etc. But again, what are you, the user going to do, viewing all this blocking your underlying image and what will you do that's better, faster than just letting the profile do this based on it's rendering intent.