[whatwg] toDataURL() for image/video?

[Ian Hickson]

On Tue, 29 May 2012, Ashley Gullen wrote:
> 
> Has toDataURL() (from canvas) been considered for ordinary image and 
> video elements?  Seems like it would be useful for pure javascript 
> applications. Currently it can be done by creating a new canvas, getting 
> a 2D context, drawImage(), then canvas.toDataURL().  However adding it 
> to images directly would be a useful convenience method, avoid the 
> performance overhead of a new canvas, and probably be straightforward to 
> define/implement.
> 
> Use cases for myimage.toDataURL():
> - deep copy an image (imga.src = imgb.toDataURL())

Why can't you do imga.src = imgb.src?

> - send an image in JSON data

Why can't you just send the URL?

If you really can't, then you can still just fetch the image data using 
XHR, and then send the blob directly, which seems more efficient than 
requiring the UA to decode the image then reencode it as a PNG.


> - conveniently store in webstorage/other permanent storage (possibly 
> also for caching purposes?)

You can store blobs into IndexDB directly.


> - downloading an image to disk (depending on other features like 
> anchor's download attribute)

Browsers offer this feature already.


> These are especially useful with javascript-synthesised images.  I 
> suppose it would have to be disallowed for cross-domain images, else 
> canvas' dirty flag can be worked around by deep copying a cross-domain 
> image.

If it's a JS-synthesised image, just synthesise it straight to canvas and 
use that instead.


> It seems to make sense to also consider it for video, but it may be 
> difficult to deal with streaming or strings storing very large amounts 
> of data.  How about a snapshot() method that returns a new Image() with 
> the contents of the currently displaying frame?  This can also be worked 
> around by drawImage() to a temporary canvas, so exists just as a 
> convenience method as well.

I think if we want to support doing things to frames of videos, we should 
approach the problem in much the same way as we do for audio, with a 
dedicated off-the-main-thread processing pipeline.


> Use cases:
> - easily get a representative frame, e.g. for a thumbnail
> - easily snapshot the current frame when displaying webcam feed with
> getUserMedia().  e.g. var myPhoto = video.snapshot();, or some of the above
> uses with video.snapshot().toDataURL().

On Tue, 29 May 2012, Glenn Maynard wrote:
> 
> It doesn't need any overhead, actually.  You can create a single canvas 
> for all of your readback operations.  As long as you keep the canvas out 
> of the document, it doesn't even need to actually blit the image; a 
> smart implementation can delay that, so when you read the data back it 
> can get the pixel data directly from the original image.  This is more 
> important with toBlob, where implementations might be able to skip the 
> compression step and just return the original compressed data.
> 
> (These are use cases for reading back images--they're not really use 
> cases for adding another way to do it.)

Indeed. It's not clear that adding this new feature has a compelling need.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'