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 <cleme...@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 > >
<<foo.png>>
<<star-alpha.png>>
<<ulcorner.png>>
____________________ Racket Users list: http://lists.racket-lang.org/users
