No content change: biSizeImage docs for BI_RLE8/BI_RLE4 live in sdk-api, not this repo

[Copilot]

Issue #5265 asks for clarification of biSizeImage (and bV4SizeImage / bV5SizeImage) when biCompression is BI_RLE8 or BI_RLE4: compressed size, uncompressed size, or either, and what happens when the value exceeds the data present in the file.

This PR contains no file changes. The pages in question are not in this repository.

Finding

• A case-insensitive search for BITMAPINFO, biSizeImage, BI_RLE8, and BI_RLE4 returns zero matches across all 9,282 tracked files.
• BITMAPINFOHEADER / BITMAPV4HEADER / BITMAPV5HEADER (/windows/win32/api/wingdi/…) are authored in MicrosoftDocs/sdk-api; bitmap storage and compression conceptual topics (/windows/win32/gdi/…) are in the Win32 conceptual repo. Neither is reachable from this branch.
• Adding a GDI reference page under hub/apps/ would duplicate content this repo doesn't own, so no page was created.

Suggested next step

Transfer #5265 to MicrosoftDocs/sdk-api (wingdi.h) and apply the wording below to the three size members.

**biSizeImage**

The size, in bytes, of the image. This can be set to zero for `BI_RGB` bitmaps.

If **biCompression** is `BI_RLE8` or `BI_RLE4`, **biSizeImage** is the size, in bytes,
of the run-length encoded (compressed) image data, not the size of the decoded pixel
data. The value must be non-zero for RLE-compressed bitmaps, because GDI uses it to
determine how many bytes of compressed data to read.

If **biCompression** is `BI_JPEG` or `BI_PNG`, **biSizeImage** indicates the size of
the JPEG or PNG image buffer, respectively.

This parallels the existing BI_JPEG/BI_PNG sentence already on the page.

Open questions for a GDI owner

Not answered in the proposed wording, and not safe to guess — the reporter is writing a BMP parser and needs to know whether to accept or reject these files:

1. Does GDI treat an RLE stream as complete at the end-of-bitmap marker (0x00 0x01) if fewer than biSizeImage bytes have been consumed?
2. When biSizeImage exceeds the data actually present, is the bitmap rejected, or is the available data decoded and the remainder ignored?

Separate issue on the same page

Earlier responses on #5265 pointed to Media Foundation and MFCalculateBitmapImageSize. That doesn't apply here — these structures are current for GDI device-independent bitmaps, and the deprecation notice atop BITMAPINFOHEADER refers to the associated media feature rather than the structure. Worth correcting in the same sdk-api pass.

• Fixes Clarify biSizeImage for BI_RLE8 or BI_RLE4 bitmaps #5265

[learn-build-service-prod]

Learn Build status updates of commit 4d94c95:

⚠️ Validation status: warnings

For more details, please refer to the build report.

Note: Your PR may contain errors or warnings or suggestions unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.

[#John wick 02 (jacobmerlincornelius02-alt)]

Doc