【问题标题】:ATL::CImage appears to misrepresent per-pixel alpha images on certain devicesATL::CImage 似乎在某些设备上歪曲了每像素 alpha 图像
【发布时间】:2013-02-16 10:51:45
【问题描述】:

我在将 alpha 图像打印到打印机设备上下文(真实或 XPS 文档编写器)时遇到问题。它们在屏幕上下文和打印预览中工作得很好,但是当我打印到文件或打印机时,当它们位于另一个图像的顶部时,它们会显示为黑色方块。我之前使用的是 CImage::Draw,结果与直接使用 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

使用 GDI+ 接口处理 CImage 数据时,两者都产生相同的结果。让 alpha 图像在打印上下文中的行为方式与在屏幕上的行为方式相同的最佳方式是什么?设备功能是否会因为 alpha 使用 BitmapMatrix 并为整个图像使用混合工作而歪曲某些内容?

编辑: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 值是否会引发打印机设备上下文?如果是这样,我怎样才能在最终 BitBlt 之前删除 alpha?

编辑:2013 年 3 月 5 日
现在我尝试了以下方法:
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 的区域使用黑色。

【问题讨论】:

  • 您的打印机有可能是 Postscript 打印机吗? Postscript 对透明胶片的支持有限。
  • 原来正在测试的打印机是 PCL 6 打印机。它在 XPS 文档编写器中也表现出相同的行为(打印到文件)。
  • 啊,那你可以无视我的回答。除非您发布您的代码,否则我不知道任何人都可以提供帮助。

标签: winapi graphics mfc gdi+ atl


【解决方案1】:

好的,我想我在这里找到了解决方案。好吧,它没有解释为什么上面讨论的方法不起作用,但它提供了前进的方向。我们的类都基于 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);

【讨论】:

  • ATL::CImage 来自 GDI 时代(在 GDI+ 之前)。除了极少数例外,GDI 操作不使用甚至不保留 Alpha 通道。所以这个解决方案是有道理的。
【解决方案2】:

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

您可能认为它在屏幕上是正确的,因为您碰巧正在混合到一个已“擦除”而不透明的白色像素的窗口上。

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

【讨论】:

  • 感谢您的建议,我刚刚尝试过,但似乎没有帮助。
【解决方案3】:

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

如果您想更深入地了解 Postscript 和透明胶片的问题,维基百科有一个 pretty good summary of the issue

【讨论】:

  • 我会试试看能不能在这附近找到一台 PCL 打印机。顺便说一句...您的屏幕渲染想法有点像我现在正在做的事情(更新了帖子),但只是逐个图像而不是整个屏幕,但有关该图像数据的某些内容仍然与设备上下文有关。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2020-01-03
  • 2012-03-30
  • 1970-01-01
  • 1970-01-01
  • 2016-10-08
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多