According to https://github.com/WICG/canvas-color-space/blob/master/CanvasColorSpaceProposal.md#imagedata, the expected behavior of color managed ImageData is as follows:

* ImageData imagedata = ctx.getImageData(sx, sy, sw, sh);
* ImageData imagedate = ctx.createImageData(width, height);
No color conversion. imagedata follows the color settings of the canvas.

* void ctx.putImageData(imagedata, dx, dy, ...);
* ImageData imagedata = ctx.createImageData(imagedata);
Color conversion, if needed, to the color settings of the canvas.

*ImageData ctx.createImageData(width, height, imageDataColorSettings);
No color conversion to the color settings of the canvas. ImageData will be created based on imageDataColorSettings.

*ImageData ctx.createImageData(data, width, height, imageDataColorSettings);
Color conversion, if needed, from the color settings of the canvas to imageDataColorSettings.

Currently, Chrome supports the following combinations of color space and pixel format:
* Legacy and SRGB, Uint8
* LinearRGB and P3 and Rec2020, Float16

However, for ImageDataColorSettings, both Uint8 and Float32 (not supportig Uint16 for now) can be used with a SRGB, linear RGB, P3 or Rec2020 color space.
* Uint8+SRGB and Float32+{linearRGB,P3,Rec2020} is straightforward.
* Uint8+{linearRGB,P3,Rec2020} requires storage format conversion to float16 (or float32->float16) when put to a float16-backed canvas. floatVal = uintVal / 255.0.
* Float32+SRGB requires storage format conversion and clamping when put to a canvas (with any color space). uintVal = std::max(0, std::min(255, std::floor(floatVal * 255))).

We should first verify that the above behavior is correct. Next, we need to provide enough layout test coverage. Some tests are already present in third_party/WebKit/LayoutTests/virtual/color_space/fast/canvas/color-space/.