->kbr for triage. Not sure what the spec says.

I'm not sure what would be needed to support wide gamut images in this path. Reza, can you at least advise us?

I'm not very knowledgeable about the latest state of half float support in WebGLRenderingContextBase, and this might be an intentional decision due to compatibility issues. When the ExtractImage is called in ImageExtractor ctor, the image decoder either ignores the color space or converts the color space to sRGB:

https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/graphics/gpu/WebGLImageConversion.cpp?type=cs&sq=package:chromium&l=2815

IIUC, we can pass ColorBehavior::Tag() here to preserve the wide gamut color profile of the input image when getting the SkBitmap from the decoded frame. Assuming that arbitrary color profiles are supported as long as we stick to 8888 pixel storage, this prevents precision loss due to wide gamut -> sRGB -> wide gamut color conversion in 8888 storage mode if the display profile is wide gamut down the road.
If half float storage is supported for the input image, then the gain of preserving the wide gamut profile would be more, as it also should / might (depending on the decoder) preserve the pixels in half float precision.

I'm not an expert on color management, but it seems to me that if we convert these images to any color space except sRGB then we'll also need to know what the color space of the WebGL-rendered canvas is. This ties into the Canvas.getContext() API and the option to select the intended color space / profile of the canvas. Right now there's a basic assumption that the WebGL canvas is rendered in the sRGB color space.

Additionally, we can't auto-upgrade textures from RGBA8888 to RGBA16F; the WebGL developer will need some way to know that they're working with a wide-gamut image, and explicitly opt-in to uploading that image to an RGBA16F texture. Is it possible to make these kinds of queries against an HTMLImageElement from JavaScript?

From what I see the color space attribute of the Canvas.getContext() is properly propagated to the WebGLRenderingContext constructor. My assumption was that the related code respects this color space and there is no assumption for it to be sRGB. I'll keep this bug as the owner and will come back to this when I'm done with context 2d and started looking into webgl context.

Regarding the pixel format, IIUC there is no need to upgrade to RGBA16F, at least for HTMLImageElement. AFAIK no image format supports half float pixel storage, and PNG is the only one that supports uint16 pixel format, which doesn't seem to be common (I might be wrong, though). Therefore, we must be able to keep the pixels in RGBA8888 but still stick to the original color profile of the wide gamut image to avoid precision loss in unnecessary color conversions.

Thanks for taking this Reza. Let's sync up when you come back to it. The thing I don't understand is: if we don't convert these wide-gamut images into the sRGB color space when uploading them to WebGL textures, then when they're drawn into the canvas (which is assumed to be in the sRGB color space), they'll look wrong to the best of my understanding.

I did a little bit of investigation. Apparently, there is no way to tag the textures with any color space other than sRGB, which makes the current implementation correct.
From color correction perspective, this is inefficient. This means that we have to convert the wide gamut source image to sRGB (which results in precision loss) and convert it back to the color space of the canvas, if necessary (which results in more precision loss). For now, there is no way to avoid this.
I'm  flagging this bug as won't fix.