GNOME Bugzilla – Bug 171306
BMP with RLE4 compression inserts a pixel at end of odd-lengthed runs in "absolute mode"
Last modified: 2005-03-24 22:42:37 UTC
Version details: 2.0.5 Distribution/Version: Fedora Core 2 How Reproducible: Always Steps to Reproduce 1) Execute "gimp 4bpp-rle-absolute-320x240.bmp" What Happens: The image shows up. It looks correct, except that there is a black vertical line about 256 pixels from the left and the black vertical line on the right border is missing. Expected Result: The image has three solid vertical bars, one red, one green, one blue. The words "TOP LEFT" appear in the upper left-hand corner. There is a single pixel black border around the entire image. Background: The bitmap format supports a compression scheme called BI_RLE4, which is a run-length encoding that uses 4 bits per pixel. This compression scheme supports two modes: encoded and absolute. Encoded mode is when you encode runs of the same pixel as a run-length/pixel value. Absolute mode is for runs with no duplicate pixels: you encode the length of the run, then put each pixel separately. In absolute mode, each byte represents two pixels (because there's only four bits per pixel in RLE4). When you have an odd number of pixels, the lower nibble of the last byte should be ignored. It looks like the GIMP is using it. The bitmap specification doesn't explicitly state that a renderer should ignore the low-nibble of the last byte in an odd-lengthed run that is encoded in absolute mode, but it implies it. MS Paint, the canonical bitmap renderer, seems to ignore it. 4bpp-rle-absolute-320x240.bmp comes from a bitmap test suite that I am putting together. It is not a typical RLE4 bitmap in that it encodes long runs of the same pixel in "absolute mode". I was unable to build the latest GIMP, so I could not verify that this bug is reproducible in 2.2.4. (I am using Gimp 2.0.5.) However, a cursory inspection of the latest plug-ins/bmp/bmpread.c makes me think that this bug will be reproducible on 2.2.4.
Created attachment 39108 [details] The image used in the repro scenario
Created attachment 39109 [details] Screenshot of the bug
The problem also shows up in GIMP 2.2/2.3 as well. David, since you seem to be knowing the BMP format rather well, I suspect that we can expect a patch that will fix the problem?!
Created attachment 39180 [details] [review] Proposed patch to fix the bug This is a proposed patch to fix the bug. It was created against the 2.2.4 tarball with the following command: diff -Naur gimp-2.2.4/plug-ins/bmp/bmpread.c \ gimp-2.2.4-bugfix/plug-ins/bmp/bmpread.c > gimp-bug171306.patch I would have preferred to created a patch against the CVS snapshot, but the instructions for anonymous CVS access don't say what the password is (this may be intentional). Here is a description of the patch that is appropriate for CVS: Fix bug #171306; now odd-length pixel encodings in "absolute mode" of RLE4 compressed data is handled correctly. (Before, it would insert a bogus pixel). Add some comments and restructure the RLE processing code a bit to make it easier to understand.
From http://www.gimp.org/source/howtos/stable-cvs-get.html : "Next, you have to log in to cvs with the command cvs login. There is no password for the anonymous login, so just press return."
Applied to the HEAD branch: 2005-03-24 Sven Neumann <sven@gimp.org> * plug-ins/bmp/bmpread.c: applied a patch from David Costanzo that fixes handling of odd-length pixel encodings in "absolute mode" of RLE4 compressed data (bug #171306). Before this is merged into the 2.2 branch, it would be nice if someone could run a couple of tests. David, perhaps we could use your BMP test suite for this purpose?
Sven, thanks for clearing up CVS access. I had misread the instructions and was trying to checkout the source from "cvs.gnome.org" with username "anonymous". I'd be honored if you used my test suite. I'm not done with it yet, but I guess it's better than nothing. Right now, it's either a 40 KB tarball of bitmaps or a 50 KB Python script that generates the bitmaps. Take your pick.
The generated files would be easier to handle probably. If you don't mind, please attach them to this bug report.
I've merged this change into the gimp-2-2 branch now. Of course testing would still be appreciated. 2005-03-24 Sven Neumann <sven@gimp.org> Merged from HEAD branch: * plug-ins/bmp/bmpread.c: applied a patch from David Costanzo that fixes handling of odd-length pixel encodings in "absolute mode" of RLE4 compressed data (bug #171306).
Created attachment 39224 [details] tar b'zipped directory of test bitmaps Here's what I have in my test suite so far. I b'zipped the tarball (instead of g'zipped) because there is a significant size savings (7.5 KB vs. 44 KB).