BMP decoder feature parity with Chromium

[telecos]

In our integration with Chromium we have executed the test suites for BMP and compared current results from Chromium BMP decoder with the BMP decoder from image crate. We are creating this issue for tracking the gaps and reference it in following PRs that will try to close the gap whenever it makes sense.

After analyzing differences, we have spot these discrepancies:

1. OS/2 v2 palette format not supported - The decoder doesn't recognize OS/2 BITMAPINFOHEADER2 format (64-byte header with variable palette entry sizes of 3 or 4 bytes). Chromium supports this legacy format. Affected tests: pal8os2v2.bmp, pal8os2v2-16.bmp, pal8os2v2-sz.bmp PR Adds support for decoding BMP files using the OS/2 2v2 and OS/2-specific 24-bit RLE compression. #2770
2. RLE transparency handling - When RLE-encoded images have "delta" escapes or truncated data leaving unfilled pixels, Chromium treats these as transparent (alpha=0), while the Rust decoder leaves them as opaque black. Affected tests: pal4rlecut.bmp, pal4rletrns.bmp, pal8rletrns.bmp
3. Oversize palette validation - Chromium accepts BMPs where biClrUsed exceeds the maximum for the bit depth (e.g., 300 colors for 8-bit) by clamping to the valid range. The Rust decoder rejects these files entirely. Affected test: pal8oversizepal.bmp
4. Stricter Header validation - Chromium tolerates invalid header values like biPlanes != 1 or biClrUsed > 256 and proceeds with decoding. The Rust decoder returns an error. Affected tests: badplanes.bmp, badpalettesize.bmp PR Allow lenient validation in BMP decoder #2764
5. Truncated RGB16 data handling - For truncated 16-bit RGB files, Chromium decodes available rows and fills remaining pixels. The Rust decoder fails at metadata parsing. Affected test: rgb16-880.bmp PR Allow lenient validation in BMP decoder #2764
6. RLE top-down validation — Chromium accepts top-down RLE images (negative height) as valid, while the Rust decoder rejects them during header validation. Affected test: rletopdown.bmp PR Allow lenient validation in BMP decoder #2764
7. BI_ALPHABITFIELDS alpha mask not read - For BITMAPINFOHEADER with compression type BI_ALPHABITFIELDS (6), the alpha bitmask wasn't being read, causing transparent pixels to render as opaque. Affected test: rgba32abf.bmp PR Implement support for alphabitfields in BMP #2762

Reference Chromium CL: https://chromium-review.googlesource.com/c/chromium/src/+/7465861

BMP files can be found in: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/images/bmp-suite/

[Shnatsel]

Is BMP decoder being part of image as opposed to a standalone crate like image-png a problem?

Lots of format implementations have been bundled with the image for legacy reasons, but we've been splitting the more complex ones into their own crates. We didn't get around to doing this for BMP yet.

[telecos]

Yeah, I was analyzing the required changes for feature parity and some of them would require exposing additional attributes from the BMP headers. A separate crate would provide more flexibility for extending the public interface without impacting the main image crate's API stability.

From Chromium's perspective, there's no issue whether the functionality lives in image or in a dedicated crate like image-bmp.

The main question we have (also related to our limited experience publishing crates on crates.io) is whether the overhead of dealing with a separated crate represents significant effort for the image-rs project, or if it's straightforward. @197g what are your thoughts? If it sounds reasonable, what would be the next steps to start the separate crate?

[telecos]

I found this page which shows expected results for bmp images from the bmp suite mainly used in Chromium and also partly in image crate:

https://entropymine.com/jason/bmpsuite/bmpsuite/html/bmpsuite.html