You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Clarify biSizeImage for BI_RLE8 or BI_RLE4 bitmaps #5265
Clarify the meaning of biSizeImage of BITMAPINFOHEADER (and the like member of BITMAPV4HEADER and BITMAPINFOV5HEADER) when biCompression (or the like member) is BI_RLE8 or BI_RLE4. Is the value equal to the size of the compressed image data in bytes? The uncompressed image data? Either? What if biSizeImage is larger than the data available in the image file?
Please see the deprecation notice at the top of BITMAPINFOHEADER, with the recommendation to move to Media Foundation, etc.. In any case, Media Foundation has the MFCalculateBitmapImageSize function, which might help you with this question.
Please see the deprecation notice at the top of BITMAPINFOHEADER, with the recommendation to move to Media Foundation, etc.. In any case, Media Foundation has the MFCalculateBitmapImageSize function, which might help you with this question.
-Steve
My question doesn't relate to Windows Media Foundation. Nor does it relate only to BITMAPINFOHEADER, which is not used only in Windows Media Foundation or in video encoding.
Rather, it relates to the use of BITMAPINFOHEADER (and BITMAPV4HEADER and BITMAPV5HEADER) in the Windows GDI, specifically in Windows device-independent bitmaps, where these three structures are not obsolete and are alive and well. The answer I seek here will be helpful when interpreting images in the .bmp format.
I'll consult the product team for help with your questions, and I'll try and find out why the docs for BITMAPINFOHEADER say that the feature associated with it is obsolete. The implication being that BITMAPINFOHEADER is obsolete.
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.
I am indeed working on a routine to read Windows bitmap (.bmp) files, in Python.
The points in this issue (#5265) and in #5241 are points where the documentation for BITMAPINFOHEADER, BITMAPV4HEADER, and BITMAPV5HEADER needs some more clarity so that I know whether to accept, reject, or properly interpret such files in tricky cases.
Thanks for the follow-up, and for clarifying that this is about reading .bmp files directly rather than via Media Foundation.
The biSizeImage semantics for BI_RLE8 / BI_RLE4 live in the Win32 API reference for BITMAPINFOHEADER (and the BITMAPV4HEADER / BITMAPV5HEADER equivalents) under /windows/win32/api/wingdi/.... That reference is generated from a separate repository than this one, so clarification requests filed here don't reach the maintainers of those pages.
To get this in front of the right team, please use the Feedback control at the bottom of the BITMAPINFOHEADER reference page — it files against the correct source repo. We're also flagging it internally (jkendirs@microsoft.com).
Closing here since it isn't actionable in this repo, but feel free to reopen or use the reference-page feedback control if you need to keep the thread going.
Activity
stevewhims commentedon Jan 22, 2025
Hi, Peter Occil (@peteroupc),
Please see the deprecation notice at the top of BITMAPINFOHEADER, with the recommendation to move to Media Foundation, etc.. In any case, Media Foundation has the MFCalculateBitmapImageSize function, which might help you with this question.
-Steve
peteroupc commentedon Jan 22, 2025
My question doesn't relate to Windows Media Foundation. Nor does it relate only to BITMAPINFOHEADER, which is not used only in Windows Media Foundation or in video encoding.
Rather, it relates to the use of BITMAPINFOHEADER (and BITMAPV4HEADER and BITMAPV5HEADER) in the Windows GDI, specifically in Windows device-independent bitmaps, where these three structures are not obsolete and are alive and well. The answer I seek here will be helpful when interpreting images in the
.bmpformat.stevewhims commentedon Jan 22, 2025
Hi, Peter Occil (@peteroupc),
I'll consult the product team for help with your questions, and I'll try and find out why the docs for BITMAPINFOHEADER say that the feature associated with it is obsolete. The implication being that BITMAPINFOHEADER is obsolete.
-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.
Merge pull request #5265 from MicrosoftDocs/main638778211418672132syn…
peteroupc commentedon Aug 13, 2025
I am indeed working on a routine to read Windows bitmap (.bmp) files, in Python.
The points in this issue (#5265) and in #5241 are points where the documentation for BITMAPINFOHEADER, BITMAPV4HEADER, and BITMAPV5HEADER needs some more clarity so that I know whether to accept, reject, or properly interpret such files in tricky cases.
GrantMeStrength commentedon Sep 2, 2026
Thanks for the follow-up, and for clarifying that this is about reading
.bmpfiles directly rather than via Media Foundation.The
biSizeImagesemantics forBI_RLE8/BI_RLE4live in the Win32 API reference forBITMAPINFOHEADER(and theBITMAPV4HEADER/BITMAPV5HEADERequivalents) under/windows/win32/api/wingdi/.... That reference is generated from a separate repository than this one, so clarification requests filed here don't reach the maintainers of those pages.To get this in front of the right team, please use the Feedback control at the bottom of the BITMAPINFOHEADER reference page — it files against the correct source repo. We're also flagging it internally (jkendirs@microsoft.com).
Closing here since it isn't actionable in this repo, but feel free to reopen or use the reference-page feedback control if you need to keep the thread going.