Created attachment 268330 [details] [review]
Replace built-in sRGB

The attached patch replaces all occurences of cmsCreate_sRGBProfile () with code that makes an sRGB profile that is functionally the same as the ArgyllCMS sRGB.icm profile. "Functionally the same" means it has the same red, green, and blue colorants and the V4 "chad" equivalent of the ArgyllCMS V2 white point. The profile TRC is also functionally equivalent to the ArgyllCMS sRGB.icm TRC and is the same as the LCMS sRGB built-in profile TRC.

It might make sense to create one file with the sRGB profile-making code and include it where necessary, instead of repeating the code in four separate files (modules/color-selector-cmyk.c, modules/display-filter-lcms.c, plug-ins/common/lcms.c, plug-ins/file-jpeg/jpeg-load.c).

Curently Gimp uses LCMS2 to create an sRGB profile to be used with images that don't have an embedded ICC profile, and also as a user-choosable destination color space ("sRGB built-in"): cmsCreate_sRGBProfile ()

Currently the LCMS2 source code that generates this profile uses Correlated Color Temperature equations to calculate the sRGB D65 source white point: cmsWhitePointFromTemp(&D65, 6504);

The CCT 6504K white point xy values (x=0.312720535, y=0.329125536) don't match the sRGB specifications white point xy values (x=0.3127, y=0.3290). This is not a matter of more versus less precision. The right xy values to use when making the sRGB (and Adobe RGB 1998 and also at least a couple more D65 profiles) are exactly (x=0.3127, y=0.3290).

The current LCMS built-in sRGB profile isn't neutral: max white isn't equal to LAB (100, 0, 0) and R=G=B values don't equate to CIELAB a*=b*=0.

"xicclu -ir -pl profile.ext" allows you to convert from RGB values to CIELAB values. RGB values in the lcms built-in sRGB and the Argyllcms sRGB don't translate to the same CIELAB values:

Argyllcsm sRGB.icm and the patch-produced sRGB produce these CIELAB values: 
(the following white point is neutral)
max white	100.000000 0.000000 0.000000

max red	        54.290039 80.810432 69.895681
max green	87.819339 -79.273851 80.994868
max blue	29.565320 68.291889 -112.034964

(the following gray axis values are neutral)
gray128	        53.389482 0.000000 0.000000
gray64	        26.984360 0.000000 0.000000
gray32	        12.189443 0.000000 0.000000


The lcms built-in sRGB profile produces these CIELAB values:
(the white point isn't neutral)	
max white	100.000590 -0.002543 0.002250 

max red	        54.278789 80.805194 69.876284
max green	87.825968 -79.234351 80.980625
max blue	29.561496 68.289548 -112.033410

(the following gray axis values aren't neutral)
gray128	        53.389835 -0.001521 0.001346
gray64	        26.983504 -0.000942 0.000834
gray32	        12.190835 -0.000618 0.000547

max white: RGB(1.0, 1.0, 1.0)
max red  : RGB(1.0, 0.0, 0.0)
max green: RGB(0.0, 1.0, 0.0)
max blue : RGB(0.0, 0.0, 1.0)
gray128  : RGB(0.5, 0.5, 0.5)
gray64   : RGB(0.25, 0.25 0.25)
gray32   : RGB(0.125, 0.125, 0.125)

The absolute differences between the two sets of CIELAB values are:
max white	0.000590 0.002543 0.002250
max red	        0.011250 0.005238 0.019397
max green	0.006629 0.039500 0.014243
max blue	0.003824 0.002341 0.001554
gray128	        0.000353 0.001521 0.001346
gray64	        0.000856 0.000942 0.000834
gray32	        0.001392 0.000618 0.000547

These are not large difference and I can't imagine how it could possibly make a difference in 8-bit image editing. 

In high bit depth image editing, again, for most edits, it won't make a perceptible difference. But it can make a perceptible difference if the editing move is extreme enough.

Does having a truly neutral white point and gray axis matter matter in scientific imaging?