Winapi 在某些设备上，ATL:：CImage似乎误报了每像素alpha图像

我在将alpha图像打印到打印机设备上下文（real或XPS document writer）时遇到问题。它们在屏幕环境和打印预览中工作得很好，但当我打印到文件或打印机时，当它们位于另一个图像的顶部时，它们显示为黑色方块。我以前使用过CImage:：Draw，结果与直接使用S GDI+API的结果类似（黑色或透明方块）：

    Gdiplus::Graphics g(hDestDC) ;
    ...
    // Edit: the image value here was one aquired from a ATL::CImage not 
    // a Gdiplus::Image (see solution)
    g.DrawImage(image,rect,0,0,GetWidth(),GetHeight(),Gdiplus::UnitPixel,0,0,0);

设备大写似乎表示上下文支持通过

GetDeviceCaps(hDestDC, SB_PIXEL_ALPHA)

图像的性质似乎也无关紧要，以下是我使用的两种格式：

PNG image data, 256 x 256, 8-bit/color RGBA, non-interlaced
PNG image data, 192 x 64, 1-bit colormap, non-interlaced

使用带有CImage数据的GDI+接口，两者产生相同的结果。让alpha图像在打印上下文中的行为与在屏幕上的行为相同的最佳方式是什么？设备功能是否会因为alpha使用位图矩阵并对整个图像使用混合而造成误报

编辑日期：2013年3月4日

我的新方法是在内存中进行所有alpha混合，我的想法是，如果打印机不支持alpha混合，我将创建一个要混合的内存上下文，然后将混合结果复制到上下文中。代码的重要部分如下所示：

int width = rectDest.right - rectDest.left;
int height = rectDest.bottom - rectDest.top;

BLENDFUNCTION blendFunction;
blendFunction.BlendOp = AC_SRC_OVER;
blendFunction.BlendFlags =  0;
blendFunction.SourceConstantAlpha = 0xFF;
blendFunction.AlphaFormat = AC_SRC_ALPHA;

HDC memDC = CreateCompatibleDC(hDestDC);
HBITMAP bitmap = CreateCompatibleBitmap(hDestDC,width,height);

SelectBitmap(memDC,bitmap);
//sample the underying area and copy it to memDC
::BitBlt(memDC, 0,0, width, height, hDestDC, rectDest.left, rectDest.top, SRCCOPY);
//now blend the image in memory onto the area.
GdiAlphaBlend(memDC,0,0, width, height,GetDC(), 0, 0, GetWidth(), GetHeight(),blendFunction);
//now just BitBlt the blended data to the context
::BitBlt(hDestDC,rectDest.left, rectDest.top,width,height,memDC,0,0,SRCCOPY);

。。。令我惊讶的是，我得到了几乎相同的结果。事实上，我在屏幕左侧显示了中间步骤，以确保一切正常运行。它捕获的背景和alpha混合结果（我将其显示在打印机上下文中）在屏幕上看起来都很棒。这可能是一只虫子吗？我猜BitBlt保留了先前混合的alpha值，那么是像素数据中的实际alpha值引发了打印机设备上下文吗？如果是这样，我如何在最后一位BLT之前删除alpha

编辑：3/5/2013
现在我尝试了以下方法：
1.使用独立于设备的位图创建HBITMAP引用。
2.使用CreateDiscardableBitmap创建HBITMAP（最成功）。
3.手动将每个像素的alpha通道设置为0xFF和0x00。

BITMAPINFO bitmapInfo;
ZeroMemory(&bitmapInfo, sizeof(BITMAPINFO));
bitmapInfo.bmiHeader.biBitCount = 32; 
bitmapInfo.bmiHeader.biCompression = BI_RGB;
bitmapInfo.bmiHeader.biPlanes = 1;
bitmapInfo.bmiHeader.biSize = sizeof(bitmapInfo.bmiHeader); 
bitmapInfo.bmiHeader.biWidth = width; 
bitmapInfo.bmiHeader.biHeight = height;
bitmapInfo.bmiHeader.biSizeImage = bitmapSizeBytes;

HDC memDC = CreateCompatibleDC(hDestDC);
//was HBITMAP bitmap = CreateCompatibleBitmap(hDestDC,width,height);
//also tried HBITMAP bitmap = CreateDiscardableBitmap(hDestDC,width, height);
HBITMAP bitmap = CreateDIBSection(memDC, &bitmapInfo,DIB_RGB_COLORS,&imageBits,NULL,0x00);

