<br><font size=2 face="sans-serif">Hi Rob, Bert, Jack:</font>
<br>
<br><font size=2 face="sans-serif">Form asGrayScale actually does extract the green component from 32 bit forms, or converts a lower depth Form to a 32 bit form and then extracts the green component. It is NOT however, a single BitBlt call. It does a copyBits for each column, and some fancy form/bitmap substituion to treat the 32 bit form as if it were an 8 bit form four times as wide. How would you accomplish this with only a "single BitBlt call"?</font>
<br>
<br><font size=2 face="sans-serif">Also, I timed my Form>>yComponent example against Form>>asGrayScale. Not surprisingly, Form>>asGrayScale is about 133 times faster. I may try optimizing mine using Form>>asGrayScale's trick of making a 32 bit form out of any form and then just extracting the RGB bits from the 32 bit pixelValues. That would eliminate all the Color object allocations (2 per pixel), which should speed it up a bit, but I don't know if I can get 133x from that. Ok... I tried it. It's only good for about a 5x speedup. Maybe I'll dabble with it more later, but it will probably need to be a primitive to get anywhere close to fast enough for video.</font>
<br>
<br><font size=2 face="sans-serif">Rob, just a caveat using Form>>asGrayScale - It is an approximation. I tried it using a workspace as the test bitmap, and the selected text didn't come out as selected because with default colors, selected text is black on a bright green and the background is bright white. This leads to what looks like no selected text in the grayscale version, where the "properly" calculated Form>>yComponent method does show the selected text as black on medium gray.</font>
<br>
<br><font size=2 face="sans-serif"> -Dean</font>
<br>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>Bert Freudenberg <bert@impara.de></b></font>
<br><font size=1 face="sans-serif">Sent by: squeak-dev-bounces@lists.squeakfoundation.org</font>
<p><font size=1 face="sans-serif">07/21/04 06:02 AM</font>
<br><font size=1 face="sans-serif">Please respond to The general-purpose Squeak developers list</font>
<br>
<td><font size=1 face="Arial"> </font>
<br><font size=1 face="sans-serif"> To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org></font>
<br><font size=1 face="sans-serif"> cc: </font>
<br><font size=1 face="sans-serif"> Subject: Re: Using video input in Squeak</font></table>
<br>
<br>
<br><font size=2 face="Courier New"><br>
Am 20.07.2004 um 20:53 schrieb Jack Johnson:<br>
<br>
> I can't help you with the implementation details, but I can tell you<br>
> that in order to generate B&W, most people will average the RGB to get<br>
> an 8-bit grayscale value. The overhead of this for a live video feed<br>
> can be noticeable, and you'll find that for most video systems if you<br>
> just take the values for green and compose a B&W image from it, the<br>
> contrast will be more what you would want or expect from B&W video.<br>
<br>
Yep, this can be very efficiently done in a single BitBlt call (mapping <br>
green component directly into black or white). See ColorMap>>mapPixel:, <br>
which is what the bitblt primitive does for each pixel when you set an <br>
instance of ColorMap as the bitblt's colorMap.<br>
<br>
- Bert -<br>
<br>
<br>
</font>
<br>
<br>