Re: [Lcms-user] LCMS2 problem with converting zero and near-zero channel values

[Elle S. <ell...@ni...>]

On 09/15/2014 04:43 AM, mar...@li... wrote:
> Otherwise, regarding the fact gimp does not like the negative numbers,
> the obvious fixup is to run a filter on the buffers removing the values
> the app does not like. This cannot be done at CMM level because there
> are other apps that do use such values. A simple for loop and a couple
> of if statements to clamp between 0 and 1.0 woudl solve the issue.

I don't think "gimp does not like the negative numbers" is a fair way of 
decribing the problem because those negative numbers are not the result 
of an intentional unbounded ICC profile conversion or other 
user-initiated action but rather the result of rounding errors during 
LCMS ICC profile conversions. Also, the small positives that should be 
zero are still wrong even after clipping any small negatives that should 
be zero.


On 09/15/2014 11:22 AM, mar...@li... wrote:
> IEEE754 single-precision float has only 7 digit precision (log10(2^24) ≈
> 7.225),
> since your conversion goes from gamma 1 to gamma 2 space, the operation
> you do is
>
> rgb^1 -> [Matrix1] -> [Matrix2]^-1 -> rgb^(1/2)
>
> Matrix1 and 2 are stored as doubles, but values are evaluated stage by
> stage and stored as floats, and therefore quantized.
>
> Then (1E-7)^(1/2) = 0.0003162277, if you move to 0..255 domain,
> (1E-7)^(1/2) * 255 = 0.0806 which is the maximum error you could get.
> The value you report is below this.
>
> What you see is a precision loss due to quantization to floats and gamma
> 1.0 space.
>

So it's not a platform difference, but a rounding error that affects all 
platforms? For 8-bit editing, the error makes no difference. But for 
16-bit editing, 0.0003162277 times 65535 is 20.7240. So it looks like at 
16-bit integer, errors up to nearly 21 can be expected when converting 
zero and near-zero channel values between different ICC profiles, yes?

Darktable, RawTherapee, Krita, GIMP from git, and probably others allow 
editing 32-bit floating point images; and Photivo, ShowFoto, and others 
allow editing 16-bit integer images.

Many people prefer editing in linear gamma color spaces, but the image 
might need to be converted to a linear gamma color space before editing 
can begin, or in GIMP's case, converted to a higher gamma color space 
from a linear gamma color space, thus incurring the rounding errors and 
possible negative channel values.

Also, at 32-bit floating point the small negatives are produced even 
when converting between nearly perceptually uniform profiles, such as 
between sRGB with the gamma=2.0 TRC and sRGB with the regular sRGB TRC.

Could you perhaps modify LCMS2 to use, or provide the option to use, 
double floating point precision throughout, thereby mitigating the 
otherwise seemingly inevitable interim single-precision floating point 
rounding errors?

Kind regards,
Elle