Re: Image.toBlob()

On 2/2/12 8:14 PM, Glenn Maynard wrote:
> (You're blue today.)
I can't stop myself from responding on my mobile phone. Bad habit :-).

>
> On Thu, Feb 2, 2012 at 4:34 PM, Charles Pritchard <chuck@jumis.com 
> <mailto:chuck@jumis.com>> wrote:
>
>     They are a pain, and lossy.
>
>     You don't want to do drawImage then a toBlob png on an image
>     that's a jpeg. We've had to use followup XHR calls which may or
>     may not do another http fetch. We went the route of doing an XHR
>     call first, but then we couldn't display nice progressive loading.
>     Canvas also inflates the size of PNG files, typically.
>
>
> Not if the browser optimizes for this and avoids the copy entirely 
> (eg. as long as you do a 1:1 copy, don't draw anything else on top of 
> it, etc).  That seems like a useful optimization anyway.

It's a pretty extreme optimization. I get what you're saying. You could, 
in theory, make one optimization
onDrawImage
if(cleanCanvas && x == 0 && y == 0 && width = canvas.width && height == 
canvas.height) referenceImageBuffer;

There's nothing like it in current implementations. I'd think it rare to 
come across an instance where an author has only made a clone image, and 
done nothing else. They'd just use the <img> element in such a case.

> I'm not sure if alpha complicates this.  If you save a transparent PNG 
> back to a PNG, you want the original RGBA, not premultiplied and 
> un-premultiplied results.  I don't know if the spec allows bypassing 
> those lossy steps in this case.  I don't think 2d canvas specifies the 
> color depth of the backbuffer.  If you think of the backbuffer as 
> having a high color depth, you'd get the same result.  That doesn't 
> work for alpha values of zero, though, where the result would be 
> undefined (and is defined as black) rather than the original color.
>
> It's worth trying to make this work before adding new API.

We're talking about jpeg, as well as PNG, and items like WebM. Canvas is 
specified as RGBA. What happens when an indexed or an RGB PNG file is 
put in? You're taking some real liberties with the scheme I mentioned 
above, and there seems to be very few use cases for it.

With that scheme, though, if you were really referencing an image, then 
your toDataURL and toBlob output, given no optional parameters were 
specified, and the file format were the same, well it could be a copy of 
the binary data.

I think that's where perhaps we're at a bit of a disconnect. My concern 
is getting a copy of the binary data of an image, not getting a copy of 
the display pixels. I was hoping Image.toBlob would handle that. There's 
all sorts of yummy information in that binary data. And I dislike the 
extra XHR calls it requires to fish out.

-Charles