W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2008

[whatwg] More ImageData issues

From: Oliver Hunt <oliver@apple.com>
Date: Thu, 21 Feb 2008 19:51:07 -0800
Message-ID: <F97389E7-A3A8-40E2-B338-1FF6C9A32DD8@apple.com>
A couple of relatively minor issues, the first is fairly simple,
At the moment the spec merely states that  
putImageData(getImageData(sx,sy,..),sx,sy) should not result in any  
visible change to the canvas, however for those implementations that  
use a premultiplied buffer there is a necessary premultiplication  
stage during blitting that results in a loss of precision in some  
circumstances -- the most obvious being the case of alpha == 0, but  
many other cases exist, eg. (254, 254, 254, alpha < 255).  This loss  
of precision has no actual effect on the visible output, but does mean  
that in the following case:
imageData = context.getImageData(0,0,...);
imageData.data[0]=254;
imageData.data[1]=254;
imageData.data[2]=254;
imageData.data[3]=1;
context.putImageData(imageData,0,0);
imageData2.data = context.getImageData(0,0,...);

At this point implementations that use premultiplied buffers can't  
guarantee imageData.data[0] == imageData2.data[0]

Currently no UA can guarantee a roundtrip so i would suggest the spec  
be updated to state that implementations do not have to guarantee a  
roundtrip for any pixel where alpha < 255.

The other issue is the behaviour of NaN in ImageData.  Currently the  
spec states that attempting to assign NaN (or any value for which  
toNumber produces NaN) into the ImageData object should throw.  I feel  
that this is another place where NaN should be simply ignored, which  
is the behaviour given by Opera, which is the only UA that implements  
the ImageData API (that i'm aware of).

In Opera's implementation all non-finite numbers are stored as zero,  
which is (to my mind) much better than throwing an exception, however  
i would expect
NaN => 0
-Infinity => 0
Infinity => 255

So +/-Infinity would treated in line with standard clamping rules.

--Oliver
Received on Thursday, 21 February 2008 19:51:07 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:39 UTC