图像颜色转换

Question

我需要将24bppRGB转换为16bppRGB，8bppRGB，4bppRGB，8bpp灰度和4bpp灰度。有什么好的链接或其他建议吗？

最好使用Windows / GDI +

[编辑]速度比质量更重要。源图像是截图 需要[EDIT1]颜色转换以最小化空间

Answer 1

正如其他人所建议的那样，你最好让自己成为一个图书馆。除了ImageMagick，还有其他一些，例如OpenCV。将其留给图书馆的好处是：

• 节省一些时间 - 通过减少开发和测试算法的时间
• 的速度即可。大多数库都被优化到远远高于标准开发人员（比如我们自己）可以实现的水平
• 符合标准。有许多图像格式，使用库可以解决标准符合性问题。

如果您自己这样做，那么您的问题可以分为以下子问题：

1. 简单color quantization。正如@Alf P. Steinbach指出的那样，这只是“降低”颜色数量。 RGB24每个R，G，B通道有8位。对于RGB16，您可以执行a number of conversions：
   • R，G，B中每一个的相等位数。这通常表示每个4或5位。
   • 偏爱绿色通道（人眼对绿色更敏感）并给它6位。 R和B得5位。
   • 您甚至可以为RGB24到RGB8做同样的事情，但结果不会像托盘化图像那样漂亮：
   • 4位绿色，2位红色，2位蓝色。
   • 3位绿色，红色和蓝色之间的5位
2. 货盘化（indexed color）。这是从RGB24到RGB8和RGB4。这是难以解决的问题，需要自己解决。
3. 颜色到灰度转换。 非常简单。将RGB24转换为YUV'色彩空间，并保留Y'通道。这将为您提供8bpp的灰度。如果您想要4bpp灰度，那么您可以量化或进行货盘化。
4. 另请务必查看chroma subsampling。通常，您可以将比特率降低三分之一，而不会对图像质量造成明显损失。

通过这种细分，你可以分而治之。问题1和2你可以很快解决。通过粗略的颜色量化，您可以看到质量。

您是否要解决问题2将取决于上述结果。你说速度更重要，所以如果颜色量化的质量只是足够好，不要打扰货盘化。

最后，您从未提及为什么您正在这样做。如果这是为了减少存储空间，那么您应该查看image compression。即使是无损压缩也会比单独减少颜色深度给出更好的结果。

修改

如果您开始使用PNG作为最终格式，那么您的选项为quite limited，因为RGB16和RGB8在PNG header中都不是有效组合。

所以这意味着：无论位深度如何，如果想要RGB色彩图像低于24bpp（每通道8位），您将 切换到索引颜色。这意味着你 NOT 能够利用我上面提到的颜色量化和色度抽取 - 它在PNG中不受支持。所以这意味着你将 来解决问题2 - 货盘化。

但在你考虑之前，还有一些问题：

• 您的图片有哪些尺寸？
• 您追求的是什么样的理想文件大小？
• 直接RBG24 + PNG压缩与理想文件大小有多接近？

• 您的图片来源是什么？你已经提到了屏幕截图，但由于你非常担心磁盘空间，我开始怀疑你可能正在处理图像序列（视频）。如果是这样，那么你可以做得比PNG压缩更好。

  哦，如果你真的想用PNG做事，那么一定要看看this library。

Answer 2

找到你自己的ImageMagick [sic]库的副本。它是非常可配置的，因此您可以教它有关您需要处理的某些二进制格式的详细信息......

Answer 3

请参阅：ImageMagick，它具有非常实用的许可证。

Answer 4

我通过Vista和Win7附带的GDI +，v.1.1获得了可接受的结果（初步）。它使用标准调色板allows conversion到16bpp（我使用PixelFormat16bppRGB565）和8bpp和4bpp。 “最佳调色板”可以获得更好的质量--GDI +将为每个屏幕截图计算最佳调色板，但转换速度要慢两倍。通过指定简单的自定义调色板，例如，收到灰度。如展示here，除了我不需要手动修改像素，Bitmap::ConvertFormat()为我做了。

[EDIT]结果真的可以接受，直到我决定在WinXP上检查解决方案。令人惊讶的是，微软决定不向WinXP发送GDI + v.1.1（Bitmap::ConvertFormat所需）。好身手！所以我继续研究......

[EDIT]不得不重新实现GDI +上的干净GDI硬编码调色板