Skip to content

Clarify various aspects of interpreting DIBs with compression of BI_BITFIELDS #5241

@peteroupc

Description

@peteroupc

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 of bmiColors, 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, and bV*AlphaMask fields 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.

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions