Kai-Uwe Behrmann schrieb:
The problem with curves is the limited range of values. For instance the
above Cineon format represents up to 1024 levels. For 0 -> 255 (usual
8-bit convention) a custom curve is ok. Anyway the curve fails to describe
the remainder from 256->1023.
I can't follow you. By definition, the TRC curves in an ICC profile
always cover the complete range of device values. There is no 1:1
relation at all required between the number of grid points in the TRC
table and the number of quantization levels for the device values. So it
is no problem at all, if the TRC has only 256 entries, but if you have
integral, quantized device values in the range 0..1023.
Notice, the TRC tables in ICC profiles are *not* simply *indexed* by the
integral, quantized device values, but the LUTs are always assumed to be
*interpolated* between the grid points. The first point in the LUT
corresponds to the lowest (zero), and the last tabe entry always
corresponds to the highest value (for Cineon obvoiusly 1023) in device
space.
Example: If you have a TRC with 256 entries (numbered 0..255), and 1024
discrete input values in the range 0..1023, then input value 1023 will
use exactly the TRC entry #255, and an input value of 512 will
interpolate linearly between the table entries #127 and #128 (since
512*255/1023 = 127.62).
If the TRC only needs to describe a straight line, then even a TRC with
only two points is sufficient - the line between the two points is
interpolated by the CMM when it applies the profile. For a curved TRC,
the number of required points is only a matter of desired accuracy (i.e.
how well can the curve be approximated by piecewise line segments
connecting adjacent points), but not a matter of the number of input levels.
Another issue to consider is the LCMS API: As is, it basically only
offers you floating point and 8- and 16-bit integral data types for
device values. But there is no built-in 10-bit data type. So if you have
10-bit device values, you either need to scale the device values up by a
factor of 65535/1023, before you feed them as e.g. TYPE_RGB_16 values
into the LCMS engine, or you need to supply a user defined formatter
function (cmsSetUserFormatters()) which handles the 10-bit data format
and converts it to a 0..65535 range, which is the LCMS internal
representation of device values.
Regards,
Gerhard
-------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/lcms-user
