Good point - it makes sense to have ImageBitmap as the "hub" of all conversion.
I've drafted a new spec which instead proposes ImageBitmap.toBlob() and ImageBitmap.toImageData(): https://www.scirra.com/labs/specs/imagebitmap-conversion-extensions.html This should cover all conversion cases asynchronously. On 23 June 2015 at 20:34, Justin Novosad <ju...@google.com> wrote: > Based on feedback received from web developers, new APIs that move image > data around should also strive to eliminate intermediate copies of the > image data to avoid memory bloat. I think your proposal achieves that, but > I think memory footprint reduction could be a stated objective of the > proposal. For example, the current solution of using a canvas forces the > creation of an intermediate copy (the canvas). > > Also, to avoid the multiplication of APIs for moving image data between > various representations, I would like to suggest an alternative: using the > ImageBitmap interface as a hub. The creation of ImageBitmaps is already > asynchronous (createImageBitmap returns a promise), and it has overloads > for acquiring images from img, video, canvas, url, blob, imagedata. All > that is missing are a few methods for getting data directly out of an > ImageBitmap. So I think adding toBlob and toImageData (both async) to > ImageBitmap is a more succinct proposal that would address your use cases, > and many additional ones at the same time. >