Gerhard,
I forgot to mention value 255 is defined as white in cineon and value 95
as black.
Mapping 255 to white as whitepoint leaves no range above. The used curves
are defined as 8 or 16-bit unsigned integers - no fixpoint. Parametric
curves would be a choice. but I think they are valid for v4 tables only.
Maybe I give it a try.
regards
Kai-Uwe Behrmann
+ development for color management
+ imaging / panoramas
+ email: [EMAIL PROTECTED]
+ http://www.behrmann.name
Am 22.05.05, 16:58 +0200 schrieb Gerhard Fuernkranz:
> 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
Lcms-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lcms-user
