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

I think the first step to understanding this is to operate at the dc%
level. That is, make a little program that draws (simpler) shapes, cropped
and uncropped, via calls directly to the dc object and see if you can find
a minimalist program. Well, that's how I tackle these problems, generally.

Robby


On Wed, Nov 28, 2012 at 7:30 PM, John Clements <clements at brinckerhoff.org>wrote:

> 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
>
>
> ____________________
>   Racket Users list:
>   http://lists.racket-lang.org/users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20121128/194f2e62/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 1253 bytes
Desc: not available
URL: <http://lists.racket-lang.org/users/archive/attachments/20121128/194f2e62/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 4181 bytes
Desc: not available
URL: <http://lists.racket-lang.org/users/archive/attachments/20121128/194f2e62/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 862 bytes
Desc: not available
URL: <http://lists.racket-lang.org/users/archive/attachments/20121128/194f2e62/attachment-0005.png>