Repository navigation
Clarify various aspects of interpreting DIBs with compression of BI_BITFIELDS #5241
Description
Type of issue
Missing information
Feedback
This feedback relates to Windows device-independent bitmap (DIB) formats with the BI_BITFIELDS compression mode.
When a DIB has the compression mode BI_BITFIELDS (biCompression of BITMAPINFOHEADER or bV*Compression of BITMAPV4HEADER or BITMAPV5HEADER equals BI_BITFIELDS):
- Clarify the meaning of
b*ClrUsed. Is this member 0? Is this member equal to 3, the size ofbmiColors, or the number of colors in the color table if any? - Can the DIB contain both a color table and color masks that follow the BITMAPINFOHEADER, BITMAPV4HEADER, or BITMAPV5HEADER?
- In the case of a packed DIB's BITMAPV4HEADER or BITMAPV5HEADER, is the DIB allowed to have color masks that follow the header? Or must the
bV*RedMask,bV*GreenMask,bV*BlueMask, andbV*AlphaMaskfields be used as the masks in this case? - Clarify the valid choices for color masks (including the alpha mask, if any). For example, can one of the color masks be zero and can the fields of the masks overlap?
- Clarify the conversion of color components to 8 bits per color component, especially when the color masks reflect that a color component has fewer or greater than 8 bits or when a color mask is 0.
Is the member bV*AlphaMask valid only for the compression mode BI_BITFIELDS? If no, then for DIBs of which bits-per-pixel values can this member be specified?
Also, the documentation for BITMAPV4HEADER says bV4V4Compression in one place, rather than bV4Compression.
Activity
[-]Clarify meaning of `biClrUsed` and presence of color tables and color masks in DIBs when compression is `BI_BITFIELDS`[/-][+]Clarify meaning of `biClrUsed` and presence of a color table in DIBs when compression is `BI_BITFIELDS`[/+][-]Clarify meaning of `biClrUsed` and presence of a color table in DIBs when compression is `BI_BITFIELDS`[/-][+]Clarify meaning of `biClrUsed`, presence of a color table, and valid color masks in DIBs when compression is `BI_BITFIELDS`[/+][-]Clarify meaning of `biClrUsed`, presence of a color table, and valid color masks in DIBs when compression is `BI_BITFIELDS`[/-][+]Clarify various aspects of interpreting DIBs with compression of `BI_BITFIELDS`[/+]stevewhims commentedon Jan 22, 2025
Hi, Peter Occil (@peteroupc),
I'll consult the product team for help with these questions.
-Steve
stevewhims commentedon Jan 22, 2025
This is the same response for issues 5241 and 5265.
It sounds like you want to retrieve information about a bitmap. Parsing a bitmap that way in your own code is extremely complicated and error-prone, and we don’t recommend it.
If you could describe exactly what it is you want to do, then perhaps there are other ways we can help.
peteroupc commentedon Jan 23, 2025
I am indeed working on a routine to read Windows bitmap (
.bmp) files, in Python, and the points in this issue and in #5265 are points where the documentation for BITMAPINFOHEADER, etc. needs some more clarity so that I know whether to accept, reject, or properly interpret such files in tricky cases.Consider, for example, a DIB which—
biSizeImagethat equals the uncompressed size rather than the compressed size.Should I accept or reject any of these cases when they arise?
Merge pull request #5241 from MicrosoftDocs/main638768813868373360syn…
peteroupc commentedon Jul 17, 2026
I still seek clarification in the API documentation on this issue as well as #5265.
GrantMeStrength commentedon Sep 2, 2026
Thanks for the detailed questions, and for the earlier thread here.
These clarifications all concern the Win32 API reference for
BITMAPINFOHEADER,BITMAPV4HEADER, andBITMAPV5HEADER(the/windows/win32/api/wingdi/...pages), including thebV4V4Compressionvs.bV4Compressiontypo you spotted. That reference content is generated from a separate repository than this one (MicrosoftDocs/windows-dev-docs), so feedback filed here won't reach the team that maintains those pages.The most reliable way to get these routed is the Feedback control at the bottom of the specific API reference page (for example, on the BITMAPINFOHEADER page) — that files against the correct source repo. We're also flagging this internally (jkendirs@microsoft.com) so the header-interpretation questions and the
bV4V4Compressiontypo are on the right team's radar.I'm going to close this issue here since it can't be actioned in this repo, but please don't hesitate to reopen or file via the reference page's feedback control if anything above is unclear.
peteroupc commentedon Sep 2, 2026
I should note, though, the following:
These two circumstances motivated me to post an issue in this repository, which is related to the win32 repository and does accept the filing of issues.