msarett: Please take a look at flaky image failures on the various css3/filters/effect-reference-* tests in software mode. See: https://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=css3%2Ffilters%2Feffect-reference
I've had to clean up a lot of bad bot autorebaselines that happened because whole sections of the output image are occasionally just not appearing at all. I think the last of the bad baselines is being deleted as I write this, but there's still flakiness because the bots are still doing this. Mac 10.9 in particular seems to be affected frequently, but it's cross-platform.
AFAICT this either started happening or got much worse after your patch here landed, though I'm not 100% sure.
There's one remaining issue here:
crbug.com/657839 fast/images/color-profile-layer.html
This test used to be flaky and is still flaky. The difference is that before, at least one of the three runs would "succeed". Now, all three runs tend to be identical (but sometimes we pass and sometimes we "fail").
I plan to see if I can change the test to behave consistently.
This is a bit of a tricky answer...
There are three stages in the transform:
(1) Convert from 2.2f transfer function to linear. This is done by using the raw bytes of the input image to look up into a table of floats. QCMS and SkCT should behave identically here.
(2) Convert from Adobe gamut to sRGB gamut. This is matrix multiply. Again, I expect that we'll behave identically here, but I haven't closely examined how QCMS inverts and concats matrices.
I actually think SkCT might be able to use more precise values for its standard matrices, I might consider a change here...
https://cs.chromium.org/chromium/src/third_party/skia/src/core/SkColorSpace.cpp?l=91
(3) Convert from linear to sRGB gamma
This is most likely where the difference is. QCMS builds a 4096 entry look-up table. SkCT uses a mathematical approximation of the sRGB curve. SkCT guarantees that we will be within 1 (on a 0-255 scale) of the true value. AFAIK, perceptually this is more than good enough. QCMS accuracy will vary quite a bit - since it generally will build the 4096 entry table by interpolating and inverting the look-up table embedded in the ICC profile - it is dependent on how sRGB is encoded in the ICC dat.
Before thinking harder, I would be interested to know how the expected values are calculated for the test. I'm not too surprised by the results - SkCT meets the guarantee of worst case off by 1.
If we feel we need to do better, I imagine we could improve by tweaking the constants in sRGB/Adobe matrices or in step (3) of the xform.
Matt, I just writing to Mark, and looked at this bug again. I noticed I wasn't in cc in the bug, so I did not see you response, my apologies.
Lemme cc myself, doh. I will answer your questions tomorrow if that's ok?
#32
We note from above, that increasing the accuracy of the existing matrix values did not improve the color accuracy score. We only look at win and mac results for now, please ignore the mac results since they are bogus for other reasons.
>There are three stages in the transform:
>(1) Convert from 2.2f transfer function to linear. This is done by using the >raw bytes of the input image to look up into a table of floats. QCMS and SkCT >should behave identically here.
Agree we should be good here.
> (2) Convert from Adobe gamut to sRGB gamut. This is matrix multiply. Again, > I expect that we'll behave identically here, but I haven't closely examined
> how QCMS inverts and concats matrices.
QCMS matrix inverts and concats are good.
> I actually think SkCT might be able to use more precise values for its
> standard matrices, I might consider a change here... [link]
Not sure where you got those matrix values from. They don't look quite right to me, they have a large white-point error compared to ICC D50.
> (3) Convert from linear to sRGB gamma
> This is most likely where the difference is. QCMS builds a 4096 entry look-up > table.
Yes this might be problem area. QCMS precaches the color transform destination profile output curve, and uses a 8192 entry lookup table: refer to https://cs.chromium.org/chromium/src/third_party/qcms/src/qcmsint.h?rcl=0&l=37
Typically when you invert a small curve, you need to provide more points for the inverse curve to avoid numerical error: see
https://cs.chromium.org/chromium/src/third_party/qcms/src/transform_util.c?l=449
> SkCT uses a mathematical approximation of the sRGB curve. SkCT guarantees
> that we will be within 1 (on a 0-255 scale) of the true value. AFAIK,
> perceptually this is more than good enough. QCMS accuracy will vary quite
> a bit - since it generally will build the 4096 entry table by interpolating
> and inverting the look-up table embedded in the ICC profile - it is dependent
> on how sRGB is encoded in the ICC dat.
The accuracy of the output curve inversion is most likely another source of error.
> Before thinking harder, I would be interested to know how the expected values
> are calculated for the test. I'm not too surprised by the results - SkCT
> meets the guarantee of worst case off by 1.
We are off-by-two in places. The munsell colors are standard colors in xyY space. They can be converted by hand from xyY to any RGB color space (sRGB, Adobe) etc. Their RGB values are tabulated in various color spaces. If we take those color values in Adobe and color transform them to sRGB, the results should match (to a tolerance) the tabulated sRGB munsell colors (in pixels) [1].
[1] http://www.brucelindbloom.com/index.html?ColorCheckerRGB.html
> If we feel we need to do better, I imagine we could improve by tweaking
> the constants in sRGB/Adobe matrices or in step (3) of the xform.
Yes, the matrix values need improvement (before we look at curve inversion problems, if any). Here are the values I recommend you use:
sRGB ----------------------------------------------------
hex encoded color primaries ICC D50
0x6fa0 0x6296 0x24a0
0x38f2 0xb789 0x0f85
0x038f 0x18da 0xb6c4
hex decoding to float
{ 0x6fa0 / 65536.0, 0x6296 / 65536.0, 0x24a0 / 65536.0 },
{ 0x38f2 / 65536.0, 0xb789 / 65536.0, 0x0f85 / 65536.0 },
{ 0x038f / 65536.0, 0x18da / 65536.0, 0xb6c4 / 65536.0 },
float decoded color primaries
{ 0.43603516, 0.38510132, 0.14306641 },
{ 0.22244263, 0.71693420, 0.06062317 },
{ 0.01390076, 0.09707642, 0.71392822 },
ICC D50 white point error = 0.000001
Adobe RGB (1998) ----------------------------------------
hex encoded color primaries ICC D50
0x9c18 0x348d 0x2631
0x4fa5 0xa02c 0x102f
0x04fc 0x0f95 0xbe9c
hex decoding to float
{ 0x9c18 / 65536.0, 0x348d / 65536.0, 0x2631 / 65536.0 },
{ 0x4fa5 / 65536.0, 0xa02c / 65536.0, 0x102f / 65536.0 },
{ 0x04fc / 65536.0, 0x0f95 / 65536.0, 0xbe9c / 65536.0 },
float decoded color primaries
{ 0.60974121, 0.20527649, 0.14918518 },
{ 0.31111145, 0.62567139, 0.06321716 },
{ 0.01947021, 0.06086731, 0.74456787 },
ICC D50 white point error = 0.000001
---------------------------------------------------------
Use those in Skia and run the images/color-profile-munsell-adobe-to-srgb.html layout test on win or linux and see if that improve things.
Comment 1 by sahinoze...@gmail.com
, Oct 20 2016