Summary: | canvas/philip/tests/2d.imageData.put.unchanged.html expects putImageData/getImageData to exactly preserve unpremul-alpha pixel values | ||
---|---|---|---|
Product: | WebKit | Reporter: | Brian Salomon <bsalomon> |
Component: | Tools / Tests | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED CONFIGURATION CHANGED | ||
Severity: | Normal | CC: | bfulgham, mdelaney7, noel.gordon, senorblanco |
Priority: | P2 | ||
Version: | 528+ (Nightly build) | ||
Hardware: | All | ||
OS: | All | ||
URL: | http://philip.html5.org/tests/canvas/suite/tests/2d.imageData.put.unchanged.html |
Description
Brian Salomon
2011-12-06 14:04:12 PST
Actually, I think the test link is referring to this statement: "The handling of pixel rounding when the specified coordinates do not exactly map to the device coordinate space is not defined by this specification, except that the following must result in no visible changes to the rendering # 2d.imageData.put.unchanged : context.putImageData(context.getImageData(x, y, w, h), p, q);" So although the mult/premult changes are lossy, in order to be spec-compliant, I think you have to be value-preserving over one roundtrip. (In reply to comment #1) > Actually, I think the test link is referring to this statement: > > "The handling of pixel rounding when the specified coordinates do not exactly map to the device coordinate space is not defined by this specification, except that the following must result in no visible changes to the rendering # 2d.imageData.put.unchanged : > > context.putImageData(context.getImageData(x, y, w, h), p, q);" > > So although the mult/premult changes are lossy, in order to be spec-compliant, I think you have to be value-preserving over one roundtrip. My take is that the rounding language refers to rounding coordinates to the pixel grid. The test seems to be exercising this by doing its get/put at coordinate (.1, .2) rather than (0, 0). Also it says "no visible change" not no change at all. The later language about premultiplying seems to indicate that a roundtrip may come back as "different values." (In reply to comment #2) > (In reply to comment #1) > > Actually, I think the test link is referring to this statement: > > > > "The handling of pixel rounding when the specified coordinates do not exactly map to the device coordinate space is not defined by this specification, except that the following must result in no visible changes to the rendering # 2d.imageData.put.unchanged : > > > > context.putImageData(context.getImageData(x, y, w, h), p, q);" > > > > So although the mult/premult changes are lossy, in order to be spec-compliant, I think you have to be value-preserving over one roundtrip. > > My take is that the rounding language refers to rounding coordinates to the pixel grid. The test seems to be exercising this by doing its get/put at coordinate (.1, .2) rather than (0, 0). Also it says "no visible change" not no change at all. The later language about premultiplying seems to indicate that a roundtrip may come back as "different values." Take a look at the entire paragraph that the sentence beginning with "The handling..." is part of: <quote> The handling of pixel rounding when the specified coordinates do not exactly map to the device coordinate space is not defined by this specification, except that the following must result in no visible changes to the rendering # 2d.imageData.put.unchanged : context.putImageData(context.getImageData(x, y, w, h), p, q); ...for any value of x, y, w, and h and where p is the smaller of x and the sum of x and w, and q is the smaller of y and the sum of y and h; and except that the following two calls: context.createImageData(w, h); context.getImageData(0, 0, w, h); ...must return ImageData objects with the same dimensions, for any value of w and h # 2d.imageData.create2.round . In other words, while user agents may round the arguments of these methods so that they map to device pixel boundaries, any rounding performed must be performed consistently for all of the createImageData(), getImageData() and putImageData() operations. </quote> The thrust seems to be that get, put, and create must all consistently round points and dimensions to device coordinates. Then it says: <quote> Note: Due to the lossy nature of converting to and from premultiplied alpha color values, pixels that have just been set using putImageData() might be returned to an equivalent getImageData() as different values. </quote> Perhaps file a W3C bug and ask Hixie for clarification. Failing that, what does Firefox do, or IE9/10? I believe they round-trip get/put just fine. Maybe run the round-trip test on those browsers to look at the web-compat story? I don't see why we should drop round-trip support. This test case appears to work properly (some 10+ years later!) |