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

[<mar...@li...>]

Hello Sergey,

> The actual data of the image(byte, short, int, float, double)->float->short->start
> lcms
> internal->float->apply color transform in floats->end lcms
> internal->float->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.

I don't know the internal architecture of OpenJDK, so maybe this is not feasible, but it seems to me the way you are doing the conversions is a serious throughput killer.  Lcms goes in a lot of trouble to optimize color transforms to make them as fast as possible whilst keeping the maximum precision. So, if you are going to convert a bitmap of 8 bits to another bitmap of 8 bits, your best option is to tell lcms to use 8 bits on input and output. The math precision and throughput performance you will obtain is actually better than going to float and then back to 8 bits, because lcms use tricks on rounding and fixed-point interpolation to go fast and accurate. Ditto for 16 bits, float, double, half...

Floating point transforms should be only used when your data is already in floating point, or in the case you want to convert to floating point. But that should be transparent to you, you should only tell the engine how your data is organized and let it to pick the better way to do the conversion. If you always convert to float assuming this is going to increase precision you are obtaining the inverse effect: sometimes less precision and definitively slower throughput. But again, I don't know OpenJDK architecture, so maybe the float step is unavoidable because other components.

Best regards

Marti Maria
The LittleCMS Project
https://www.littlecms.com




> -----Original Message-----
> From: Sergey Bylokhov <byl...@am...>
> Sent: Monday, August 14, 2023 10:18 PM
> To: Philip Race <phi...@or...>; mar...@li...; lcms-
> us...@li...
> Subject: Re: [Lcms-user] Configuration of the bounded/unbounded mode
> 
> 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
> internal->float->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/595fdd36c5f735b53ed2950c539be46382f
> 9bcdd/src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMSTransform.j
> ava#L230
> 2.
> https://github.com/openjdk/jdk/blob/595fdd36c5f735b53ed2950c539be46382f
> 9bcdd/src/java.desktop/share/classes/java/awt/image/ColorConvertOp.java#L8
> 09
> 3. Well we have a public API for such float based conversion -
> to/From/RGB/CIEXYZ:
> https://github.com/openjdk/jdk/blob/595fdd36c5f735b53ed2950c539be46382f
> 9bcdd/src/java.desktop/share/classes/java/awt/color/ICC_ColorSpace.java#L20
> 2
> 
> 
> 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.