Hi Elle,
Sorry I didn't explain myself. I mean, when you actually
store a built-in profile to disk, you are forced to use
the ICC profile format. The ICC profile format has some
limitations when storing floating point numbers.
That means, if you have a floating point number
in memory that is, say, 1.234567890, the file format
used by ICC stores it as 1.23457. Then, when you read
the profile again, the number you obtain is 1.23457 which
has only 5 decimal places of precision and is slightly
different from the original number. In your example
you were mixing a yet existing profile with the srgb
builtin and the builtin saved to disk.
So, if you save the builtin to disk and read it again, you
actually get slightly different numbers. If those numbers are
the 3x3 matrix elements, you got different results.
As a proof of that, if you save the builtin and you use
the saved file as input and output, it still roundtrips
well.
transicc -i sRGB_builtin.icc -o sRGB_builtin.icc
LittleCMS ColorSpace conversion calculator - 4.2 [LittleCMS 2.06]
Enter values, 'q' to quit
R? 255
G? 255
B? 255
R=255.0000 G=255.0000 B=255.0000
etc.
So, this loss of precision is due to the file format.
Hope it makes sense to you
Regards
Marti
Quoting Elle Stone <ellest...@ninedegreesbelow.com>:
> On 04/02/2014 04:43 PM, marti.ma...@littlecms.com wrote:
>>
>>
>> Hi,
>>
>> The ICC file format stores matrix of sRGB as 15.16 fixed point, that
>> means the precision you have is 1 / ((1 << 16) - 1) which is
>> about 1.5e-5 Since evaluating the matrix implies multiplication
>> and addition, the final precision is reduced to 1e-3, that means
>> only two decimal places are accurate. This is not a major problem
>> because is far below 1 dE.
>>
>
> Hi Marti,
>
> My apologies, I didn't understand all of what you said. Are you saying
> that conversions to sRGB are only accurate to two decimal places,
> meaning somewhat less than five significant digits in terms of floating
> point precision?
>
> Previously I tested 32-bit floating point round-trip conversions from
> ProPhotoRGB to sRGB and back using your wonderful unbounded mode ICC
> profile conversions. The round trip conversion (using only profiles from
> disk and involving 4 sequential ICC profile conversions) is 100% lossless:
> http://ninedegreesbelow.com/photography/lcms2-unbounded-mode.html#pro2srgb
>
> I would have expected rounding errors during the unbounded mode round
> trip conversions if the conversions were accurate only to two decimal
> places. How is the round-trip conversion lossless despite only two
> decimal places of accuracy? My ability to visualize/grasp the math fails
> at this point.
>
> >
> > The in-memory built-in is not quantized and does not have this
> > problem, as soon as you serialize it, you got quantization.
> >
>
> Are you saying the conversion to the built-in profile that was created
> and stored in memory is more accurate? or less accurate? than the
> conversion to the same profile that's been saved to disk? It seems to me
> that it's less accurate.
>
> Here's another example of transicc output with less confusing RGB
> values. In this case transicc converts from a linear gamma version of
> the lcms built-in sRGB (cmsCreate_sRGBProfile) that had been created and
> saved to disk.
>
> When converting from linear to regular sRGB (both profiles using the
> same primaries and white point), the resulting output RGB values should
> match the source RGB values for all source values like (0,0,0),
> (255,255,255), (255,0,0), etc.
>
> Converting to the built-in lcms sRGB profile that had been created and
> saved to disk:
>
> $ transicc -w -c0 -b -t1 -i sRGB-lcms-primaries-wtpt-V4-g100.icc -o
> sRGB-lcms-primaries-wtpt-V4-srgbtrc.icc
>
> 255 255 255
> R=255.0000 G=255.0000 B=255.0000
>
> 255 0 0
> R=255.0000 G=0.0000 B=-0.0000
>
> 0 255 0
> R=-0.0002 G=255.0000 B=-0.0000
>
> 0 0 255
> R=-0.0001 G=0.0000 B=255.0000
>
> The figures above are accurate to almost 4 decimal places.
>
>
> Converting to the lcms built-in sRGB profile:
>
> $ transicc -w -c0 -b -t1 -i sRGB-lcms-primaries-wtpt-V4-g100.icc -o *sRGB
> 255 255 255
> R=254.9988 G=255.0029 B=254.9981
>
> 0 255 0
> R=0.0254 G=255.0008 B=0.0153
>
> 0 0 255
> R=0.0034 G=0.0343 B=254.9988
>
> The figures above are accurate to 2 decimal places.
>
> So it looks to me like conversions to the profile that had been saved to
> disk are more accurate.
>
>
> GIMP from git does 32-bit unbounded mode floating point conversions from
> the source color space profile (which may be a linear gamma color space)
> to sRGB (and possibly to linear gamma sRGB), keeping the out-of-gamut
> RGB values rather than clipping them. So the conversions do need to be
> accurate.
>
> Can I modify the GIMP ICC profile conversion code to make conversions to
> the GIMP built-in sRGB *exactly* match conversions to the same profile
> that has been saved to disk? Perhaps there is an optimization switch
> that needs to be set or unset?
>
> Or is the only alternative rewriting the GIMP code to save the built-in
> profile to disk and then convert to the disk copy instead of to the copy
> in memory?
>
>
>
>> So, that is because the XYZ representation of file format. You
>> may want to use LUT based profiles instead.
>>
>
> This possible sRGB LUT profile, is there one that can be made with LCMS?
> Can it be used for unbounded mode ICC profile conversions? When
> converting to the LUT profile in memory, will the accuracy be better
> than or at least as good as the accuracy when converting to a matrix
> sRGB profile from disk?
>
>> Regards
>> Marti
>>
>
> Best regards,
> Elle
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Lcms-user mailing list
> Lcms-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/lcms-user
------------------------------------------------------------------------------
_______________________________________________
Lcms-user mailing list
Lcms-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lcms-user
