Add alpha channel to BMP with RLE to allow setting transparency to skipped pixels

[telecos]

This change is adding alpha channel to RLE encoded images so that skipped pixels (by Delta, EndOfRow or EndOfFile commands) are set to transparent color, rather than opaque black. This change affects expected pixel output for pal4rlecut.bmp and pal4rletrns.bmp.

This change is part of #2747

However, I have done some investigation and based on this page: https://entropymine.com/jason/bmpsuite/bmpsuite/html/bmpsuite.html

These files which are skipping pixels with different RLE commands have multiple expected results, so both current result from BmpDecoder (which mimics Windows and old IE browser) and the proposed change on this PR (matching Chromium) seem correct. For example, in pal4rlecut.bmp:

Chromium (image on right) is displaying as 1st option on left, while our reference in BmpDecoder matches the 3rd

For additional info, I also checked Firefox and it is also showing as transparent, which can be checked also in a specific comment from their BMP decoder:

// Note that RLE-encoded BMPs might be transparent because the 'delta' mode
// can skip pixels and cause implicit transparency.

https://searchfox.org/firefox-main/source/image/decoders/nsBMPDecoder.cpp#688

Being both valid, I don't have strong opinion on adding this change by default (more on the opposite). Maybe adding a function to control externally from the consumer if RLE should be treated as RGB or RGBA?

[anforowicz]

These files which are skipping pixels with different RLE commands have multiple expected results, so both current result from BmpDecoder (which mimics Windows and old IE browser) and the proposed change on this PR (matching Chromium) seem correct. For example, in pal4rlecut.bmp:

...

For additional info, I also checked Firefox and it is also showing as transparent.

Thank you for the explanation. For completeness, we could check which reference result (left) is actually displayed (right) for pal4rlecut Safari when visiting https://entropymine.com/jason/bmpsuite/bmpsuite/html/bmpsuite.html (unfortunately I don't have a Mac or iPhone readily available...).

I think matching the current behavior of web browser (at least Firefox and Chromium) makes sense, but I don't have a strong opinion.

[telecos]

These files which are skipping pixels with different RLE commands have multiple expected results, so both current result from BmpDecoder (which mimics Windows and old IE browser) and the proposed change on this PR (matching Chromium) seem correct. For example, in pal4rlecut.bmp:
...
For additional info, I also checked Firefox and it is also showing as transparent.

Thank you for the explanation. For completeness, we could check which reference result (left) is actually displayed (right) for pal4rlecut Safari when visiting https://entropymine.com/jason/bmpsuite/bmpsuite/html/bmpsuite.html (unfortunately I don't have a Mac or iPhone readily available...).

I think matching the current behavior of web browser (at least Firefox and Chromium) makes sense, but I don't have a strong opinion.

I have just tested on Safari and found that it is showing the 2nd option (so not like Chromium nor like image crate)

[anforowicz]

I have just tested on Safari and found that it is showing the 2nd option (so not like Chromium nor like image crate)

Ack. I think this means that web compatibility is not a strong argument for landing this PR (although it would align the behavior with Firefox and with the legacy decoder in Chromium). One option that is still on the table is updating the "golden" / expected images in Chromium tests (although ultimately I defer to the Skia folks on that decision).

I don't have a strong opinion on whether to pursue this PR, vs update the test expectations. Sorry for not being more decisive here.

[telecos]

For completeness, sharing how chromium renders when enabling rust bmp decoder from image crate in its current status: