如何正确计算位图文件中的bfOffBits参数？

嵌入式位图资源不会返回BITMAPFILEHEADER（按Raymond Chen的结论属于“正确不返回”的场景），因此需要手动构造这个文件头，其中bfOffBits的计算是核心——它代表像素数据相对于文件开头的字节偏移量，一旦计算错误，位图渲染就会出错。

常见错误的Workaround #

很多示例直接用固定值计算：

bmfHeader.bfOffBits = (DWORD)sizeof(BITMAPFILEHEADER) + (DWORD)sizeof(BITMAPINFOHEADER);

这种写法只适用于无调色板的真彩色位图，完全忽略了索引位图或带调色板位图的调色板大小，会导致偏移计算不足，无法正确定位像素数据。

正确的计算逻辑 #

bfOffBits的本质是文件开头到像素数据的总字节数，必须包含三部分：

1. BITMAPFILEHEADER的大小（固定14字节）
2. BITMAPINFOHEADER（或其扩展头，如BITMAPV5HEADER）的大小（由biSize字段指定，而非固定的40字节）
3. 调色板或颜色掩码的总大小

分场景处理 #

1. 使用传统RGBQUAD调色板的位图

这是最常见的索引位图场景（如BI_RGB压缩格式、位深度≤8的位图）：

• 每个调色板条目是RGBQUAD结构，固定4字节
• 调色板总大小 = biClrUsed * sizeof(RGBQUAD)
  • 如果biClrUsed为0，需根据位深度计算默认调色板数量：位深度n（≤8）对应1<<n个条目，比如8位对应256个，4位对应16个

2. 使用BI_BITFIELDS压缩的位图

这种格式没有传统调色板，而是用3个DWORD（每个4字节）的颜色掩码来定义RGB分量，因此需要直接加上3 * sizeof(DWORD)（12字节），此时biClrUsed通常为0，无需额外处理。

解释MSDN示例的合理性 #

MSDN中的示例代码：

hdr.bfOffBits = (DWORD) sizeof(BITMAPFILEHEADER) + 
                pbih->biSize + pbih->biClrUsed 
                * sizeof (RGBQUAD); 

它只针对使用RGBQUAD调色板的场景，这是嵌入式位图资源中最普遍的情况，因此直接用sizeof(RGBQUAD)作为条目大小。但要注意，这个示例没有覆盖BI_BITFIELDS格式，实际使用时需要补充该场景的处理。

完整的计算代码示例 #

DWORD CalculateBfOffBits(const BITMAPINFOHEADER* pBih) {
    // 基础偏移：文件头 + 信息头
    DWORD offBits = sizeof(BITMAPFILEHEADER) + pBih->biSize;
    
    if (pBih->biCompression == BI_BITFIELDS) {
        // BI_BITFIELDS格式，追加3个颜色掩码的大小
        offBits += 3 * sizeof(DWORD);
    } else {
        DWORD clrCount = pBih->biClrUsed;
        if (clrCount == 0 && pBih->biBitCount <= 8) {
            // 无指定调色板数量时，按位深度计算默认值
            clrCount = 1 << pBih->biBitCount;
        }
        // 追加调色板总大小
        offBits += clrCount * sizeof(RGBQUAD);
    }
    
    return offBits;
}

内容的提问来源于stack exchange，提问作者yoonsoh