[whatwg] toDataURL() for image/video?
chuck at jumis.com
Fri Jun 15 19:42:26 PDT 2012
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
>> 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
>> 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.
>> 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
> 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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg