[argyllcms] Re: icmColorantTableVal_write: write of PCS coord failed
- From: Gerhard Fuernkranz <nospam456@xxxxxx>
- To: argyllcms@xxxxxxxxxxxxx
- Date: Fri, 12 Jun 2009 02:35:08 +0200
Graeme Gill wrote:
> Gerhard Fuernkranz wrote:
>> I did some trials (though with a different display). However, there seem
>> to be banding issues. Looks like -qh is a must for this kind of profiles
>> (though -qm gives reasonable results for a CIELAB PCS, using the same
>> .ti3).
>
> Do you think this is the A2B or B2A tables ?
Looks like the major issue is caused by the B2A tables, though I don't
fully trust the A2B1 table either - the self-fit error is IMO
unreasonably low (I think I need to run a cross validation with separate
training and test sets to assess).
> [ 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.
Kind Regards,
Gerhard
Other related posts:
