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
