GNOME Bugzilla – Bug 742689
eog displaces BMP file
Last modified: 2018-05-22 13:17:54 UTC
Created attachment 294208 [details] BMP file - created by ImageMagick if I recall correctly The attached BMP file is not properly displayed by eog. I have just noticed shotwell is broken as well. Gimp and ImageMagick display the BMP file properly - therefore the bug might be in some Gnome library. Steps to Reproduce: 1. Download the attached file myoung.bmp. 2. Display it in eog. Notice how the image is shifted.
Created attachment 294209 [details] screenshot of eog shifting the BMP file
Created attachment 294210 [details] screenshot of ImageMagick properly displaying the BMP file
Yes, this appears to be a bug in gdk-pixbuf reading the BMP file.
I had a look at the file and it is a 16bpp-BMP which employs the RGB565 encoding. The offset seems to be caused by 14 padding bytes (offset 0x42 - 0x4f) between the three bitfield masks and the actual image data. The BMP loader however seems to assume that the image data begins directly after the bitfield masks and thus interpretes the padding as the first 8 px of the last scanline. It ignores the offset field from the bitmap header which correctly specifies that the image data begins at offset 0x50. Removing these padding bytes and adjusting the offset field in the header makes the file universally show correct for me (eog, gimp, ImageMagick).
Likely a dupe of bug 700952.
Created attachment 342620 [details] [review] tests: Add test for bug 742689
I don't understand the state machine in BMP loader, but the problem is that BufferPadding is not handled in the "State->Compressed == BI_BITFIELDS" case in DecodeHeader().
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gdk-pixbuf/issues/49.