On 09/15/2014 04:43 AM, marti.ma...@littlecms.com 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, marti.ma...@littlecms.com 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 ------------------------------------------------------------------------------ Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk _______________________________________________ Lcms-user mailing list Lcms-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lcms-user
