[whatwg] toDataURL() for image/video?

[Charles Pritchard]

On Jun 15, 2012, at 7:10 PM, Ian Hickson <ian at hixie.ch> wrote:

> 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.



It's a bit of extra work and won't be "compatible" with the img setsrc technique. I think this is just a rehash of having Image.toBlob() and video.frameToBlob() made available.






> 
> 
>> - 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.   `._.-(,_..'--(,_..'`-.;.'