Currently, the image format and the quality parameter are passed separately (https://html.spec.whatwg.org/multipage/canvas.html#the-canvas-element):
USVString toDataURL(optional DOMString type, optional any quality);
void toBlob(BlobCallback _callback, optional DOMString type, optional any quality);
It seems better to consider a dictionary, similar to what has been proposed for OffscreenCanvas.convertToBlob(). We also want to stick to the color space and pixel formats that are supported for canvas itself.
dictionary ImageEncodeOptions {
DOMString type = "image/png";
unrestricted double quality = 1.0;
CanvasColorSpace colorSpace = "srgb";
CanvasPixelFormat pixelFormat = "8-8-8-8";
};
USVString toDataURL(ImageEncodeOptions options);
Promise<Blob> toBlob(ImageEncodeOptions options);
Questions:
1. Do we need to ship a new version of toDataURL, considering blocking APIs are not favorite any more?
2. WDYT about migrating from callback based toBlob() to promise based?
3. Since the callback is not optional in the current toBlob(), we can make ImageEncodeOptions optional:
Promise<Blob> toBlob(optional ImageEncodeOptions options);
but then the API would not match toDataURL(). WDYT?
Summary: Support target color space and pixel format in toBlob() (was: Support target color space and pixel format in toBlob/toDataURL)
As discussed with junov@, we don't need to support color management in toDataURL(). Also, the signature of the new convertToBlob() will be as follows:
enum ImagePixelFormat {
"8-8-8-8", // default
"uint16",
};
dictionary ImageEncodeOptions {
DOMString type = "image/png";
unrestricted double quality = 1.0;
CanvasColorSpace colorSpace = "srgb";
ImagePixelFormat pixelFormat = "8-8-8-8";
};
Promise<Blob> convertToBlob(optional ImageEncodeOptions options);
yes, convertToBlob() is the future. The legacy APIs still need to behave correctly on color-managed canvases, but they don't need to provide color management options.
Summary: Implement HTMLCanvasElement::convertToBlob() (was: Support target color space and pixel format in toBlob())
After discussions with junov@, we decided to use a new enum for the image color space instead of the existing canvas color space, mostly since the wide gamut canvas color spaces use linear gamma but for the exported image we like to use the standard gamma transfer function of the used wide gamut color space.
Comment 1 by zakerinasab@chromium.org
, May 7 2018