[argyllcms] Re: icmColorantTableVal_write: write of PCS coord failed
- From: Gerhard Fuernkranz <nospam456@xxxxxx>
- To: argyllcms@xxxxxxxxxxxxx
- Date: Fri, 12 Jun 2009 13:35:57 +0200
Gerhard Fuernkranz wrote:
> Graeme Gill wrote:
>
>> [ A refinement that I haven't got around to adding is to use the
>> per-channel tables to scale the cLUT grid region to just surround
>> the gamut of the device in the B2A. ]
>>
>
> This gives however still just the opportunity to bracket a cuboid in XYZ
> space, which is aligned with the X, Y, and Z axis. An "RGB cube" however is
> skewed in XYZ space and is still just a small subset of this cuboid. So I'm
> wondering, couldn't it be useful to make use of the matrix in the lut16type
> in order to extract the "RGB cube" from the XYZ space? I.e.
> find the smallest triangle in [x,y] chromaticity space which completely
> encloses the device gamut (projected to [x,y] chromaticity space), and setup
> the matrix in the lut16type so that it maps XYZ to the (linear) RGB space
> described by this triangle. These RGB numbers are then fed into the
> prelinearization tables, etc. I guess this could significantly reduce the
> subset of the XYZ space which needs to be covered by the CLUT table.
>
Though my notebook LCD is definitively not additive, it looks like the
gamut projected to chromaticity space still forms approximately a
triangle, though the (extrapolated) corners of this triangle don't match
the measured primaries exactly (see attached diagram). So I guess it may
work quite well for display devices to use an perfectly additive RGB
space (which tightly encloses the gamut of the display) as intermediate
color space for indexing the B2A CLUT. CAM clipping via the B2A tables
is of course passé if the CLUT does no longer cover the whole PCS; if
this property should be retained as well, the only solution is likely to
increase the B2A CLUT resolution.
Regards,
Gerhard
Other related posts: