After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 711215 - EOG Doesn't Show Tall BMP v3 File
EOG Doesn't Show Tall BMP v3 File
Status: RESOLVED DUPLICATE of bug 709908
Product: eog
Classification: Core
Component: image viewer
3.4.x
Other Linux
: Normal normal
: ---
Assigned To: EOG Maintainers
EOG Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-10-31 14:56 UTC by Paul Hardy
Modified: 2013-11-06 17:38 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Paul Hardy 2013-10-31 14:56:58 UTC
When opening this monochrome Windows Bitmap Version 3 file in The Eye of GNOME Image Viewer version 3.4.2, it just appears black with no image displaying:

     http://unifoundry.com/gnu_unifont_long-6.3.20131020.bmp

The Image Viewer correctly shows that the file is 288 pixels wide by 65,584 pixels high. It correctly identifies the type as a "Windows BMP Image".

GIMP version 2.8.2 does display the above image properly.

Below is an output of the header contents of the file with my annotations added. The data was generated using "od -t x1" on an Intel CPU.


FILE HEADER
-----------
42 4d       = ASCII 'B' 'M' (standard BMP file beginning)
fe 06 24 00 = 0x002406FE = 2,361,086 bytes (file size in bytes)
00 00 00 00   Reserved
3e 00 00 00 = 0x0000003E = 62 bytes (offset in file to bitmap data)


BITMAP HEADER (BMP Version 3)
-------------
28 00 00 00 = 0x00000028 = 40 bytes (size of this header in bytes)
20 01 00 00 = 0x00000120 = 288 pixels (image width in pixels)
30 00 01 00 = 0x00010030 = 65,584 pixels (image height in pixels)
01 00       = 0x0001     = 1 color plane
01 00       = 0x0001     = 1 bit per pixel
00 00 00 00 = 0x00000000 = 0 (compression type: uncompressed)
c0 06 24 00 = 0x002406C0 = 2,361,024 bytes (size of bitmap in bytes)
                           [this is file size - header size = 2,361,086 - 62]
c4 0e 00 00 = 0x00000EC4 = 3,780 pixels/meter (horizontal resolution) = 96 dpi
c4 0e 00 00 = 0x00000EC4 = 3,780 pixels/meter (vertical resolution) = 96 dpi
02 00 00 00 = 0x00000002 = 2 colors in the image
02 00 00 00 = 0x00000002 = 2 minimum important colors


COLOR PALETTE
-------------
00 00 00 00 = Blue:   0; Green:   0; Red:   0; Padding: 0 (first color: black)
ff ff ff 00 = Blue: 255; Green: 255; Red: 255; Padding: 0 (second color: white)


IMAGE BITMAP - remaining output of "od -t x1" showing octal addresses on left
------------
0000076 00 00
0000100 00 01 ff ff ff ff ff ff ff ff ff ff ff ff ff ff
.
.
.
11002560 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
*
11003360 ff ff ff ff ff ff ff ff ff ff ff ff ff ff
11003376


File Size  = octal 11003376 = 0x002406FE = decimal 2,361,086 [same as "ls -l"]

Headers    = 0x3E = decimal 62 = octal 76

Image Size = File Size - Headers = octal 11003376 - 76
           = octal 11003300
           = 0x002406C0 [which agrees with what is in the header]
           = decimal 2,361,024


So the values that appear in the file header check with the actual file size and bitmap image size.


POSSIBLE SOLUTION HINTS:

Here is a handy web page that describes the different versions of Windows Bitmap file formats:

     http://www.fileformat.info/format/bmp/egff.htm

The format of the file in question is "BMP Version 3 (Microsoft Windows 3.x)".

The above web page also has a handy section titled "Windows BMP File Types" that lays out an algorithm for determining which version of BMP a given BMP file is.

The Eye of GNOME Image Viewer does display smaller BMP version 3 files, for example

     http://unifoundry.com/bmp/uni00.bmp


Thank you,


Paul Hardy
Comment 1 Paul Hardy 2013-11-02 04:20:39 UTC
I should also specifically mention that this is a monochrome image, so each pixel takes one bit.  Therefore the total number of pixels is the total number of image bits, which is 288 * 65,584 = 18,888,192 bits.  At 8 bits/byte, this is 18,888,192 / 8 = 2,361,024 bytes, which agrees with what is specified in the header information.


Paul Hardy
Comment 2 Felix Riemann 2013-11-06 17:38:04 UTC
Awesome format analysis Paul. :)

Unfortunately, this is the same problem as bug 709908.
There is currently a size limitation of 32k pixels in any direction imposed on eog by libcairo.
---
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find.

*** This bug has been marked as a duplicate of bug 709908 ***