---

使用一次性位图，至少让图像渲染，但对于alpha应该显示的区域，使用黑色

在PCL打印机上测试。我想你会发现是打印机，不是你的代码。如果是这种情况，唯一的解决方案是将整个页面呈现为单个位图，然后将该位图blit到打印机。就性能而言，这不是很理想，但它可以在所有打印机、Postscript或其他设备上可靠地工作

---

如果您想更深入地了解Postscript和透明胶片的问题，Wikipedia有一个解决方案。

尝试先用白色填充目标区域，然后进行混合

有可能你们认为它在屏幕上是对的，因为你们恰好混合到一个被“擦除”的窗口上，而这个窗口是不透明的白色像素

---

打印机可能正在尝试混合到尚未显式初始化的像素。也许打印机驱动程序假定这些像素最初是黑色的。这是一个合理的（即使是违反直觉的）假设。打印机纸张是白色的这一事实导致人们假设打印“透明”像素将使该区域保持白色，但从技术上讲，这些像素是未初始化的。

好的，我想我在这里找到了解决方案。这并不能解释为什么上面讨论的方法没有发挥作用，但它提供了一条前进的道路。我们的课程都基于ATL:：CImage。看起来解决方案的真正关键在于ATL:：CImage在加载某些alpha图像时，以某种方式错误处理了这些图像的图像数据。例如，对于报告相同格式的图像，它将反转其中一种而不是另一种的颜色，或者不显示其中一种。。。像这样的事情。作为测试，我将读取到CImage:：Load中的相同数据存储到Gdiplus:：Image实例中，并使用该数据绘制到图形实例上（代码如下）。这解决了所有的问题，所以在这一点上，故事的寓意似乎是用更新的东西替换基于ATL的代码，因为它不能正确处理alpha图像

以下是最新的代码：

   int width = rectDest.right - rectDest.left;
   int height = rectDest.bottom - rectDest.top;

   Gdiplus::Graphics gfx(hDestDC);
   //These next two lines allow resizing and printing of JPG to a printer
   //without them GDI+ seems to have trouble resizing and repositioning
   //JPEG files to fit onto the printer context and renders them off screen
   //and distorted.
   gfx.SetInterpolationMode(Gdiplus::InterpolationModeHighQuality);
   gfx.SetPageUnit(Gdiplus::UnitPixel);
   Gdiplus::Rect destination(rectDest.left, rectDest.top,width, height);
   Gdiplus::ImageAttributes attributes;
   //The color matrix has to be set onto the attributes or otherwise 
   //alpha will not work even though it's the identity. Also you 
   //can tweak the position at [4,4] to adjust alpha for the whole image
   //and have per-pixel alpha as well.
   Gdiplus::ColorMatrix matrix = {1.0, 0.0, 0.0, 0.0, 0.0,
                                  0.0, 1.0, 0.0, 0.0, 0.0,
                                  0.0, 0.0, 1.0, 0.0, 0.0,
                                  0.0, 0.0, 0.0, 1.0, 0.0,
                                  0.0, 0.0, 0.0, 0.0, 1.0};
   attributes.SetColorMatrix(&matrix,Gdiplus::ColorMatrixFlagsDefault, Gdiplus::ColorAdjustTypeBitmap);
   gfx.DrawImage(gdiImage, destination, 0,0, GetWidth(),GetHeight(),Gdiplus::UnitPixel, &attributes, NULL, NULL);

---

您的打印机可能是Postscript打印机吗？Postscript对透明胶片的支持有限。结果表明，正在测试的打印机是PCL 6打印机。它在XPS文档编写器中也表现出同样的行为（打印到文件）。啊，那么，你可以忽略我的回答。除非你发代码，否则我不知道有谁能帮上忙。我会试试看能否在这附近找到一台PCL打印机。顺便提一下你的屏幕渲染想法有点像我现在所做的（更新了帖子），但只是一幅图像一幅图像的基础上，而不是整个屏幕，但关于图像数据的一些东西仍然与设备上下文有关。感谢这个想法，我只是尝试了一下，但似乎没有帮助。ATL:：CImage来自GDI时代（在GDI+之前）。除了极少数例外，GDI操作不使用甚至不保留alpha通道。所以这个解决方案是有意义的。