Re: Photoshop Gamut warning vs ColorThink
Re: Photoshop Gamut warning vs ColorThink
- Subject: Re: Photoshop Gamut warning vs ColorThink
- From: Graeme Gill <email@hidden>
- Date: Sun, 24 Feb 2008 12:53:29 +1100
dpascale wrote:
the gamut limits (this is not as bad a statement as it looks!). Apart
from different computing methods, as pointed by many in this post,
another reason is that even if a color is well within a gamut, there is
always a small residual DeltaE error when going back and forth between
the input and output spaces. In addition, our own "tolerance" for errors
Actually, for the xicclu method, the tolerance is basically the
determined by the floating point precision of the machine in inverting
a linear equation:
$ xicclu -fif -ir 3dap.icm
50.000000 0.000000 0.000000 [Lab] -> Lut -> 0.030272 0.000000 0.049075 0.600702 [CMYK]
$ xicclu -ff -ir 3dap.icm
0.030272 0.000000 0.049075 0.600702 [CMYK] -> Lut -> 49.999987 0.000004 -0.000006 [Lab]
(This example really showing the precision being limited by the 6 digits of display.
The internal calculation is accurate to something like 12 decimal digits or more.)
This doesn't mean that it translates to other CMM's though, since they
may use a different interpolation algorithm, or compute using
a different representation (ie. fixed point). And ultimately the
A2B is only an approximation of the actual device behaviour.
[ The above examples are being computed in floating point with simplex
(ie., tetrahedral in 3D) decomposition of the LUT cells.]
With GO/NO-GO approaches, such as Photoshop, or Argyll (for color
lists), an "overlay" or "clip" status is given. Since we do not know the
criteria for this flag (it cannot be a non-zero error, so it is a
programmer's decision; ColorThink and GamutVision have more flexibility
Well, no, not in the case of xicclu. If a target color can't be
located in the forward interpolation of the A2B table within the
floating point precision of the machine, then it is out of gamut.
The precision is dictated by floating point arithmetic error, and
there is no input from the programmer in this, since there is no
magic "fudge factor" (it comes down to a device value being within
the range 0 to 1 inclusive). It's go/no-go with high precision.
The biggest source of uncertainty with this approach is in specifying
the TAC and other similar limits. For more than 3 inks there is also
a distinction between what's in gamut for a spot color, and in gamut
for images, since the latter relies on color interpolation where
continuity is important. The invert A2B approach is good at answering
the question "is this color theoretically within the reach of a device".
It's not so good for answering the question "is this color reproducible with
a particular workflow involving possible gamut mappings and interpolated PCS
to device lookups".
Graeme Gill.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Colorsync-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden