The Problem:
When the exact same bitmap is displayed with the exact same Delphi
program, the resultant image is different when run under Windows NT
versus Windows 95, with displays of similar capability.
The Scene:
Machine A: 200 MHz Pentium, 96 meg memory, VGA display at 1024 x 768 x
16 bpp or 800 x 600 x 24 bpp (results identical at either setting),
Windows NT 4.0, service pack 1.
Machine B: 120 MHz Pentium, 16 meg memory, VGA display at 640 x 480 x
16 bpp or 640 x 480 x 24 bpp (results identical at either setting), Win
95 a.
The Action:
A bitmap which is 1200 x 900 x 8 bpp (256 colors) is loaded into a
TBitmap. A second bitmap is created, its pixel format is set to one of
either 8 bpp or 24 bpp. A CopyRect then squashes the input bitmap into
the output bitmap at 1/2 the width and height (600 x 450). Finally, the
second bitmap is Assigned to a Timage for display.
var
InBmp, OutBmp : TBitmap;
begin
InBmp := TBitmap.Create;
OutBmp := TBitmap.Create;
InBmp.LoadFromFile(BitmapFile);
InBmp.PixelFormat := pfXXbit; // see below - only changed sometimes
- either pf8bit or pf24 bit
OutBmp.PixelFormat := pfXXbit; // either pf8bit or pf24 bit
OutBmp.Width := 600; // InBmp.Width div 2;
OutBmp.Height := 450; // InBmp.Height div 2;
OutBmp.Canvas.CopyRect(Rect(0,0,600,450), InBmp.Canvas,
Rect(0,0,1200,900));
Form1.Image1.Picture.Assign(OutBmp);
InBmp.Free;
OutBmp.Free;
end;
The Results:
I get different results (ie, bitmaps look different) when I run the
above code on Windows 95 versus Windows NT, when I use different
PixelFormat settings, as noted below.
Run 1 - Do not touch the PixelFormat settings on either InBmp or OutBmp,
just do the load, CopyRect, and Assign.
Win 95 - One ugly ass picture, incorrect color rendition, smeared fonts
and lines.
Win NT - a good compression of the map, although the text is very
'heavy' for the new image size, a 24 bit StretchDIBits, I'd guess.
Run 2 - Change the OutBmp PixelFormat to pf24bit but do not touch the
the input PixelFormat
Win 95 - Still ugly as hammered sh*t, same as Run 1
Win NT - good image, same as Run 1
Run 3 - Change the OutBmp PixelFormat to pf8bit but do not touch the the
input PixelFormat
Win 95 - a good compressed image appears, lighter looking type, an 8 bit
StretchDIBits, I'd guess.
Win NT - now this image is one ugly picture, incorrect color rendition,
smeared fonts and lines.
Run 4 - Change the OutBmp PixelFormat to pf24bit, and change the InBmp
PixelFormat to pf24bit after the image has been loaded. Note: This
causes a new bitmap to be created in memory by the SetPixelFormat
procedure.
Win 95 - a good looking compressed image appears, heavier type, a 24 bit
StretchDIBits, I'd guess.
Win NT - Hey, the same good looking image, an apparent 24 bit
StretchDIBits
Etcetera:
It appears that there is no way I get to do an 8 bit to 8 bit
StretchDIBits under Windows NT (see Run 3).
This is an unhappy set of affairs. I've got 8 bpp bitmaps to reduce
size, and this goes for memory as well. Switching to a 24 bpp on the
input gobbles lots more memory, not to mention the fact that it is
slower.
A workaround I am looking into is to identify the oepratiing system via
an API call, then set the output PixelFormat appropraitely to get the
image I want.
As a final note, the results turn out exactly the same if one dispenses
with the OutBmp and instead applies the PixelFormat changes directly to
the bitmap contained in the TImage.
Thoughts on the process and possible workarounds would be appreciated.
Anyone who would like the source and the bitmap to try this on your own
machine, I'll be happy to email the poop.
--
Wayne Herbert
Manager, Computer Products
Key Maps, Inc.
1411 West Alabama
Houston, TX 77006
Vox: 713.522.7949
Fax: 713.521.3202
Email: wherb...@rice.edu
"Why is it only drug dealers and software developers call their clients
'users'?"
