jsummers/bmpsuite

A set of Windows BMP image files, for testing purposes

bmpsuite's Issues

Offset to color profile incorrect?

I'm confused by bmpsuite subtracting 14 from the offset to the profile data. Why is this done?

As far as I can understand the specification ProfileData should simply be a plain offset, not modified.

Incorrect value in Intent field?

I'm confused by the value bmpsuite assigns to the Intent field in BitmapV5GHeader. It is set to 4 and the comment implies that this means Perceptual. Did you mixed up Intent with GamutMappingIntent where 4 means LCS_GM_IMAGES?

As I read the specification Intent must be set according to LogicalColorSpace for which the valid values are:

• 0x00000000 for LCS_CALIBRATED_RGB
• 0x73524742 for LCS_sRGB
• 0x57696E20 for LCS_WINDOWS_COLOR_SPACE

And since you are using sRGB Chromaticity values perhaps Intent is better set to LCS_sRGB?

Some suggestions

Hi,

1. Your two LINK + MBED examples are hard to judge. The LINK example might be broken; a relative or absolute path on your system, not working in a downloaded test suite.
2. The LINK + MBED examples should be obvious. There are nice public profiles swapping RGB ending up as BRG, together with something like the FFmpeg rgbtestsrc it should be obious if this works as expected. It didn't for me, maybe I got it wrong (trying your interpretation of the specification.) If you don't find this profile on the ICC site holler, I could send it in a mail, put it in Google docs, or similar (credits: Adobe).
3. The BMP page on Wikipedia mentions 5-5-5-1 (1 bit transparency) as Bibitfield case with a name. An example where it's obvious what tools actually do (ignore the bit or treat it as transparency) would be nice.
4. Likewise there are two named 10-10-10-2 RGBA variants, and no clear specification what 10 and 01 are supposed to do, 33% and 66% transparency would be plausible. That also deserves two or three examples.
5. I have not yet tested the mobile phone format number for RGBA (or rather ARGB, the alpha bits at the begin, but the alpha mask at the end). and you also skipped that.
6. With mspaint, Chrome, and XnView on my Windows 7 box I think the 56 bytes header is okay, you could remove the confirmation request for q/rgba32h56.bmp (but I dare not mention it on Wikipedia, the spec. does not really cover it.) OTOH the 52 bytes header is rather dubious, BiBitfields without alpha.

Now checking the new examples in version 2.4, thanks, also for imageworsener, its excellent docu, and tweakpng. If you get around it please check the color profile import/export in tweakpng, I think it's broken (no big issue, adding sRGB chunks works like a cHRm or CHRm or whatever ;-)

How are gamma & endpoints supposed to be handled?

Sorry for what follows, this is not really a bug, this is a cry for help.
Note that I knew nothing about colorimetry a few days ago, so I'm probably saying stupid things.

I started to write a BMP parser in Rust, just to play with nom: https://github.com/ColinPitrat/RustMisc/tree/master/bmp.
And I bumped into pal8v4.bmp which got me down a deep rabbit hole.

All the documentation I found says that the endpoints contain the XYZ coordinates of red, green & blue:
https://docs.microsoft.com/en-us/windows/win32/api/wingdi/ns-wingdi-ciexyztriple

And there are also the per-color gamma.

So my understanding is that, when handling a color, I should:

• normalize the color: [0, 255] -> [0.0, 1.0]
• apply the gamma to each coordinate: x -> x^gamma
• transform from the color in the endpoints to the color in XYZ: X = Xr * R + Xg * G + Xb * B (where Xr, Xg, Xb are the X components from R, G and B endpoints - and apply similar for other components)
• transform the XYZ color in sRGB to display properly because that's what my display expects (I suppose, as the other BMPs that say sRGB are displayed fine)

