[racket] problem with get-argb-pixels (or underlying drawing software)

From: John Clements (clements at brinckerhoff.org)
Date: Wed Nov 28 20:30:20 EST 2012

I'm seeing strange behavior in bitmap rendering... or maybe the problem is in get-argb-pixels; I don't seem to have the tools to observe the difference.

I'm hesitant to file a bug report, because this may simply be a consequence of built-in mac drawing routines.  At a minimum, though, there's a doc fix.

The problem is that rendering an image into a bitmap and then using get-argb-pixels produces results that depend on the width and height of the bounding box of the given bitmap. 

For instance, here's my test image:



Now, here's the alpha channel of the upper-left corner of this thing, blown up by 10x:



Now, here's the alpha channel of the whole thing, blown up by 10x:



Note that I've warped the colors to show a very clear difference between alpha channel values of 0 and nonzero.

If you take a close look at certain pixels---(14,5), for instance--you'll see that the alpha value is different. To be more visual: consider the top two spikes. Pick the left one. Now look at the number of pixels in its leftmost column, at the top. In the cropped image, that column contains six nonzero values. In the other one, it contains five nonzero values. This difference occurs despite the fact that the images are being rendered with the same top left corner.

Looking at the alpha values produced for these pixels shows a difference: in the top image it's 1/255, in the bottom one it's 0/255. 

This could be a problem with get-argb-pixels, or with render-image.  I couldn't tell which it was, because attempting to use get-pixel directly on the dc% in which the rendering was happening produced strange values; the alpha was always either 1.0 or 0.0. 

FWIW, the docs appear to suggest that 'get-argb-pixels' should produce the same thing as 'get-pixel', which AFAICT is not the case.

The code for this appears in this gist:

https://gist.github.com/4166076

There's definitely a workaround; if I call "freeze" on the images first, then all is well and I get the same values for the cropped image that I do for the un-cropped one.

Anyhow: is it render-image or get-argb-pixels that changes depending on the width and height of the bitmap?

Thanks,

John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20121128/63c5c617/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: foo.png
Type: image/png
Size: 1253 bytes
Desc: not available
URL: <http://lists.racket-lang.org/users/archive/attachments/20121128/63c5c617/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ulcorner.png
Type: image/png
Size: 862 bytes
Desc: not available
URL: <http://lists.racket-lang.org/users/archive/attachments/20121128/63c5c617/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: star-alpha.png
Type: image/png
Size: 4181 bytes
Desc: not available
URL: <http://lists.racket-lang.org/users/archive/attachments/20121128/63c5c617/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4370 bytes
Desc: not available
URL: <http://lists.racket-lang.org/users/archive/attachments/20121128/63c5c617/attachment.p7s>

Posted on the users mailing list.