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

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

Hi,

Keep in mind the CMM internally operates always in unbounded mode and clips
values at final stage if you use anything but floating point. Also, not all
profiles allow unbounded mode. Doing the change you purpose would have a
severe impact on applications not expecting values negative or over 1.0. 
By using shorts, you are limiting precision to 16 bits, if you use floats,
you get more accuracy. Also note the encoding range changes, 0.1 for RGB,
0.100 for CMYK and for Lab it comes already decoded.
Unbounded mode works in both directions, if you feed the transform with a
value bigger then 1.0 and the profile supports it, the obtained XYZ would be
an out-of-gamut extrapolation.

The flag cmsFLAGS_NONEGATIVES was introduced to prevent only negative values
because security issues, does not work for values bigger than 1. In any
case, no matter what you do, the result would be wrong because this is an
out of gamut value. Clipping is an option, just the simplest gamut mapping
you could do.

> 3. What about the use case when the user splits the "big" transform into a
> few small intermediate transformations, is it possible to enable
"unbounded"
> mode for all transformations except for the output of the latest
transform?

Sure. Just ad a couple of "if >= 0 &&  <= 1.0" at the very end of the
pipeline.

Regards

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



> -----Original Message-----
> From: Sergey Bylokhov via Lcms-user <lcm...@li...>
> Sent: Sunday, August 13, 2023 1:48 AM
> To: lcm...@li...
> Subject: [Lcms-user] Configuration of the bounded/unbounded mode
> 
> Hello, Colors Experts!
> 
> I am working on the OpenJDK project and have a couple of questions about
> the LittleCMS library.
> 
> The OpenJDK uses the LittleCMS for color conversion for a long time. And
one
> of the use cases is getting the pixel data from the user in float format.
> Unfortunately before passing this float data to the LittleCMS the OpenJDK
> converts them to shorts(16 bit) and after color transformation converts
the
> shorts to floats back and returns that floats to the user.
> 
> The current implementation was done for LittleCMS 1 and was not updated
for
> version 2. I have read this[1] document about the "Floating Point Encoding
> Range" added to the spec in 2006 and how it is implemented in the
LittleCMS
> library and would like to use this functionality in OpenJDK.
> 
> The change in OpenJDK should be straightforward, delete the intermediate
> conversion from floats to shorts and back and pass the floats directly to
the
> LittleCMS library. But this is a moment I would like to clarify some
possible
> impacts on the compatibility with the old behavior.
> 
> 1. It is a good thing to do all intermediate computation in the unbounded
> mode during color transformation, but how the out-of-gamut values are
> handled for input and output data? That was not a problem for short but
> could be a  problem for floats, for example, what will happen if 2.0f is
passed
> as a color value for the sRGB format - will it be clipped? or error will
occur? or
> transformation will be applied as-is?
> 
> 2. What about the output? There is a cmsFLAGS_NONEGATIVES flag to prevent
> negative values but when and how that values will be clipped by the upper
> bounds? There are no options to configure that and it seems some clipping
> occurs here and there in the code based on some constants which are not
> exposed as CMS API.
> 
> 3. What about the use case when the user splits the "big" transform into a
> few small intermediate transformations, is it possible to enable
"unbounded"
> mode for all transformations except for the output of the latest
transform?
> 
> Thank you for any suggestions!
> 
> [1] https://www.littlecms.com/CIC18_UnboundedCMM.pdf
> 
> --
> Best regards, Sergey.
> 
> 
> _______________________________________________
> Lcms-user mailing list
> Lcm...@li...
> https://lists.sourceforge.net/lists/listinfo/lcms-user