[Openicc] Re: color-policy vs. color-infrastructure

[Graeme Gill]

Stefan Döhla wrote:
> But is this information really helpful? In real applications I don't
> want to know, whether a color is printable by setting a (unknown)
> particular color.

This comes down to what your definition is of "in gamut".
The definition I was assuming is "is capable of being
produced by the device". I think this is the most
usual definition applied in color science.

If you are after something else (such as "is capable of
being produced after translating through this particular
profile's particular B2A table", then yes, a different
procedure would be appropriate.

> What I really need is
> the information, whether a particular color is reproducible, by
> setting it's values e.g. in Lab. Can you tell me, what color should
> have been selected in the app to get the desired color?

You seem to be asking to second guess the B2A table processing.
If you really want to do that, then you'd have to do an inversion
of PCS -> chosen B2A -> device -> colorimetric A2B -> PCS
for your desired color, and it is out of gamut if the inversion
fails (ie. there is no inverse for that PCS).

> For real color management it should be the same color, which isn't
> guaranteed if you're only checking the A2B table.

By directly inverting the A2B, the resulting color is exact (as far
as the response of the device is known). This is a far more accurate
device value than any practical B2A table will produce. The output
of inverting the A2B is the device values needed to reproduce the
given PCS color.

> To see, whether a PCS color was preserved, the B2A table must be
> considered.
>  
> Your method can work only if A2B is truly the inverse of B2A,
> which means, there happens no shift. This is something, I wouldn't
> assume ...

Um, the A2B is never an inversion of the B2A. The B2A is an inversion
of the A2B. The A2B is the record of the natural response of the device
(it is basic information.) The B2A is derived information.

Graeme Gill.