Re: Perceptual Javex-offline
Re: Perceptual Javex-offline
- Subject: Re: Perceptual Javex-offline
- From: Graeme Gill <email@hidden>
- Date: Tue, 26 Sep 2006 23:24:51 +1000
eugene appert wrote:
We have been using Monaco
Proof for several years for monitor, printer and scanner profiles. This
particular problem has never occurred before with any of our other
scanner profiles. The profiles are for an Epson 4990, the perceptive
table of the transparent (TR_4990) does not seem to handle values above
the target white patch ( L*88 RGB 210) but the reflective profile R_4990
does.
The reflective profile contains both matrix profile, and LUT
profile information. The matrix information is useless however,
because all the three colorant values are identical.
It's nominated white point is very close to D50. This is
unlikely to be the actual white point of the test chart used
to created it, although without the reference file and/or
measuring the white patch of the test chart, it's hard to be sure.
Having a white point of nearly D50 disables any distinction
between relative and absolute colorimetric intent.
The relative white point is either rather inaccurate at
an Lab value of 100.390625 0.00 0.00, or more likely,
it has been wrongly encoded - it's using an L* value
encoded as 0xffff, whereas L* = 100 should be encoded as 0xff00 for
all Version 2 ICC profiles.
(This is rather a worry for the interchangebility of all Monaco
generated V2 profiles. V4 has since changed to an 0xffff encoding for
L*=100 for most tags.)
My guess is that Monaco is generating an inherently absolute
colorimetric profile for the relative table, and is effectively
discarding the absolute white point information and placing
D50 as the white point, to achieve this.
There is some practical logic to this approach, to be able
to provide one intent that doesn't clip for input value above
the test chart white patch, but it is not how I understand that
the ICC spec. recommends input profiles should be created by default,
and means that the relative colorimetric intent doesn't function
as such, but functions as an absolute intent.
There is no evidence of clipping behaviour for the relative
colorimetric table, because the scanner (evidently) is set
to return values of approximately 255,255,255
(ie. normalized values 1.0,1.0,1.0) for a perfectly reflective
or transparent sample.
The perceptual & saturation tables are different
to the relative colorimetric table with regard to their
contents. These two tables show a clipping characteristic.
The clipping is less sever in the Reflective profile
(starting around R=G=B=0.96), whereas this it is more
obvious in the Transparency profile (starting around R=G=B=0.76).
I would presume it has been the perceptual intent you have been
using.
I would guess that the clipping is due to the colorimetric
nature of these two intents, and that the test chart white patch
is well bellow R=G=B=1.0. Without the test chart readings and
reference data, I can't say whether this guess is correct, but
if it is, the profiles are behaving as one would expect for these
two intents. Since Lab LUT tables can't contain L* values
above 100, and device value above the test chart white patch
will be clipped for the perceptual and saturation tables. This
is an inherent limitation of ICC Lab PCS LUT input profiles.
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