Better image resize, crop, thumbnailing, etc with createImageBitmap()

Description

Major engines implement createImageBitmap(), but they differ in observable behaviour. I hope this is a good fit for Interop.

These differences affect applications and sites that resize photos before upload, apply EXIF orientation, crop images or sprites, process images in workers, capture video frames, or prepare data for graphics APIs.

The proposed scope covers:

• Supported ImageBitmapSource types.
• Cropping, negative dimensions, out-of-bounds pixels, and output dimensions.
• Resizing and the quality keywords inherit order, e.g. medium < high.
• imageOrientation: "from-image" and "flipY".
• colorSpaceConversion and premultiplyAlpha.
• Invalid input and promise settlement.
• Origin cleanliness, closing, serialization, and transfer.
• Window and Worker behaviour covered by WPT.

The scope excludes:

• Performance.
• Exact output for "low", "medium", and "high", since HTML does not require particular interpolation algorithms.
• imageOrientation: "none", which is not in the current HTML enum.

This proposal revisits the Interop 2025 proposal for createImageBitmap, which I also submitted. I've tried to narrow the scope and add details about tests and how they map to browser bugs, which was some of the feedback I got last year.

My think because of quality issues, it's been overlooked by developers. Manipulating images is applicable in many areas. I think usage would be higher if it just worked better and more consistently across browsers.

Hence this proposal!

Evaluator site and examples

I've published a mini-site (and code) for testing differences across browsers, as well as published my findings. The source + code is open, so easy to review.

Site:

https://sandstrom.github.io/create-image-bitmap-comparison/

Code:

https://github.com/sandstrom/create-image-bitmap-comparison/

Findings

These are with my test image, but the code works with any uploaded image.

• 'pixelated' and 'low' modes yields similar results across browsers
• With Chrome there is little difference between 'high' and 'medium'.
• WebKit's 'medium' result is near the reference while 'high' is worse.
• For edge, 'medium' also seems better than 'high'.

Specification

https://html.spec.whatwg.org/multipage/imagebitmap-and-animations.html#the-imagebitmap-interface

web-feature

createimagebitmap

Test Links

Results

https://wpt.fyi/results/html/canvas/element/manual/imagebitmap?label=master&label=experimental&aligned&q=createimagebitmap

Tests

https://github.com/web-platform-tests/wpt/tree/master/html/canvas/element/manual/imagebitmap

The dashboard contains 20 files and 314 subtests. Experimental runs pass 298
in Chrome, 299 in Edge, 291 in Firefox, and 259 in Safari.

Some related tests cover WebCodecs VideoFrame and wide-gamut canvas sources:

https://wpt.fyi/results/webcodecs?label=master&label=experimental&aligned&q=createImageBitmap

https://wpt.fyi/results/html/canvas/element/manual/wide-gamut-canvas?label=master&label=experimental&aligned&q=ImageBitmap

Someone more knowledgeable than me should decide if the the video source failures and the failure for SVG images without a natural size are relevant and should be in the test selection.

Test gaps

From what I can tell, there are coverage gaps include cropping combined with EXIF orientation, SVG Blob decoding, more Worker source and option combinations, preserving crops through VideoFrame, and stronger colour and alpha checks.

A somewhat elusive thing that's a bit special about this API, is image quality during e.g. resize. If the output isn't "good", developers cannot use it. Sadly, the spec itself doesn't mandate a particular algorithm, but maybe there are still things we can do to improve this area?

I understand that SSIM, SSIMULACRA2, or another perceptual metric may not be on the table.

But for example Chrome has had an issue where 'medium' yielded better results than 'high'. See my test site linked above.

If this isn't considered a great fit for the WPT suite, maybe just doing a shared investigation across the participating browsers against a fixed image corpus, and making sure it's somewhat aligned, i.e. that 'high' or 'medium' doesn't deviate too much across browsers.

Additional Signals

When I asked for feedback on my previous proposal, I was asked for better analysis of WPT coverage and more evidence of developer impact. So I've tried to beef up that section a bit.

Pica, a widely used browser image-resizing library, disables
createImageBitmap() resizing by default. Its documentation says that the
result depends on the browser and recommends its JavaScript and WebAssembly
path for predictable output:

https://github.com/nodeca/pica#new-picaconfig

Chromium issue 41313833 documents poor createImageBitmap() downscaling,
including cases where "medium" produced better results than "high". It has
59 comments and several reproductions:

https://issues.chromium.org/issues/41313833 (merged into https://issues.chromium.org/issues/40044062).

Firefox still has an open bug for the unimplemented resizeQuality option:

https://bugzilla.mozilla.org/show_bug.cgi?id=1363861

Other open reports include:

• Chromium: https://issues.chromium.org/issues/40773069
• Chromium: https://issues.chromium.org/issues/362431889
• Chromium: https://issues.chromium.org/issues/339759426
• Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1797567
• Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1880753
• WebKit: https://bugs.webkit.org/show_bug.cgi?id=202458
• WebKit: https://bugs.webkit.org/show_bug.cgi?id=237895
• WebKit: https://bugs.webkit.org/show_bug.cgi?id=288115

With better interoperability I think many developers would prefer this API over the more complicated and memory intensive approaches with Canvas or WebAssembly.

Thanks for reading and holding my fingers crossed for this year! 💯

Start by reviewing the WPT tests in html/canvas/element/manual/imagebitmap and the linked wpt.fyi results, then compare the listed coverage gaps with the createImageBitmap specification. The work is complete when the participating-browser scope and relevant tests are agreed, including whether the VideoFrame and SVG failures belong in the selection.