Observations:
1. I tapped into the PaintShader (which is used to store the image pattern inside the PaintFlags, which is sent to canvas->drawRect()). Looking at the SkImage storage containing red_at_12_oclock_with_color_profile.jpg in PaintShader, the red is already at 12 oclock, which IIUC means that the image is already color converted to sRGB in the decoder, and rules out the assumption that we are not doing any color conversion in the pipeline.
* If the color profile of the image is not applied, I expect to see a bluish color at 12 oclock in the paint shader, like what we have here: https://fiddle.skia.org/c/58b0526ceb05f5c6efe948e8f8b38ea1
2. However, the internal SkImage in PaintShader does have a color space, but it is not sRGB. The other plausible option was that may be it is still ColorSpin even though the image is decoded to sRGB. We cannot rely on SkColorSpace::Equals() to check ColorSpin since there is no guarantee that the ICC profile created by SkImage::MakeFromEncoded() is the same as the one generated by the image decoder. FWIW, SkColorSpace::Equals() returns false when comparing the color space of the paint shader SkImage with the one extracted from the file by SkImage::MakeFromEncoded(). There is a ICCProfileForTestingColorSpin() in ui/gfx/test/icc_profiles.h, but apparently it cannot be accessed from cc/paint/paint_shader.cc.
To rule out the possibility of having double colorpsin->sRGB color correction, I imitated the behavior in a fiddle. The double color correction output can be seen at the bottom left of the output here: https://fiddle.skia.org/c/85fad125b51e5701ff93a4aee6ec888b.
3. Assuming that we already ruled out having no color conversion in step 1,
surprisingly, the only way that we might get what we see in https://chromium-review.googlesource.com/c/chromium/src/+/598500/11/third_party/WebKit/LayoutTests/images/color-profile-image-canvas-expected.png is to have a reverse color conversion from sRGB to ColorSpin, as shown in the bottom right corner of the output here: https://fiddle.skia.org/c/85fad125b51e5701ff93a4aee6ec888b. However, AFAICT this doesn't make sense.
I think the source of the problem is somewhere in the image decoder when the color space of the SkImage is not set correctly. This is okay for legacy canvas as there is no color conversion there but messes with the color managed canvas. Please let me know if anything comes to your mind.
Comment 1 Deleted