通过SOIL保存位图时断开BMP。截图区

Question

这是我最后一个关于将截图保存到SOIL的问题的延续。 here现在我想知道，如何制作屏幕截图部分并消除奇怪行为的原因。我的代码：

bool saveTexture(string path, glm::vec2 startPos, glm::vec2 endPos) 
{ 
    const char *charPath = path.c_str(); 

    GLuint widthPart = abs(endPos.x - startPos.x); 
    GLuint heightPart = abs(endPos.y - startPos.y); 

    BITMAPINFO bmi; 
    auto& hdr = bmi.bmiHeader; 
    hdr.biSize = sizeof(bmi.bmiHeader); 
    hdr.biWidth = widthPart; 
    hdr.biHeight = -1.0 * heightPart; 
    hdr.biPlanes = 1; 
    hdr.biBitCount = 24; 
    hdr.biCompression = BI_RGB; 
    hdr.biSizeImage = 0; 
    hdr.biXPelsPerMeter = 0; 
    hdr.biYPelsPerMeter = 0; 
    hdr.biClrUsed = 0; 
    hdr.biClrImportant = 0; 

    unsigned char* bitmapBits = (unsigned char*)malloc(3 * widthPart * heightPart); 

    HDC hdc = GetDC(NULL); 
    HDC hBmpDc = CreateCompatibleDC(hdc); 
    HBITMAP hBmp = CreateDIBSection(hdc, &bmi, DIB_RGB_COLORS, (void**)&bitmapBits, nullptr, 0); 
    SelectObject(hBmpDc, hBmp); 
    BitBlt(hBmpDc, 0, 0, widthPart, heightPart, hdc, startPos.x, startPos.y, SRCCOPY); 

    //UPDATE: 
    - int bytes = widthPart * heightPart * 3; 
    - // invert R and B chanels 
    - for (unsigned i = 0; i< bytes - 2; i += 3) 
    - { 
    - int tmp = bitmapBits[i + 2]; 
    - bitmapBits[i + 2] = bitmapBits[i]; 
    - bitmapBits[i] = tmp; 
    - } 

    + unsigned stride = (widthPart * (hdr.biBitCount/8) + 3) & ~3; 
    + // invert R and B chanels 
    + for (unsigned row = 0; row < heightPart; ++row) { 
    +  for (unsigned col = 0; col < widthPart; ++col) { 
    +   // Calculate the pixel index into the buffer, taking the 
      alignment into account 
    +   const size_t index{ row * stride + col * hdr.biBitCount/8 }; 
    +   std::swap(bitmapBits[index], bitmapBits[index + 2]); 
    +  } 
    + } 

    int texture = SOIL_save_image(charPath, SOIL_SAVE_TYPE_BMP, widthPart, heightPart, 3, bitmapBits); 

    return texture; 
} 

当我运行这个，如果widthPart和heightPart是偶数，那就很完美了。但是，如果从这个事情是奇数我得到这个BMP的：

我检查任何转换和代码的两倍，但在我看来，原因是我的错块传输功能。转换RGB的功能不会影响问题。什么可能是一个原因？这是BitBlt中区域的正确方法？

更新无偶数或奇数。当这个数字相等时，产生正确的图像。我不知道哪里出了问题（（

UPDATE2

SOIL_save_image功能检查参数错误并发送至stbi_write_bmp：

int stbi_write_bmp(char *filename, int x, int y, int comp, void *data) 
{ 
    int pad = (-x*3) & 3; 
    return outfile(filename,-1,-1,x,y,comp,data,0,pad, 
     "11 4 22 4" "4 44 22 444444", 
     'B', 'M', 14+40+(x*3+pad)*y, 0,0, 14+40, // file header 
     40, x,y, 1,24, 0,0,0,0,0,0);    // bitmap header 
} 

OUTFILE功能：

static int outfile(char const *filename, int rgb_dir, int vdir, int x, int 
y, int comp, void *data, int alpha, int pad, char *fmt, ...) 
{ 
    FILE *f = fopen(filename, "wb"); 
    if (f) { 
     va_list v; 
     va_start(v, fmt); 
     writefv(f, fmt, v); 
     va_end(v); 
     write_pixels(f,rgb_dir,vdir,x,y,comp,data,alpha,pad); 
     fclose(f); 
    } 
    return f != NULL; 
} 

Answer 1

破碎的位图图像是Windows位图之间的数据布局不一致以及SOIL库预计的结果。从CreateDIBSection返回像素缓冲器遵循的Windows规则（见Bitmap Header Types）：

扫描线对齐DWORD [...]。它们必须填充扫描线宽度，以字节为单位，这些宽度不能被4 [...]整除。

换言之：每条扫描线的宽度（以字节为单位）为(biWidth * (biBitCount/8) + 3) & ~3。另一方面，SOIL库不希望像素缓冲区是DWORD对齐的。

为了解决这个问题，像素数据在传递到SOIL之前需要进行转换，通过剥离（潜在）填充和交换R和B颜色通道。下面的代码这样做就地：

unsigned stride = (widthPart * (hdr.biBitCount/8) + 3) & ~3; 

for (unsigned row = 0; row < heightPart; ++row) { 
    for (unsigned col = 0; col < widthPart; ++col) { 
     // Calculate the source pixel index, taking the alignment into account 
     const size_t index_src{ row * stride + col * hdr.biBitCount/8 }; 
     // Calculate the destination pixel index (no alignment) 
     const size_t index_dst{ (row * width + col) * (hdr.biBitCount/8) }; 
     // Read color channels 
     const unsigned char b{ bitmapBits[index_src] }; 
     const unsigned char g{ bitmapBits[index_src + 1] }; 
     const unsigned char r{ bitmapBits[index_src + 2] }; 
     // Write color channels switching R and B, and remove padding 
     bitmapBits[index_dst] = r; 
     bitmapBits[index_dst + 1] = g; 
     bitmapBits[index_dst + 2] = b; 
    } 
} 

有了这个代码，index_src是索引到像素缓冲器，其包括填充以执行适当的DWORD对准。 index_dst是没有应用任何填充的索引。将像素从index_src移动到index_dst可删除（潜在）填充。

---

泄密的符号是扫描线移动到左边或右边被一个或两个像素（或以不同的速度各个颜色通道）。这通常是一个安全的迹象，即扫描线对齐不一致。
该操作是破坏性的，即，像素缓冲器不再被传递到Windows GDI函数一旦被转换，尽管原始数据可以 被重建，即使有点更复杂。