All major browser engines implement createImageBitmap() already, but they differ in observable behaviour. Given the focus is about interoperability, I hope this is a good fit for Interop.

These differences affect applications 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, including the specified resizeQuality: "pixelated" algorithm.
• 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.
• Bugs without suitable automated WPT coverage when tests are selected.

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

My subjective feeling around this API, is that because there has been quality issues around this API, more so when it was new, it's been overlooked by developers. Resize that turns images into junk isn't something anyone will use.

So even though this may not be the most popular API today (because it often doesn't work), if we just iron out these issues, I think it'll be very popular! :) Manipulating images is a core feature that's applicable in many areas. I think the usage would be much higher if it just worked better and more consistently across browsers.

Hence this proposal!