Re: [Lcms-user] Configuration of the bounded/unbounded mode

[Sergey B. <byl...@am...>]

On 8/13/23 15:07, Philip Race wrote:
> Sergey,
> 
> Why do you want to do this ? I'm not sure I see the value in it.
> 
> Although JDK does support float for images, none of the standard image
> formats use floats.

Unfortunately not, even though most standard images use bytes and ints to convert color profiles and 
access pixels in images, we use floats. So the common pattern we have is:
The actual data of the image(byte, short, int, float, double)->float->short->start lcms 
internal->float->apply color transform in floats->end lcms internals->short->float->the data of the 
image(byte, short, int, float, double). So at the end we have a "good" precision of the result 
especially if the image stores the color component in 17+ bits.

An examples of such conversion:
1. 
https://github.com/openjdk/jdk/blob/595fdd36c5f735b53ed2950c539be46382f9bcdd/src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java#L230
2. 
https://github.com/openjdk/jdk/blob/595fdd36c5f735b53ed2950c539be46382f9bcdd/src/java.desktop/share/classes/java/awt/image/ColorConvertOp.java#L809
3. Well we have a public API for such float based conversion - to/From/RGB/CIEXYZ: 
https://github.com/openjdk/jdk/blob/595fdd36c5f735b53ed2950c539be46382f9bcdd/src/java.desktop/share/classes/java/awt/color/ICC_ColorSpace.java#L202


But there are a few things I would like to check before starting to work on the OpenJDK side.
1. The slow performance of the float based calculations, described here: 
https://github.com/mm2/Little-CMS/issues/356 But I think elimination of an additional conversion 
should compensate that.
2. Compatibility related to the out-gamut values discussed in this thread. I would like to 
understand how to implement clip properly. Note that our current implementation do not clip 
out-of-gamtut values but blindly cast to short and get some "random" value at the end.

-- 
Best regards, Sergey.