GNOME Bugzilla – Bug 724822
Make gegl's create_lcms_linear_rgb_profile match Gimp's gimp_lcms_create_srgb_profile
Last modified: 2015-05-23 13:08:14 UTC
Created attachment 269828 [details] [review] Make gegl's create_lcms_linear_rgb_profile match Gimp's gimp_lcms_create_srgb_profile See https://bugzilla.gnome.org/show_bug.cgi?id=723787 for details. This patch makes the gegl-created linear gamma sRGB primaries match the Gimp sRGB primaries, which in turn match the ArgyllCMS primaries, which are neutral, mapping R=G=B=1 to the ICC profile D50 illuminant, and are made using the sRGB specs D65 values. The primaries are prequantized to compensate for the fact that the LCMS profile-making code doesn't account for hexadecimal quantization.
I had been meaning to change the illuminant D65 values since the gimp values changed, thanks. About the prequantization: The statement that "the LCMS profile-making code doesn't account for hexadecimal quantization" is a little misleading. LCMS quantizes the values itself from floating point numbers to 32-bit integers, and does it correctly; just when it does the quantization it tries to minimize the amount of error in each of the whitepoint primaries. Greame, however, has changed his quantization so it actually increases the error in some of the primaries, while reducing the error in the sum of the primaries. They're both valid ways to quantize, just Greame's quantization has benefits for the whitepoint tag. That being said, the prequantization bothers me a little. If we're going to rely on getting the exact, correctly rounded integer values from lcms, then we should probably find a way to give lcms the correct values directly instead of trying to undo everything the cmm does, and then hoping that the cmm will redo everything the way we expect it to. I'm going to see if we can use the lcms api to specify whitepoint values that have already been adapted and quantized. It should be possible using some of the raw tag api's of lcms, although it might be a bit of a hack. In the meantime, I'll commit your patch.
commit f956b8999f519496fae001d100cf22d9fccad7c9 Author: Elle Stone <ellestone@ninedegreesbelow.com> Date: Thu Feb 20 14:09:12 2014 -0500 operations: Make linear sRGB using sRGB D65 white point
(In reply to comment #1) > I had been meaning to change the illuminant D65 values since the gimp values > changed, thanks. > > About the prequantization: The statement that "the LCMS profile-making code > doesn't account for hexadecimal quantization" is a little misleading. LCMS > quantizes the values itself from floating point numbers to 32-bit integers, and > does it correctly; just when it does the quantization it tries to minimize the > amount of error in each of the whitepoint primaries. Greame, however, has > changed his quantization so it actually increases the error in some of the > primaries, while reducing the error in the sum of the primaries. They're both > valid ways to quantize, just Greame's quantization has benefits for the > whitepoint tag. Recalling what Graeme said, you are absolutely right. There is a tradeoff between one error and the other. I think that tradeoff can't be eliminated, a choice must be made. With the prequantization and using the D65 value in the sRGB specs, the gimp/gegl code makes a profile that has the same primaries as Graeme's profiles and is also neutral. Without the prequantization and using the D65 values in the sRGB specs as the source white point, the resulting LCMS profile will have slightly different primaries and a slight deviation from neutrality. Using the LCMS D65 values results in primaries that are farther from being neutral and also farther from the ArgyllCMS sRGB profile. It seems to me that having R=G=B=1 equate to CIELAB (100,0,0) is a good thing when doing high bit depth image editing. One could argue that it really doesn't matter in most if not all actual image editing applications. I haven't seen a good case one way or the other, but my preference is for neutral profiles. What finally convinced me that prequantized primaries were the way to go was the fact that I wasn't able to make an Adobe 1998 compatible profile using LCMS that exactly matched the values given in the Adobe RGB 1998 specifications (which unlike the sRGB specs tells you exactly what the adapted profile primaries should be), without using prequantized primaries back-calculated from the ClayRGB primaries that do match the Adobe specs exactly. Otherwise there is a slight deviation from neutrality (the same deviation as in the sRGB profile) and the resulting primaries don't exactly match the Adobe-specified adapted primaries. I mentioned this on the lcms mailing list (http://sourceforge.net/mailarchive/forum.php?thread_name=52F14018.2080605%40ninedegreesbelow.com&forum_name=lcms-user) but didn't receive a reply. > That being said, the prequantization bothers me a little. If we're going to > rely on getting the exact, correctly rounded integer values from lcms, then we > should probably find a way to give lcms the correct values directly instead of > trying to undo everything the cmm does, and then hoping that the cmm will redo > everything the way we expect it to. I'm also not happy with resorting to prequantization. However, once the profile is created, it's handled in ICC profile conversions just like any other profile. Leastways I haven't seen any reason to suspect otherwise. I could do some testing if you like. LCMS doesn't "know" that the neutral, ArgyllCMS-matching profile produced in gimplcms.c was produced using prequantized primaries. After the profile is made, it's just a profile. > I'm going to see if we can use the lcms api to specify whitepoint values that > have already been adapted and quantized. I'm not sure what you mean but if there's any way I can help, let me know. The D65 white point values in the lcms built-in function for making the sRGB profile are not the same values that are found in the sRGB specs. I asked about this on the lcms mailing list (http://sourceforge.net/mailarchive/forum.php?thread_name=52F3BBD3.5040705%40ninedegreesbelow.com&forum_name=lcms-user) but didn't get a reply from Marti. It could be argued that the sRGB specs are wrong, I suppose. But the HP sRGB profiles and the color.org V2 sRGB profiles do use the sRGB specs values for D65, which is the same D65 values used in the Adobe RGB 1998 profile and the Adobe AppleRGB profile and so on. > It should be possible using some of > the raw tag api's of lcms, although it might be a bit of a hack. > > In the meantime, I'll commit your patch. The alternatives I could see were: *Use the D65 values hard-coded in LCMS, which don't match the D65 values in the sRGB specs. *Use the D65 values in the sRGB specs, don't prequantize the primaries, and accept the fact that there is a slight deviation from neutrality in the resulting profile. *Use the prequantized, back-calculated primaries to produce a profile that matches the ArgyllCMS sRGB profile and is truly neutral. I didn't like any of the choices, but the last choice seemed the least objectionable. As a way of confirming to my own satisfaction that it was an acceptable choice, I put together a spreadsheet that calculates the Bradford-adapted sRGB primaries from the values in the sRGB and ICC specs. It's available as a download from this article which explains the math behind Bradford chromatic adaptation: http://ninedegreesbelow.com/photography/srgb-color-space-to-profile.html