But when I do this, this gives me a weird result, way to red.
I tried removing/modifying gamma & endpoins in the file to see what it would give in other viewers. Most keep displaying the same thing (the "correct" display, although it's obviously not correct anymore as I messed with the colorimetry).

The exceptions are firefox & chrome. I therefore assume they support gamma & endpoints. But looking at firefox code:
https://dxr.mozilla.org/mozilla-central/source/image/decoders/nsBMPDecoder.cpp#906

It builds a xyY endpoint and assumes a white point that is not provided by the BMP. My understanding is that no white point should be needed with XYZ endpoints. I also found this post where the author explains that they use your image suite to code it: https://blog.mozilla.org/nnethercote/2015/11/06/i-rewrote-firefoxs-bmp-decoder/
There are also comments in the code suggesting there has been exchanges between chrome & firefox codes.

So at this point I'm starting to wonder:

• if the pal8v4.bmp example shouldn't be modified to NOT display correctly when a viewer is ignoring completely gamma and/or endpoints
• if this wouldn't deserve more than a single file to test this
• if there's a reference implementation (from microsoft?) that supports this to verify if pal8v4.bmp actually displays the way it's expected to in it?

For the record, the way I modified gamma & endpoints (although modifying bmpsuite code would actually be easier):

$ xxd pal8v4.bmp pal8v4.hex
$ vi pal8v4.hex
# Either 0 out, rotate or modify values
# Typically rotating the endpoints (put green values for red, blue values for green and red values for blue)
$ xxd -r pal8v4.hex pal8v4_mod.bmp

Firefox's rendering of pal4rlecut.bmp and pal8rlecut.bmp

Firefox's rendering of pal4rlecut.bmp and pal8rlecut.bmp doesn't exactly match any of the three options. The seem to match the first of their options, but with the black band across the top that can be seen in the third of their options.

Should Firefox's rendering be added as a fourth option to bmpsuite for these two images?

Please add BMP with 64bpp

BMP with 64bpp is now legal:
https://en.wikipedia.org/wiki/BMP_file_format

In the original OS/2 DIB, the only four legal values of color depth were 1, 4, 8, and 24 bits per pixel (bpp).[5] Contemporary DIB Headers allow pixel formats with 1, 2, 4, 8, 16, 24 and 32 bits per pixel (bpp).[19] GDI+ also permits 64 bits per pixel.[20]

Suggestion: Bad color palettes with too few bytes

(for context, g/pal4.bmp is a "Paletted image with 12 palette colors, and 4 bits/pixel.")

• g/pal4.bmp exactly but with biClrUsed set to 13, so the color palette is expected to contain 13 entries, but it actually only contains enough bytes for 12 entries
• g/pal4.bmp exactly but with biClrUsed set to 0, so the color palette is expected to contain 2^4 = 16 entries, but it actually only contains enough bytes for 12 entries

From what I've seen, both Windows and Firefox reject both of the above as invalid.

These would nicely complement q/pal8offs.bmp, which has more bytes in the palette than expected / extra bytes between the palette and the pixel data.

Missing standard 32bppBGRA BMP

I noticed Paint.NET cannot properly open transparent samples such as q\rgba32.bmp:

Paint.NET is using standard Windows Imaging Component (WIC) for BMP loading and saving. WIC is used by GDI+, WPF, .NET. The problem with mentioned q\rgba32.bmp is in channels order. I created a modified version of this image with BGRA order:

	defaultbmp(glctx, c);
	c->filename = "q/rgba32win.bmp";
	c->headersize = 124;
	c->bpp = 32;
	c->compression = BI_BITFIELDS;
	c->bf[I_R] = 0x00ff0000; c->nbits[I_R] = 8; c->bf_shift[I_R] = 16;
	c->bf[I_G] = 0x0000ff00; c->nbits[I_G] = 8; c->bf_shift[I_G] = 8;
	c->bf[I_B] = 0x000000ff; c->nbits[I_B] = 8; c->bf_shift[I_B] = 0;
	c->bf[I_A] = 0xff000000; c->nbits[I_A] = 8; c->bf_shift[I_A] = 24;
	c->pal_entries = 0;
	set_calculated_fields(c);
	if (!make_bmp_file(c)) goto done;

It works fine with Paint.NET and all applications based on WIC.

Note that GIMP is also saving 32bpp alpha transparent BMP with BGRA channels order.

Would you accept pull request with this image?

pal8.bmp and pal8.png differ when opened in MS Paint

When opening the generated g/pal8.bmp and the reference html/pal8.png (both with MS Paint which is quite an authority in BMP), and taking a screenshot of the magnified files to compare pixel values in an editor, some pixels have different green levels (e.g. pixel (7, 63) has green=42 in the png and green=43 in the bmp).

I think Huffman example is incorrect

I know you say it yourself:

My attempt to make a BMP file with Huffman 1D compression. It is quite possibly incorrect. Even if everything else about it is correct, I have no way to know whether it is black/white reversed, and/or flipped vertically.

But I think it's incorrect only because it's missing the RTC at the end.
From http://zig.tgschultz.com/bmp_file_format.txt the data should end with 6x EOL (End of line), also called RTC (Return to control) to signal the end of file.

My code manages to read and display your BMP fine as long as I hardcode to stop after 64 lines, because it seems it never finds the RTC.

What's about 64-bit bitmaps

There is just a little bit information about this format (https://docs.microsoft.com/en-us/windows/win32/wic/-wic-codec-native-pixel-formats) but I'm able to create a 64-bit BMP file in c# by creating 64-bit bgra Bitmap, draw a 32-bit bgra Bitmap on it and save it as bmp. The resulting file uses a BITMAPINFOHEADER with a bitcount of 64. The pixels are a bit special. All 16-bit channel values are fixed point values in the format s2.13: (sign bit, two integer bits, and thirteen fractional bits). These files seem to work with any application using WIC (like the FileExplorer, Photo, paint.net).
Would it make sense to add such files to the bmpsuite?

Huffman 1D bit order

I was surprised this hadn't been tested yet, so I tried opening the two Huffman 1D-compressed BMP files from the suite with OS/2 programs, which, considering the nature of the format, I think is an authoritative source. There's surprisingly lacking support for Huffman-compressed files even among the tools of the era, but from every program I've found that does support them, including the built-in OS/2 image viewer, the correct bit order is msb-first.

Here is pal1huffmsb.bmp, converted to a .gif file with the OS/2 Warp 4.0 image viewer.

And this is pal1hufflsb.bmp, converted the same way.

(That might not load properly with all browsers, so here it is converted to a .tif file from OS/2, and then to a .png file with GIMP:)

The shareware image viewer/converter PMView can read them and gives the same output, and can also write them (it's easier to reference, since it has a Windows version). Here's an example of a new 1 bpp Huffman 1D-compressed BMP file written with PMView based on pal8os2v2-16-comp.bmp.

Wrong header size for BitField compression

Hi,

The header size used for the following images is 40 bytes. Shouldn't it be 52 bytes ?

• g/rgb16-565.bmp
• g/rgb16-565pal.bmp
• g/rgb32bf.bmp
• q/rgb16-231.bmp
• q/rgb32-111110.bmp

The BMP_file_format wikipedia article suggests so.

Sweet project

Thanks for making this available as open source.
I am currently looking for a BMP with embedded ICC profile.
Can you tell me where I can find one? Also, do you happen to know
how common it is for users to embed ICC in BMP ?

Thanks!
Aaron

Chrome Crash

Hello,
Is it expected that when I try to view the "descriptions" page of the suite, the tab almost immediately crashes with SIGBUS?

Chrome 111.0.5563.71 (Official Build) (32-bit)

rgb24prof2.bmp does not match rgb24.png in Chrome and Firefox

As displayed by Chrome and Firefox, the top-left corner of rgb24.png is red whereas the top-left corner of bmpsuite.html is green. (Red and green are swapped.) It's not clear to me if this is a bug in bmpsuite, a bug in Chrome and Firefox, or if there are different valid renderings.

Two major BMP variants are missing - JPG wrapped in BMP and PNG wrapped in BMP

There are two major BMP variants missing:
JPG wrapped in BMP and PNG wrapped in BMP

BI_JPEG, //Specifies that the image is compressed using the JPEG file interchange format. JPEG compression trades off compression against loss.
BI_PNG, //Specifies that the image is compressed using the PNG file interchange format.

I am not sure whether you have also:
BI_CMYK = 0x0B, //The image is an uncompressed CMYK format.
BI_CMYKRLE8 = 0x0C, //A CMYK format that uses RLE compression for bitmaps with 8 bits per pixel. The compression uses a 2-byte format consisting of a count byte followed by a byte containing a color index.
BI_CMYKRLE4 = 0x0D //A CMYK format that uses RLE compression for bitmaps with 4 bits per pixel. The compression uses a 2-byte format consisting of a count byte followed by two word-length color indexes.