W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2009

[whatwg] getImageData/putImageData comments

From: Ian Hickson <ian@hixie.ch>
Date: Sat, 11 Jul 2009 00:35:48 +0000 (UTC)
Message-ID: <Pine.LNX.4.62.0907110034050.9397@hixie.dreamhostps.com>
On Fri, 10 Jul 2009, Boris Zbarsky wrote:
> Ian Hickson wrote:
> > > For another example, consider an algorithm that wants to reduce the 
> > > size of the image by 1px horizontally (e.g. content-aware image 
> > > resizing as demoed using canvas at 
> > > <http://labs.pimsworld.org/wp-content/uploads/2009/04/demo-content-aware-image-resizing-2/>). 
> > > If we're shrinking by one device pixel, then suddenly we can't even 
> > > create a canvas of the right size for the new image, because canvas 
> > > size is specified in integer CSS pixels.  Note that the algorithm 
> > > used here, basically off-the-shelf, would in fact want to work on 
> > > device pixels the way the spec is written right now; in general it 
> > > would want to work on whatever pixels imagedata is in.
> > 
> > If you want to shrink an image, redraw it using drawImage() with 
> > different dimensions.
> 
> You apparently didn't look at the linked-to page.  It's basically 
> applying a graphical filter to an image that results in a smaller image.  
> It's explicitly NOT trying to resize the image using whatever algorithm 
> the browser happens to implement; it's implementing its own 
> image-resizing algorithm (one that arguably produces much better results 
> at the cost of a lot more computation).

Hm, neat.

I don't see why the imagedata API isn't suitable for that. It's not like 
if you're painting that on the canvas you'll want to leave the last row or 
column unaffected. You'll want to clear it or some such, in practice.

I think this use case works fine with the current API.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 10 July 2009 17:35:48 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:14 UTC