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 PR Add alpha channel to BMP with RLE to allow setting transparency to skipped pixels #2773
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 PR Allow lenient validation in BMP decoder #2764
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
8. V4 color space parameters are not exposed causing different pixel colors resulting in Chromium w.r.t. BmpDecoder. Affected test: pal8v4.bmp PR Support BMP V4/V5 color space fields #2771

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

[telecos]

Update on chromium side: Field trial will start during next days. The remaining discrepancies are documented on these tests comparing both decoders, expecting Pixel differences as result for the 5 cases affected by the 2 discrepancies covered in PR #2771 and PR #2773

https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/platform/image-decoders/bmp/bmp_image_decoder_test.cc;l=596

[197g]

Thanks for the update. I'm not sure how to do properly integrate the color treatment in image yet and unlike the previous exposed interfaces it doesn't generalize beyond bmp. Maybe that's the point to turn it into a crate proper; or to consider how to better treat those options in 1.0 since it seems wanted.

The question for image itself is if we want to externalize the color conversion or to internalize it. That is, should the caller be responsible (for now)–and we can't turn it into a correctly CICP-indicated ImageBuffer)–or should we have conversion routines. The latter is our current course and matches most other callers expectations but possibly (?) not requirements for Chromium.

A third alternative, unexplored in other formats, is constructing an ICC on the fly that correctly describes the V4/V5 color space fields. That would put the format-specifics behind a uniform interface but ICCv4 is not universal; so it may come down to a rather awkward LUT solution in the end.

[telecos]

A third alternative, unexplored in other formats, is constructing an ICC on the fly that correctly describes the V4/V5 color space fields. That would put the format-specifics behind a uniform interface but ICCv4 is not universal; so it may come down to a rather awkward LUT solution in the end.

I explored the alternative of creating an equivalent ICC profile, and it worked. I updated PR #2771 so now the support of the V4/V5 color parameters is done through the creation of an equivalent icc_profile that is exposed in the already existing icc_profile() function, avoiding thus the need to expose new bmp-specific public methods.