Re: Photoshop Gamut warning vs ColorThink
Re: Photoshop Gamut warning vs ColorThink
- Subject: Re: Photoshop Gamut warning vs ColorThink
- From: "dpascale" <email@hidden>
- Date: Sat, 23 Feb 2008 22:15:14 -0500
Graeme,
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.
I realized that after writing my message, when reading a post you wrote
earlier, and sent another message on the list just after, indicating my
oversight.
Sorry for that.
A method with "no tolerance" will tend to reject more colors than what could
be "accepted". For instance, I am willing to live with a 1 Delta-E
difference (any formula you choose) between file and print (and probably
more in many cases). In practice, this means that patches tagged as clipped
with xicclu are acceptable for me when measured, and I verified, with a test
file, that it happens. However, now I know why this happens.
Danny Pascale
----- Original Message -----
From: "Graeme Gill" <email@hidden>
To: <email@hidden>
Sent: Saturday, February 23, 2008 8:53 PM
Subject: Re: Photoshop Gamut warning vs ColorThink
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
_______________________________________________
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