Luminous Landscape Forum
Raw & Post Processing, Printing => Colour Management => Topic started by: Doug Gray on July 30, 2019, 02:05:29 am
-
Printing accurate colors not only depends on profile quality, but on the color engine used.
It's been known for some time that, in Photoshop, ACE has smaller conversion errors than ICM. See Jim Kason's post (https://blog.kasson.com/the-last-word/icm-vs-ace/). However, this was looking at errors in converting RGB matrix spaces.
I'm trying to nail down the cause of *very* small discrepancies when printing larger numbers of colors using I1Profiler and Argyll profiles.
From testing, there are 4 different color engines involved. For Photoshop there is Adobe ACE and Microsoft ICM. For MATLAB, there is LCMS. And I'm not sure what there is for Argyll but it's different from the other three.
To get a quantitative evaluation of these 4 CMEs, I made a set of 2,000 in-gamut LAB colors for the Pro1000 with MP101 paper. These were then converted to device RGB using each of the 4 CMEs. The small differences in rgb values differed, on average, from about .4 bits to 3.2 bits (geometric distance between triplets based on 0:255).
ACE and ICM values were obtained using a 16 bit Lab tif image in Photoshop and converting to the device profile.
The MATLAB LCMS values were obtained converting the Lab values using the Color Toolkit. The Argyll CME's values were obtained using the xicclu utility.
These are the differences:
ACE:MATLAB 0.39 dE00: 0.04
ACE:ARGYLL 0.89 dE00: 0.10
ACE:ICM 3.19 dE00: 0.40
ICM:MATLAB 3.20 dE00: 0.40
MATLAB:ARGYLL 0.75 dE00: 0.09
The ICC does not specify how algorithms interpret 3DLUTs. It's up to the color engine coders. And there is no ideal way to interpolate 3DLUTs. One possible approach to testing profile/cme accuracy is to create a synthetic patch rgb/lab set with zero noise and lots of patches then see how the profiles perform with each of the CMEs.
However, outside of ICM, these are all reasonably close but I start to see the effects of these different engines when comparing say, 1000 color patches and averaging the printed accuracy.
Anyone know of there is a way to use the ACE inside MATLAB or perhaps with C++ code?
-
They used to have ACE as a separate colorengine on the Mac. If you set the profile preferred CMM the system might use the preferred engine. Not sure if that engine is still available separately. Also note that a profile has a setting for conversion quality which might need to be set to "best" prior to conversion. Whether any of the settings are actually used is still completely opaque. Lots of uncertainties therefor considering the amount of precision you're seeking. Have you calculated what deviations can be considered significant btw, relative to the number of measurements and overall process variability?
-
Have you calculated what deviations can be considered significant btw, relative to the number of measurements and overall process variability?
Especially shot and quantization noise at 8 bits: 1/sqrt(12) is 0.3 dE, right? Have you tried 16 bits or accounted for things like ACE's non-standard toe linearization in Adobe RGB? 0.09 dE is very low and it would probably pick up such low level effects?
-
Especially shot and quantization noise at 8 bits: 1/sqrt(12) is 0.3 dE, right? Have you tried 16 bits or accounted for things like ACE's non-standard toe linearization in Adobe RGB? 0.09 dE is very low and it would probably pick up such low level effects?
This is strictly the printing profile side of things where I start with a 16 bit LAB image so it goes directly to the LAB PCS then the 3DLUT process. There was an issue with low L* toe conversion for matrix images but Photoshop changed that years ago and there is no linear toe since PS6 or so. I did test images in ProPhoto and the conversions are essentially identical now. Errors are in the conversion from Lab PCS to device RGB.
-
This is strictly the printing profile side of things where I start with a 16 bit LAB image so it goes directly to the LAB PCS then the 3DLUT process. There was an issue with low L* toe conversion for matrix images but Photoshop changed that years ago and there is no linear toe since PS6 or so. I did test images in ProPhoto and the conversions are essentially identical now. Errors are in the conversion from Lab PCS to device RGB.
I understand. I presume device RGB is typically linear 8 bits and then you convert back to LAB again to obtain a dE to the original 16-bit LAB image? So without dithering you may be getting some quantization errors while in 8 bits?
-
I understand. I presume device RGB is typically linear 8 bits and then you convert back to LAB again to obtain a dE to the original 16-bit LAB image? So without dithering you may be getting some quantization errors while in 8 bits?
The RGB for profiles is strictly 8 bits, 0:255. It's provided together with measured Lab values, rounded to hundredths, (no spectral) and input to each of the profile creating programs.
-
Ignore the rest of this post (except for the part about how bad ICM is). I made a gross error in comparing Adobe ACE. I compared the BtoA1 conversion, which is from Lab to RGB against the AtoB1 conversion which goes from RGB back to Lab. They differ wildly in accuracy and, as a result, I slammed Adobe Photoshop ACE in error.
Let this be a lesson for me. I'm in the process of properly comparing Apples to Apples (not the iOS kind). I will crosscheck my work against BruceLindblooms color calculator and post revised resulted.
Again: read the rest of this as an example of how not to do an experiment.
Some more work shows that Adobe's ACE has built in inaccuracies, but Microsoft's ICM is even worse.
This is quite astonishing. Here's the gory details.
First I made a "printer" profile that basically acts as if a printer could precisely print Adobe RGB directly in device space. It used a set of 35937 (33x33x33 points) patches where the Lab values were calculated from the Adobe RGB spec. This profile did an excellent job of converting rgb values to/from printer space with tiny errors under .02 dE in both MATLAB and Argyll. This seems reasonable since the calculated Lab values were rounded to two places. There was no significant difference between profiles made with Argyll (.020 dE) or I1Profiler (.013 dE).
Next, I generated a random set of 100,000 RGB triplets. Converted this to a reference Lab set.
Then, to test Adobe ACE, I created a 16 bit tif image in Lab. Converted it to device space using the profiles generated above. Then I read the 16 bit image in MATLAB which should have been very close to the ideal RGB values.
Converting these device RGB values to Lab and comparing them to the initial Lab values produced an average error of about dE .40 with a worst case of dE 3.6. Holy Cow. MATLAB and Argyll's utilities show errors of under .02.
On examining what colors were altered the most, turns out they were strong, luminous, violets. Colors not printable by any printer. Noting that under 30% of Adobe RGB can be printed on the Pro1000 with MP101 paper, the conclusion is that Adobe ACE simply is a crappy CME. But if it was that bad, why wouldn't this have been noticed before.
Worst Color, full Adobe RGB gamut where the average dE is: .40
Lab device rgb Lab Diff
33.7 57.2 -107.7 34.0 54.7 -105.1 dE:3.60
Perhaps Adobe's ACE, which was created back in the dark ages of PC CPU power, converts profiles into some simpler form to speed up calculations. And perhaps they focus on the portions of Adobe RGB that are actually possible to print. After all, speed was essential to Photoshop performance and the fastest possible conversion through printer profiles critical for soft proofing.
To test this theory, I created another set of Adobe RGB triplets but ones that were also within gamut of the Pro1000. Then I ran the same tests to see if the average and max errors were reduced. They were. Significantly.
Worst Color, Adobe RGB gamut limited to Pro1000 gamut where the average dE is: .13
Lab device rgb Lab Diff
36.5 -9.6 -49.7 36.8 -8.3 -48.7 0.93
Please note that the average errors of .13 dE will decrease as other error sources accrete. This is because most errors are statistically independent. For instance, another error source of .30 dE will only be increased to .33 dE. So whatever simplification Adobe did in making ACE, the impact on real printing errors is negligible and one has to go to considerable effort to see any differences even using high end spectros.
So if one wants the absolute best conversion using printer profiles the choices are Argyll or MATLAB. Both are an order of magnitude better than ACE with synthetic profiles and slightly better once your profile accuracy is better than about .40 dE.
I've added the "printer" profile used above that does a very close conversion into Adobe RGB as if one had a perfect printer that could print the entire Adobe RGB color set directly from RGB.
-
The MATLAB LCMS values were obtained converting the Lab values using the Color Toolkit.
Is that a Mathworks product? If so, I'd like some information about it.
I'm using optprop, but it's unsupported and is starting to have compatibility issues with the current Matlab releases.
Jim
-
The ICC does not specify how algorithms interpret 3DLUTs. It's up to the color engine coders. And there is no ideal way to interpolate 3DLUTs.
Here's one way I like:
Kasson, J.M., Nin, S.I., Plouffe, W.E., and Hafner, J.L., “Performing Color Space Conversions with Three-Dimensional Linear Interpolation, Journal of Electronic Imaging, vol. 4, July 1995, pp. 226-249.
http://spie.org/Publications/Journal/10.1117/12.208656?SSO=1
But I'm biased. 😉
Jim
Jim
-
Is that a Mathworks product? If so, I'd like some information about it.
I'm using optprop, but it's unsupported and is starting to have compatibility issues with the current Matlab releases.
Jim
Hi Jim. It is indeed. I've found MATLAB and the Color toolkit called formally, "Image Processing Toolkit" quite accurate though it has no spectral processing. And I've written a bunch of functions that make interacting with it quite simple. For example:
rgb=rand(100000,3);
rgb_rt=ProfileConvert(rgb, 'profileUnderTest.icm', 'r', 3, 'f', 3);
This does the same thing but is wordier:
rgb_rt=ProfileConvert(ProfileConvert(rgb, 'profileUnderTest.icm', 'r', 3), 'profileUnderTest.icm', 'f', 3);
This does a round trip through the profile from device space rgb, to Lab, then back to rgb. Takes about a second.
If you are interested, I can provide the code for this function but you need MATLAB and the image toolkit.
-
Here's one way I like:
Kasson, J.M., Nin, S.I., Plouffe, W.E., and Hafner, J.L., “Performing Color Space Conversions with Three-Dimensional Linear Interpolation, Journal of Electronic Imaging, vol. 4, July 1995, pp. 226-249.
http://spie.org/Publications/Journal/10.1117/12.208656?SSO=1
But I'm biased. 😉
Jim
Jim
Jim,
Interesting paper! MATLAB, when it loads an ICC profile, generates nested tables for all the constructed LUT elements in the profile. Given how large the grids are in them I'd guess the errors associated with LUT interpolation are rather small in comparison to whatever assumptions are made in creating the profile. OTOH, the BtoA tables are quite coarse on the a* and b* axes with steps of over 7 between LUTs because they have to cover a range of 127/-128. AT least for standard I1Profiler profiles with grid count of 32 and Argyll -qh with grid count of 33.
Any idea if you or someone else has explored evaluating the techniques in your paper using MATLAB with it's easy access to the profiler internals?
-
The RGB for profiles is strictly 8 bits, 0:255. It's provided together with measured Lab values, rounded to hundredths, (no spectral) and input to each of the profile creating programs.
Hmm, not sure I understand. Example:
1) Reference D50 Lab value [10.00 9.00 -9.00]
2) sRGB value (FP) [34.9922 23.2651 39.7778]
3) 8 bit Profile Result [35 23 40]
4) D50 Lab of 8 bit profile [9.9290 9.2344 -9.2725]
5) dE 1->4 0.3663
The dE in step 5 is due to quantization in step 3. Is this what you are doing?
Indipendently of that, what white point are your color engines using? D50's XYZ coordinates are defined in as many different ways as one looks up sources. Same as formulas for XYZ to Lab and back.
Jack
-
The ICC does not specify how algorithms interpret 3DLUTs. It's up to the color engine coders. And there is no ideal way to interpolate 3DLUTs.
On the input end of the processing chain, the DNG Spec (http://wwwimages.adobe.com/www.adobe.com/content/dam/acom/en/products/photoshop/pdfs/dng_spec_1.5.0.0.pdf) specifies trlinear interpolation of the HSV LUT, accessed via ProPhotoRGB. Many dcp profiles contain 90x30x30 tables resp, with H optionally gamma encoded.
Jack
-
Hi Jim. It is indeed. I've found MATLAB and the Color toolkit called formally, "Image Processing Toolkit" quite accurate though it has no spectral processing. And I've written a bunch of functions that make interacting with it quite simple. For example:
rgb=rand(100000,3);
rgb_rt=ProfileConvert(rgb, 'profileUnderTest.icm', 'r', 3, 'f', 3);
This does the same thing but is wordier:
rgb_rt=ProfileConvert(ProfileConvert(rgb, 'profileUnderTest.icm', 'r', 3), 'profileUnderTest.icm', 'f', 3);
This does a round trip through the profile from device space rgb, to Lab, then back to rgb. Takes about a second.
If you are interested, I can provide the code for this function but you need MATLAB and the image toolkit.
I have both, and I'd be interested in the code. Thanks.
Jim
-
Any idea if you or someone else has explored evaluating the techniques in your paper using MATLAB with it's easy access to the profiler internals?
None. I'm not interested in doing it myself a) because that low-level detail is not what I'm interested in anymore, and b) because that kind of thing is nearly useless unless it runs fast and I have neither the knowledge nor the interest to optimize the code properly.
Jim
-
I have both, and I'd be interested in the code. Thanks.
Jim
Sure, I've attached the MATLAB function here:
A few notes.
The '-f' and '-r' are followed by an int n which is the intent mode: 0: Perceptual, 1:Colorimetric, 2: Saturation, 3: Absolute. The '-f' goes from PCS Lab to device RGB (B2A). The '-r' goes from device RGB to Lab (A2B).
The 'b' option should be used with mode 1 and fairly closely, but not exactly, corresponds to Relative Colorimetric with BPC. It does the same thing as the 'f' option with BPC added. There is no reverse that undoes it.
Oh, and this requires that the profile be in PCS LAB, which are the large majority of printer profiles.
-
Sure, I've attached the MATLAB function here:
Thanks!
Jim
-
I've broken down the analysis of Adobe's Color Management Engine in two major phases using Adobe's ACE and Microsoft's ICM. The first phase analyzes the conversion from device space RGB to Lab. This is typically the most accurate conversion since the full RGB device space also uses the full AtoB Colorimetric 3DLUTs in the profile.
A random set of 100,000, 8 bit RGB values that are also in-gamut of the Pro1000 with MP101 Matte,was used to create a tiff image. In Photoshop the image was first converted to 16 bits to get the highest precision in subsequent operations. Then the image was assigned the I1P profile and Argyll profile from the ideal Adobe RGB printer created with the 35957 patch sets of RGB and LAB pairs that map Adobe RGB into Lab.
Both images were then converted to LAB in Photoshop using both ACE and ICM and saved as 16 bit tiff files in CIELAB space. These were then read by MATLAB and compared to the actual Lab values from an Adobe RGB to LAB conversion producing average dE76 conversion errors for each.
This produces 4 results.
Using Adobe's ACE:
Argyll: .032 and I1Profiler: .019
Using Adobe's ICM:
Argyll: .045 and I1Profiler: .226
Interestingly, the ICM conversion was far worse with the I1Profiler than the Argyll profiles. So much so that I made a single patch of the worst case color, RGB(234, 206,20), and compared the color after conversion in Photoshop using the I1Profiler's profile with ICM against Bruce Lindbloom's color calculator. S/B Lab(84.44, 1.80, 91.13) but was Lab(84.34, 1.63, 90.77).
Next, I looked at the ACE and ICM conversion accuracy in Photoshop going from the working colorspace (16 bit Lab) to device RGB for the Argyll and I1Profiler profiles. These differences were much larger which is to be expected since a large fraction of the BtoA, 3DLUTs are not used converting to the printer's RGB scape. Errors are average dE76.
Using Adobe's ACE:
Argyll: .13, I1Profiler: .11
Using Adobe's ICM:
Argyll: .73, I1Profiler: .77
Again, the ICM shows much higher conversion errors but now for both profiles and not just the I1Profiler one. These were also verified against Bruce Lindbloom's calculator.
The largest ICM error was: 2.656 for
RGB (54 140 167) S/B Lab(52.12,-34.77, -26.93) was( 51.88,37.34, -27.58)
I suspect that Microsoft's ICM is simply defective and doesn't handle the variations in profile construction according to the ICC spec. There were a lot more ambiguities in the spec back when ICM was created.
However, how to explain the differences between Argyll and I1Profiler using Adobe's ACE with the latter being slightly better. It could be the construction of the grid points in the LUTs differ slightly. There is an interaction between the CME and Profile construction. If a profile is constructed assuming the CME it will be used with uses tri-linear interpolation, then the LUT grid points won't be set at their match, but rather will be set to minimize average error across the interpolation space. If I1Profiler's profiles were designed this way it would account for the small differences.
-
Since you are trying to investigate such low level effects, what white points do each of your tested methods use? What about Lab<->XYZ conversion formulas? How is chromatic adaptation performed? Also, do any of these use FP vs Integer math internally?
E.g. This is D50's White Point in XYZ as specified by ICC [31595 32768 27030]/32768 = [96.4203 100.0000 82.4890]. Bruce Lindbloom says [96.4220 100.0000 82.5210]. dE is 0.0260.
Jack
-
Since you are trying to investigate such low level effects, what white points do each of your tested methods use? What about Lab<->XYZ conversion formulas? How is chromatic adaptation performed? Also, do any of these use FP vs Integer math internally?
E.g. This is D50's White Point in XYZ as specified by ICC [31595 32768 27030]/32768 = [96.4203 100.0000 82.4890]. Bruce Lindbloom says [96.4220 100.0000 82.5210]. dE is 0.0260.
Jack
Yes indeed, there are small differences with ICC v equation based due to the 15 bit math ICC (and Adobe) uses. The Lab value for RGB 255,255,255 is 100.00,0.00,0.02 I rounded the Lab values in the RGB/LAB set used to make the synthetic Adobe RGB "Printer" profile.
One effect is that the profiles generated by I1Profiler and Argyll take the .02 difference as a media white point shift form D50 This shows when doing an AtoB transform in Abs. Col. with a small shift in the opposing direction. But, as expected, conversions using Rel. Col. come out to exactly 100,0,0 in MATLAB as they scale to the media WP.
I haven't been looking at chromatic adaptation using printer profiles, or Adobe RGB for that matter as their values are already D50 based.
You stimulated an idea that I need to check.
Create a set of RGB/LAB values based on aRGB but with a white point set to something typical of a printer, say 95,1,-5 then check how close Argyll/I1Profiler profiles match. They should still match within 15 bit rounding errors. If they don't that would account for some of the larger variations and would indicate they are doing different adaptations to/from media white point. I made the Argyll profiles setting "Wrong von Kries" as recommended some time back by Graeme for compatibility.
Might be worth noting that out of the 35937 RGB/LAB pairs used to create the synthetic Adobe RGB printer profile, 6 are outside the LAB PCS. The worst by a bit over 1 dE. The fact that Adobe RGB doesn't fit in ICC LAB may affect the stats. This may be a cause of the slight differences in the AtoB between I1Profiler and Argyll. They could deal with these Lab values that are out of ICC range differently.
-
Since you are trying to investigate such low level effects, what white points do each of your tested methods use? What about Lab<->XYZ conversion formulas? How is chromatic adaptation performed? Also, do any of these use FP vs Integer math internally?
E.g. This is D50's White Point in XYZ as specified by ICC [31595 32768 27030]/32768 = [96.4203 100.0000 82.4890]. Bruce Lindbloom says [96.4220 100.0000 82.5210]. dE is 0.0260.
Jack
Yup. I changed the synthetic AdobeRGB printer profile to scale the WP to the MP101 matte paper. Then I made Argyll and I1Profiles and checked the AtoB results over a random rgb set. Average dE was .23 which is way above roundoff error or the small discrepancies n D50 between CIE and ICC.
That is the sort of error I would expect if the Wrong_Vonkries global setting wasn't working. It's still fairly small but that's because I'm using M2 measurements for the paper scans. My error. I was using this:
SET ARGYLL_CREATE_WRONG_VON_KRIES_OUTPUT_CLASS_REL_WP
and I should have been using this:
SET ARGYLL_CREATE_WRONG_VON_KRIES_OUTPUT_CLASS_REL_WP=1
This was a major problem as it caused slightly greater error in Argyll v I1Profiler. It would have been more obvious had I been using M0 or M1.
-
Yup. I changed the synthetic AdobeRGB printer profile to scale the WP to the MP101 matte paper. Then I made Argyll and I1Profiles and checked the AtoB results over a random rgb set. Average dE was .23 which is way above roundoff error or the small discrepancies n D50 between CIE and ICC.
That is the sort of error I would expect if the Wrong_Vonkries global setting wasn't working. It's still fairly small but that's because I'm using M2 measurements for the paper scans. My error. I was using this:
SET ARGYLL_CREATE_WRONG_VON_KRIES_OUTPUT_CLASS_REL_WP
and I should have been using this:
SET ARGYLL_CREATE_WRONG_VON_KRIES_OUTPUT_CLASS_REL_WP=1
This was a major problem as it caused slightly greater error in Argyll v I1Profiler. It would have been more obvious had I been using M0 or M1.
Interesting. I am not very familiar with Argyll. Are Argyll, ICM, ACE all using the same wavelength/M-weight range to compute the white point?
-
Interesting. I am not very familiar with Argyll. Are Argyll, ICM, ACE all using the same wavelength/M-weight range to compute the white point?
Argyll is a nice collection of open source color management tools by Graeme.
https://argyllcms.com/
When comparing different tools I only use RGB/LAB(at D50) pairs. There are subtleties like interdevice variations, etc. when including spectral data and it's best to avoid them unless a good reason to stray from D50 exists.
Adobe ACE, like other CMEs, don't use spectral data. It's not part of ICC profiles except for the most recent, post V4 which is pretty nascent.
-
Adobe ACE, like other CMEs, don't use spectral data. It's not part of ICC profiles except for the most recent, post V4 which is pretty nascent.
It's a great job you've done. Thanks for sharing.
Spectral data color engine only available in limited software. ONYX(it's a RIP) is one of them. The new version support iccMAX rendering and building. iccMAX is called ICC V5 or ICC2. It has the ability to use spectral data and supports spectral PCS. Better than ICC V4 which use a fixed D50 PCS. It's mainly develop by Max Derhak, Co-Chair of ICC and also principal scientist of ONYX. That's why ONYX is the first RIP to support iccMAX. Don't know when will Adobe support it.
iccMAX page in ICC website (http://www.color.org/iccmax/index.xalter)
official open source implementation on GitHub (https://github.com/InternationalColorConsortium/RefIccMAX)