GNOME Bugzilla – Bug 150664
Update regions for bmp are wrong?
Last modified: 2010-07-10 04:08:40 UTC
It looks on quick inspection that the region passed to the update function in io-bmp.c:DoCompressed is wrong ... it doesn't seem to take into the account the fact that BMP data is upsidedown. When fixing that, it's important to pay attention to the fact that compr.y may be off the top of the image and clamp that value ... the sanitization of the values inside the gdk-pixbuf core is minimal.
compressed upsidedown bmps are not actually allowed, according to the information I've seen. 2005-01-04 Matthias Clasen <mclasen@redhat.com> * io-bmp.c (DecodeHeader): Error on compressed images with negative height. Also make uncompressed images with data_offset != header_size work. (#150664, Owen Taylor)
I thought BMP data was start-at-bottom by default?
Hmm, the only compressed bmp I have at hand to check is symmetric wrt to the height/2 axis, so it is hard to tell :-)
I am in the process of creating a test suite of bitmaps, so I've got a bunch of RLE bitmaps images that have a very obvious "up". I can upload them, if desired (the entire suite is under 50K when b'zipped). Owen is correct, all bitmaps are bottom-up by default. Only BI_BITFIELD and BI_RGB bitmaps may have a negative height, which says that the bitmap should go top-down.
David, if you would provide that testsuite (ideally together with png versions to check correctness), that would be nice.
I reported a bug in GQView which the author has tracked down to this bug. This bug report is in GQView's bug database: https://sourceforge.net/tracker/?func=detail&atid=104050&aid=1166688&group_id=4050 Basically, the top half of all RLE bitmaps are not drawn. This is only a problem in progressive rendering, when the file is being rendering as it is being read from a file. The effects on TGA images are worse. They are not drawn at all and the "area update signal" sometimes falls outside the drawable area. Should I file a separate bug on this? Since this bug report does not have a repro scenario, I'll include one here. Steps to Reproduce: 1) Compile the pixbuf-tester.c sample application (see attachment) 2) Run "pixbuf-tester rle8-encoded-320x240.bmp" What Happens: The bitmap is drawn bottom-up in the progressive window. The "area signals" fill in from the top-down. Expected Result: The progressive window and the "area signals" are both drawn bottom-up. Does this happen every time? Yes
Created attachment 39310 [details] pixbuf-tester.c -- a code sample that demonstrates the bug Compile instructions are in the comment at the top of the file. DISCLAIMER: This code was given to me by the author of GQView. I don't know what it does. (I'm not a GTK+ hacker).
Created attachment 39311 [details] rle8-encoded-320x240.bmp -- An RLE8 bitmap that demonstrates the bug The image is rendered correctly. The area update signals are incorrect.
Created attachment 39312 [details] bmptestsuite-0.6.tar.bz2 -- test suite of bitmaps Matthias, here is the test suite that I mentioned. I haven't put together the control .PNGs yet (or even a text description of what the images should look like), but all bitmaps look about the same and they all render correctly in gThumb. The filenames are also relatively descriptive. I'm trying to get some space on SourceForge to host this test suite, so I want to make it so useful/complete as possible. I'd appreciate and feedback on the test suite (especially critisism).
Thanks for the test images 2005-03-27 Matthias Clasen <mclasen@redhat.com> * io-bmp.c (DoCompressed): Use the correct update regions for compressed bmps. (#150664, Owen Taylor, test images provided by David Costanzo)
David, I forgot. Can you please file a separate bug about the tga loader ?