Date: Mon, 09 Apr 2001 10:05:45 +0100 Newsgroups: borland.public.delphi.graphics Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Newsreader: Virtual Access by Atlantic Coast PLC, http://www.atlantic-coast.com/va Organization: Woozle Software Message-ID: Subject: Re: Delphi TBitmap problems From: Colin Wilson Reply-To: colin@wilsonc.demon.co.uk References: <3ace2d39_2@dnews> NNTP-Posting-Host: 194.222.91.69 X-Trace: dnews 986807151 194.222.91.69 (9 Apr 2001 02:05:51 -0700) Lines: 53 Path: dnews Xref: dnews borland.public.delphi.graphics:37124 In article <3ace2d39_2@dnews>, Gavin Foster wrote: > When saving bitmaps as 16 bit and 15 bit, the headers are the same, they > both report the number of bits per pixel as 16 bits although the content of > the bitmap image is different. Is this a bug in the bitmap component? > > Also, when saving in 16 and 15 bit formats, the bitmap compression field in > the header is set to 3 although the bitmap data is not compressed. In > addition, in 15/16 bit format, there is a 12 byte gap in between the header > and the start of the bitmap, whereas in 24 bit mode there is no gap. Here's how it meant to works in graphics.pas... 1. When it loads a '16-bit uncompressed' bitmap, it calls it pf15Bit. That's fair enough - an RGB 16 bit bitmap uses 5 bits for red, 5 for blue and 5 for green. The other bit is unused. 2. When it loads a RLE compressed 16-bit bitmap that has 5 bits for red, 6 bits for green and 5 bits for blue, it calls it pf16Bit. 3. Any other RLE or other compressed 16-bit bitmap it calls pfCustom. 4. If you create a pf16Bit bitmap and save it, when you load it again it will still be a 'pf16Bit' bitmap. That all workds OK. 5. If you create a pf15Bit bitmap and save it, when you load it again it will probably be pfCustom (!). Here's why: * In CopyBitmap in graphics.pas, it calls CreateDIBSection (specifying the correct pixel format, compression, etc). It then fills in the bits in the newly created DIB section from the old bitmap with GetDIBits. * Finally it throws away everything it knows about the bitmap, except the handle that was returned in CreateDIBSection, and gets it all again with a call to GetObject. It has to do this to guarantee that the data it's got on the bitmap matches the handle. And this data returned is in an incorrect format! Even if you specify BI_RGB in a call to CreateDIBSection, it can return a DIB with BI_BITFIELDS compression, for 16 (and 32 bit) bitmaps (!!!) Whether this is a bug in Windows, or it's working as designed is debatable. MSDN is ambigous about it. It seems to deliberatly skate round the issue with weasel words! But the upshot is that the call to CreateDIBSection specifying BI_RGB compression (at least on my NT 4 box with a Matrox Mystique card) returns a 16 bit bitmap with BI_BITFIELDS compression, and the bitfields specifying 5 bits for red, 5 for green and 5 for blue. And loading this bitmap gives pfCustom (see 2 and 3 above). Colin e-mail :colin@wilsonc.demon.co.uk web: http://www.wilsonc.demon.co.uk/delphi.htm