Hi Graeme,

You could use
Input profile -> abstract profile -> Render profile
[...]

I'm not following that line of thought. Usually clipping is
a problem at the destination profile, due to real device

Oh, my point is much more simple. Imagine we have a matrix-shaper
profile for RGB->XYZ on input. This profile may represent a sort
of "working space", not necessarily tied to any specific device.
Then, one can adjust such profile in order to encode highlights, for
example setting the effective white point to (230, 230, 230) and
reserve the contone levels 230..255 for highlights. In such way,
(230,230,230) would be mapped to D50 in rel. colorimetric and
the remaining contone would represent values with Y>100.

At that point, if the output profile is operating on Lab, the CMM
must clip Y>100 to L*=100, since the encoding of PCS doesn't
allow L*>100. The PCS is used as indexing space for the output
profile, so the encoding should be maintained, thus, all highlights
are effectively lost.

However, using a abstract XYZ->XYZ profile in the middle, this
profile can implement a sort of gamut mapping to map the extended
range to Lab, preserving hue, for example.  So, you can operate on
highlights by means of the extended RGB > 230 and still getting
the ability to display the image on screen without artifacts.

gamut limits. XYZ PCS certainly has a much greater range than
Lab PCS, but how many input profiles are going to have a gamut
that exceeds the Lab PCS ?

AdobeRGB does. RGB=(0,255,0) cannot be represented on
Lab PCS. Anyway, I was assuming a specific profile, built on
purpose to deal with extended range medias.

[Another fly in the ointment of using an ICC approach, is that
 I notice the latest V4 specs now mandate value independent value
 clipping, causing the type of hue shifts in question. See 6.4,
 page 13 in the V4.2 spec. I'm personally wondering whether to
 make this behaviour controllable in my CMM.]

That's why I said highlights are not well handled on ICC color
management. I've specifically addressed this issue to several
ICC members.

Best regards.
Marti.

P.D. Are you going to attend CIC this year? ICC is planning a
developers conference at same time & location... it would be
great to have you there :-)



----- Original Message ----- From: "Graeme Gill" <[EMAIL PROTECTED]>
To: <lcms-user@lists.sourceforge.net>
Sent: Saturday, May 21, 2005 2:51 PM
Subject: Re: [Lcms-user] Colour clipping


Kai-Uwe Behrmann wrote:

the input matrix->abstract->monitor
approach sugested by Marti was tested. And the former posted site updated accordingly.

Am 11.05.05, 15:31 +0200 schrieb Marti:

i.e. instead of using:

Input profile -> Render profile

You could use

Input profile -> abstract profile -> Render profile

Obviously this is going to work only if PCS of input  profile is
XYZ. Lab PCS is limited to L*=100, so it will be not suitable
at all.

I'm not following that line of thought. Usually clipping is
a problem at the destination profile, due to real device
gamut limits. XYZ PCS certainly has a much greater range than
Lab PCS, but how many input profiles are going to have a gamut
that exceeds the Lab PCS ?

Of course if you are trying to process out-of-range input
device values, perhaps a result of filtering operations etc.,
then this could happen, but how valid is the input profile
conversion to PCS under these circumstances ? If this is the
problem, then perhaps an input space hue-preserving "hack"
will cover many situations ? (HSL space type clipping
mentioned by Robert provides that type of geometry,
although I suspect a similar result might be coded
directly in RGB if that's the space you want to work in.)

[Another fly in the ointment of using an ICC approach, is that
 I notice the latest V4 specs now mandate value independent value
 clipping, causing the type of hue shifts in question. See 6.4,
 page 13 in the V4.2 spec. I'm personally wondering whether to
 make this behaviour controllable in my CMM.]

Graeme Gill.


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
_______________________________________________
Lcms-user mailing list
Lcms-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lcms-user



--
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.322 / Virus Database: 266.11.14 - Release Date: 20/05/2005





--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.322 / Virus Database: 266.11.14 - Release Date: 20/05/2005



-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
_______________________________________________
Lcms-user mailing list
Lcms-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lcms-user

Reply via email to