Naive Theoretical Colour Mgmt. continued.

[tomczak]

David and Elie,

Many thanks! I think I almost understand it now with perceptual and colorimatric intents. But what happens when a saturated colour (such as pure saturated red (1 0 0)) is mapped from a smaller gamut sRGB to a larger gamut AdobeRGB using 'Preserve Saturation' rendering intent? I thought that in such case the fully saturated colours at the boundary of the input gamut would be translated to the boundry colours of the output space even though the two colours wouldn't really match. This doesn't seem to happen - why?

Cheers!

[afx]

If you preserve saturation, then you cant stay at 1, that would be an increase.
Going from small to big, your max from small will not be max in big, but smaller than that.

cheers
afx

[elied]

I have to admit that I don't know what the effect of rendering intents would be when going from a smaller to a larger gamut. I suspect that they have no effect at all since their purpose is to determine the manner in which the data is compressed when going from big to small. From small to big there is remapping and losses due to rounding off, but no compression. Moreover, since all conversions from one work space to another are Relative Colormetric (Preserve Identical Colors) no matter what intent you have selected, I doubt that Preserve Saturation could be used at all for sRGB to AdobeRGB.

[tomczak]

Here is a blurb supporting what Elie just said:

http://www.earthboundlight.com/phototip ... ptual.html

[jsachs]

I am not sure I agree with any of the analysis so far on this thread.

First, I do not believe that Adobe RGB has a brighter red primary than sRGB - monitor profiles (unless you are talking about V4 profiles) just have a few entries - the monitor primaries, white point, black point and gamma. Adobe RGB is virtually identical to sRGB except that it has a slightly larger gamut in the blue/green area. If the Adobe RGB red was brighter than sRGB then everything would look red. The primaries in monitor profiles are all normalized and it is up to monitor calibration to set the white point so as to balance out the brightness of the three primaries to render neutral grays when the three channels are equal. Having a brighter red primary would simply mean that at most you could get a brighter maximum brightness out of the monitor, not that you could reproduce brighter reds relative to other colors.

The actual mapping of colors from one gamut to another is performed within the black box of the color engine. Color engines generally use proprietary algorithms to attempt to map from one color space to another, using the rendering intents as a hint as to how to make the various trade-offs. Results will vary from color engine to color engine as gamut mapping is more of an art than a science. Perceptual rendering intent (aka Maintain Full Gamut) is supposed to favor mapping fully saturated colors in one space to fully saturated colors in the other, so I would expect full red (255,0,0) to map to full red regardless of the color space, unless the color engine does not support all the rendering intents or has some other idea about what it thinks you want. This works the same whether expanding or compressing gamuts. If you just mapped to the nearest color you would waste a lot of the best colors when going from a smaller to larger gamut and would map a lot of colors to the same color when going from a larger gamut to a smaller one. Maintain Full Gamut is supposed to do accurate mapping for colors well within both gamuts and progressing compression or expansion as you get close to the limits of either gamut.

[tomczak]

Here is another writeup stating that matrix-based colour spaces (such as sRGB or AdobeRGB) can only be mapped to one another using relative colorimetric intent - choosing perceptual defaults to relative colorimetric anyway. Is that true? That would have explained, I think, why (255,0,0) translates to less saturated red when going from smaller space to a larger one.

http://www.colorwiki.com/wiki/Color_Man ... yths_21-25

p.s. If that's the case, and the piece actually suggests it, would it be possible at all to detect what rendering intents are possible when converting profiles, and allow only those that can be used.

[jsachs]

That sounds right - the rendering intent is an optional hint to the color engine and not all profiles support all rendering intents. Mostly I have seen rendering intent applied to printer profiles where there are multiple sets of tables - one for each supported rendering intent.

[David_B]

The littleCMS tutorial by Marti Maria contains the annex below, that provides a "clear explanation". If anyone can translate it into plain english, I would be interested to see it.

My interpretation is:

The CMS is dumb, it just does what the matrix or LUT tells it.

If you have only a matrix or one LUT. then that is what it does, but it doesn't know what the LUT represents.
If you have three LUTs then Perceptual does LUT 0, Relative Colorimetric does LUT 1 and Saturation does LUT 2.

With a matrix or single LUT, the only option the CMS has, is whether to adjust for a different whitepoint or not, and you get Relative Colorimetric and Absolute Colorimetric respectively.

The CMS has no internal concept of a Perceptual mapping that it can use in conjunction with a matrix.

But I could be completely wrong! Any other ideas?

FROM TUTORIAL.TXT by MARTI MARIA:

Annex A. About intents
============================================================================

Charles Cowens gives to me a clear explanation about accomplished intents. Since it is very useful to understand how intents are internally implemented, I will reproduce here.


AtoBX/BtoAX LUTs and Rendering Intents

The ICC spec is pretty detailed about the LUTs and their varying meaning according to context in tables 20, 21, and 22 in section 6.3. My reading of this is that even though there are 4 rendering intent selectors there are really 6 rendering styles:

Relative Indefinite
(Relative) Perceptual
Relative Colorimetric
(Relative) Saturation
Absolute Indefinite
Absolute Colorimetric

If a device profile has a single-LUT or matrix:

* Perceptual, Relative Colorimetric, Saturation selectors produce the same Relative Indefinite rendering style

* Absolute Colorimetric selector produces an Absolute Indefinite rendering style derived from the single LUT or matrix, the media white point tag, and the inverse of a white point compensation method designated by the CMS

If a device profile has 3 LUTs:

* Perceptual, Relative Colorimetric, Saturation selectors produce the appropriate rendering styles using the 0, 1, and 2 LUTs respectively

* Absolute Colorimetric selector produces an Absolute Colorimetric rendering style derived from the Relative Colorimetric LUT (numbered "1"), the media white point tag, and the inverse of a white point compensation method designated by the CMS


This would explain why perceptual is the default rendering style because a single-LUT profile's LUT is numbered "0".

[99eagle99]

Here is my understanding of the above information:

Using a matrix profile (most monitor profiles are matrix profiles), there is no way to accomplish progressive gamut compression or expansion since each output RGB channel is just computed as a weighted sum of the input RGB values, with a brightness curve for each channel. Table based profiles (generally used for printers and scanners) contain a lot more information since the tables contain precomputed result values for each channel for a skeleton of evenly spaced input values. Since you can have (but are not required to have) a different table for each rendering intent, there is at least the possibility of intelligent gamut compression/expansion, depending on the profile creation software. Scanner profiles are also usually tabular but rendering intents are not meaningful since the scanner does not render anything. The bottom line is that rendering intents are only used when printing and then only if the printer profile implements them. At some future date there may be tabular monitor profiles, but the computational burden of performing the necessary 3-D interpolation to convert every displayed pixel will probably make this impractical for some time.

[tomczak]

Is it the presence of proper LUTs in the source, the target, or in both profiles that enables the use of a rendering intent different from relative colorimetric?

Would it also mean that Preferences/Monitor rendering intent is irrelevant?