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. <div>
<div><br></div><div>Robby</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Nov 28, 2012 at 7:30 PM, John Clements <span dir="ltr"><<a href="mailto:clements@brinckerhoff.org" target="_blank">clements@brinckerhoff.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">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.<div>
<br></div><div>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.</div><div><br></div><div>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. </div>
<div><br></div><div>For instance, here's my test image:</div><div><br></div><div><img height="44" width="46" src="cid:92B0D8AA-6E2D-44F9-944C-39650EAB55BD@wireless.calpoly.edu"></div><div><br></div><div>Now, here's the alpha channel of the upper-left corner of this thing, blown up by 10x:</div>
<div><br></div><div><img height="121" width="241" src="cid:AB0C9AB6-5773-4F41-8D9E-22E465B12E8C@wireless.calpoly.edu"></div><div><br></div><div>Now, here's the alpha channel of the whole thing, blown up by 10x:</div><div>
<br></div><div><img height="431" width="451" src="cid:BA5912B5-E748-4B7C-B47C-AB1F98D1B639@wireless.calpoly.edu"></div><div><br></div><div>Note that I've warped the colors to show a very clear difference between alpha channel values of 0 and nonzero.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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. </div><div><br></div><div>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. </div>
<div><br></div><div>FWIW, the docs appear to suggest that 'get-argb-pixels' should produce the same thing as 'get-pixel', which AFAICT is not the case.</div><div><br></div><div>The code for this appears in this gist:</div>
<div><br></div><div><a href="https://gist.github.com/4166076" target="_blank">https://gist.github.com/4166076</a></div><div><br></div><div>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.</div>
<div><br></div><div>Anyhow: is it render-image or get-argb-pixels that changes depending on the width and height of the bitmap?</div><div><br></div><div>Thanks,</div><div><br></div><div>John</div><div><br></div></div><br>
____________________<br>
Racket Users list:<br>
<a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a><br>
<br></blockquote></div><br></div>