GDI失败转换为索引颜色与确切的调色板？ [英] GDI fails conversion to indexed color with exact palette?
问题描述
摘要
使用Windows GDI将24位颜色转换为索引颜色，似乎GDI选择的颜色是足够接近，即使有完全匹配
任何人都可以确认这是一个GDI问题，或者我在某个地方犯了错误。
也许有一个请检查整个调色板的颜色匹配标志，我找不到？注意：这是不是量化。源是24位，但包含256个或更少的颜色，所以精确的调色板是微不足道的计算。问题是GDI不使用完整的调色板。
解决方法
通过映射颜色自己，但我更喜欢使用GDI，因为它应该更好地优化。问题是，它似乎是快但是错误。
详细说明
位，但使用256（或更少）的颜色。我生成一个确切的调色板，并要求GDI使用该调色板将图像转换为索引位图。对于一些像素，GDI选择类似的，但不是精确的颜色，即使在调色板的其他地方有确切的颜色。
这个问题发生在：
- SetDIBitsToDevice
-
- StretchDIBits
- BitBlt
- StretchBlt
问题不是会发生：
- SetPixel或SetPixelV在一个循环非常慢！）
- 使用我自己的代码进行映射
This on：
- Windows 7（NVidia硬件/驱动程序）
- Windows Vista驱动程序）
- Windows 2000（VMware硬件/驱动程序）
同样的结果。
我不认为这个问题是颜色管理（ICM / ICC配置文件等），因为大多数的API说他们不使用它，我已经尝试明确地关闭在GDI DC以及通过V5位图头，我不认为它将适用于我的vanlilla-Win2k VM。 p>
测试项目
一个简单的Win32 / GDI / VS2008测试项目的代码可以在这里找到：
http://www.pretentiousname.com/data/ GdiIndexColor.zip
Win32UI.cpp中的Test1函数是实际测试。它有两个RGBQUAD数组，一个是源图像，另一个是精确的调色板。它验证调色板确实是精确的，然后要求GDI使用上述API转换图像，每次测试结果。对于每个测试，它会告诉你第一个不正确的像素之前&
谢谢！
感谢您的阅读我的问题！对不起，如果这是我做一些真正蠢的结果！ ： - ）
我遇到了这个完全相同的问题，最终与Microsoft联系并向他们提供了一个测试用例。在测试用例中，我提供了一个在24位DIB中有128种颜色的渐变图像，然后将它转换为一个8位DIB，该颜色表包含来自24位图像的所有128种颜色。转换后，8位图像只使用128种颜色中的65种。
总结他们的响应：
这不是一个错误，GDI使用当向下转换图像的颜色深度时足够接近的计算。这不是真正地记录在任何地方，并且保证所有的原始颜色的唯一方法将完全转换是自己手动操作像素。
Summary
Using Windows GDI to convert 24-bit color to indexed color, it seems GDI chooses colors which are "close enough" even though there are exact matches in the supplied palette.
Can anyone confirm this as a GDI issue or am I making a mistake somewhere?
Maybe there's a "please check the whole palette for color matches" flag which I've failed to find?
Note: This is not about quantizing. The source is 24-bit but contains 256 or fewer colors so an exact palette is trivial to calculate. The problem is GDI doesn't use the full palette.
Workaround
I've worked around the problem by mapping the colors myself but I'd prefer to use GDI as it should be better optimized. Problem is, it seems to be "fast but wrong."
Detailed description
My source image is 24-bit but uses 256 (or fewer) colors. I generate an exact palette for it and ask GDI to transfer the image into an indexed bitmap using that palette. For some pixels GDI chooses similar, but not exact, colors even though there are exact colors elsewhere in the palette. This ruins smooth gradients.
This problem happens with:
- SetDIBitsToDevice
- StretchDIBits
- BitBlt
- StretchBlt
The problem does not happen with:
- SetPixel or SetPixelV in a loop (incredibly slow!)
- Using my own code to do the mapping
I've tested this on:
- Windows 7 (NVidia hardware/drivers)
- Windows Vista (ATI hardware/drivers)
- Windows 2000 (VMware hardware/drivers)
In every test I get the same results. (Not just the wrong colours but always the same wrong colors.)
I don't think the issue is color management (ICM/ICC profiles/etc.) as most of the APIs say they don't use it, I've tried explicitly turning it off on the GDI DC as well as via the V5 bitmap header, and I don't think it would apply within my vanlilla-Win2k VM.
Test Project
Code for a simple Win32/GDI/VS2008 test project can be found here:
http://www.pretentiousname.com/data/GdiIndexColor.zip
The Test1 function within Win32UI.cpp is the actual test. It has two arrays of RGBQUADs, one the source image and the other the exact palette for it. It verifies that the palette really is exact and then asks GDI to convert the image using the APIs mentioned above, testing the result each time. For each test it'll tell you the first incorrect pixel's before & after colors, or tell you that all pixels are correct if it worked.
Thanks!
Thanks for reading my question! Sorry if it's the result of me doing something really dumb! :-)
I ran into this exact same problem, eventually contacted Microsoft and provided them with a test case. In the test case I provided a gradient image that had 128 colors in a 24bit DIB, I then converted that to an 8bit DIB that was created with a color table containing all 128 colors from the 24bit image. After conversion, the 8 bit image had only used 65 of the 128 colors.
To sum up their response: This is not a bug, GDI does use a close enough calculation when down converting the color depth of an image. This is not really documented anywhere, and the only way to insure all of the original colors will convert exactly is to manually manipulate the pixels yourself.
这篇关于GDI失败转换为索引颜色与确切的调色板？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
