As discussed with ccameron@, we can remove canvas color extensions and turn on color correct rendering by default for canvas. The legacy behavior can be detected by using CanvasColorParams::UsesOutputSpaceBlending() API (and the fact that user has not provided a color space).
There is only one issue with CreateImageBitmap colorSpaceConversion option. The legacy behavior for "default" is to color convert to display color space, and the current color corrected behavior is to color convert to SRGB. We should make a decision on what to do when color correct rendering is on by default.
Huh, it seems that we cannot do this as there is no way to find out if the provided attribute (for example the color space in CanvasContextCreationAttributes) is the default value or is provided in js.
I have a question as to how to interpret this bug. It's not clear to me if the feature is implemented yet, but off by default, or not.
I enabled experimental canvas in flags, and it recognizes colorSpace in getContext (in that it complains about an invalid value such as "sRGB"), but a profile-less image displayed with drawImage was not assumed to be sRGB. I also tried "bitmaprenderer" rather than "2d", with the same effect.
PS. It's a separate issue, but I was surprised how slow "bitmaprenderer" in combination with createImageBitmap and transferToImageBitmap is, compared to using drawImage on "2d". Perhaps there's already a bug for that someone can point me to.
@pdknsk #6: This feature is "almost" implemented but it might have some bugs, and it is off by default. I suggest waiting until we address the remaining issues.
To test the feature anyway, you need both --enable-experimental-canvas-features and --enable-color-correct-rendering flags. You should not need to set any color space or so, as it should silently set sRGB as the color space of the canvas and other resources.
It's from an internal page, so I'd have to reduce it.
I figured out that it only affects images that don't match canvas-size.
(Using 1 + 8 parameters with drawImage to crop the image.) Images with
exact canvas-size render fine.
I also noticed severe (non-canvas) image corruption
when enable-color-correct-rendering is used with enable-gpu-rasterization,
like with this simple icon.
https://ssl.gstatic.com/ui/v1/icons/mail/no_photo.pnghttp://cdn.pwmon.org/chrome/no_photo.png
pdknsk@: I can see that the second icon has some artifacts (the first one is okay) but I don't think this is a Chromium bug. I can see the same artifacts in Firefox or when using wget + gimp. I guess something might be happening on your server side (image manipulation may be? like crbug.com/747640#c30 ?).
Comment 1 by zakerinasab@chromium.org
, Jun 14 2017