STR #825: Strange colors are read from a 32-bit bitmap

STR #825

Application:	FLTK Library
Status:	1 - Closed w/Resolution
Priority:	2 - Low, e.g. a documentation error or undocumented side-effect
Scope:	3 - Applies to all machines and operating systems
Subsystem:	Image Support
Summary:	Strange colors are read from a 32-bit bitmap
Version:	1.1-current
Created By:	Natevw
Assigned To:	mike
Fix Version:	1.1-current (SVN: v4336)
Update Notification:	Receive EMails Don't Receive EMails

Trouble Report Files:

#1	Natevw 05:45 Apr 21, 2005

iewall2.bmp
150k

#2	Portale 06:38 Apr 21, 2005

iewall2_24bit.bmp
225k

#3	Portale 13:11 Apr 21, 2005

bmp_16_bit_565_fix.patch
2k

#4	Portale 09:44 Apr 22, 2005

rgb_ramps_24bit.bmp
46k

#5	Portale 09:44 Apr 22, 2005

rgb_ramps_16bit_555.bmp
30k

#6	Portale 09:45 Apr 22, 2005

rgb_ramps_16bit_565.bmp
30k

#7	Portale 11:14 Apr 22, 2005

bmp_16_bit_alignment_fix.patch
0k

#8	Portale 12:33 Apr 22, 2005

24bit_reverse_row_order.bmp
46k

#9	Portale 12:42 Apr 22, 2005

bmp_flipped_row_order_fix.patch
1k

#10	mike 08:20 May 12, 2005

str825.patch
3k

Trouble Report Comments:

#1	Natevw 05:45 Apr 21, 2005

The attached bitmap can be loaded, but the colors are not correct. thx, -nvw

#2	Portale 06:43 Apr 21, 2005

It looks as if your BMP is in reality 16 bit. The file size (320x240pixel * 2Bytes = 153600 Bytes) suggests it. Or maybe it has some kind of compression? The .bmp file which I posted has 24 bits (320x240pixel * 3Bytes = 230400 Bytes). This should work.

#3	Natevw 07:14 Apr 21, 2005

Hmm....I did notice strange file size comparisons when I saved it as a 24 bit using Windows Paint. Windows Explorer properties say it's 32 bit. Explorer couldn't possibly be wrong, could it! I can convert files in whatever flavor this is to a format FLTK can read, the problem is that the image libraries _do_ attempt to read it, but then proceed to read it incorrectly. thanks, -nate

#4	Portale 10:43 Apr 21, 2005

The Windows Explorer properties seem to be wrong. A test showed me that this .BMP file is 16 bit. There are two different ways of using the 16 bits for the RGB channels. One is 5:5:5, where each channel has 5 bits and one bit is wasted. This way of interpreting 16 bit .BMPs is the default in Fl_BMP_Image. The second variant is 5:6:5 where green has 6 bits. This is #deffed out via "USE_5_6_5". The image you posted has the 5:6:5 variant. Now, the question is: Is the information "5:5:5" or "5:6:5" for 16 bit images written in the .BMP header? If yes, the reading routine could switch dynamically.

#5	Portale 11:00 Apr 21, 2005

The in formation could be in the header. From the .BMP spec: "If the /Compression/ field of the bitmap file is set to /BI_BITFIELDS/, the /Palette/ field contains three dword color masks that specify the red, green, and blue components, respectively, of each pixel. Each word in the bitmap array represents a single pixel." and "When the /Compression/ field is set to /BI_BITFIELDS/, Windows 95 supports only the following 16bpp color masks: A 5-5-5 16-bit image, where the blue mask is 0x001F, the green mask is 0x03E0, and the red mask is 0x7C00; and a 5-6-5 16-bit image, where the blue mask is 0x001F, the green mask is 0x07E0, and the red mask is 0xF800." Does anyone habe a 5:5:5 16 bit bmp image somewhere, for testing?

#6	Portale 13:15 Apr 21, 2005

The patch proposal "bmp_16_bit_565_fix.patch" should make the "USE_5_6_5" preprocessor symbol obsolete.

#7	Portale 09:51 Apr 22, 2005

The color problem with the 16bpp .bmp types 555 and 565 is solved. But there seems to be another issue with 16bpp .bmp images whose width is not a multiple of 4 (or another padding).

#8	Portale 12:46 Apr 22, 2005

There is also an issue with .bmp images that have a flipped row order. Those images have a negative height and FLTK doesn't handle that. Example image: <http://www.fltk.org/strfiles/825/24bit_reverse_row_order.bmp> Patch proposal: <http://www.fltk.org/strfiles/825/bmp_flipped_row_order_fix.patch> I am not happy with the patch proposal, since in order not to add too many new variables and not to change too many things, introduces one line of spaghetti code (the grown "if" statement). For sure, it can be done in a smarter way.

#9	mike 08:20 May 12, 2005

Fixed in Subversion repository. I've attached the final, combined patch. Instead of the ? operator stuff, I added start and end variables to track things. Also, I changed bool to int (FLTK 1.1.x is not supposed to use bool, 2.0 will) and fixed the 32-bit alignment check at the end of your 16-bit code (&2 is incorrect).