Java 中的 BufferedImage 和 ColorModel答案

【问题标题】：BufferedImage & ColorModel in JavaJava 中的 BufferedImage 和 ColorModel
【发布时间】：2011-02-05 13:45:55
【问题描述】：

我正在使用 java 中的图像处理库来处理图像。我要做的第一步是读取图像并创建一个java.awt.Image.BufferedImage 对象。我是这样做的，

BufferedImage sourceImage = ImageIO.read( new File( filePath ) );

上面的代码用DirectColorModel创建了一个BufferedImage对象：

rmask=ff0000
gmask=ff00
bmask=ff
掩码=0。

当我在我的 macbook 上运行上述代码时会发生这种情况。

但是当我在 linux 机器（托管服务器）上运行相同的代码时，这会创建一个带有 ColorModel 的 BufferedImage 对象：

pixelBits = 24
numComponents = 3
颜色空间 = java.awt.color.ICC_ColorSpace@c39a20
透明度 = 1 有 alpha = false
isAlphaPre = false。

我在这两种情况下都使用了相同的 jpg 图像。不知道为什么同一张图片的ColorModel在mac和linux上运行时不一样。 mac 的ColorModel 有 4 个组件，linux 的 colormodel 有 3 个组件。

因此产生了一个问题，我使用的图像处理库总是假设传递的图像的ColorModel中总是有4个组件，并且在linux机器上运行时会抛出一个数组越界异常.但在 macbook 上，它运行良好。

添加更多信息，读取图像后，我打印出image.getType()

在 mac -> 它返回 TYPE_INT_RGB（1 的值）
在 linux 上 -> 它返回 TYPE_3BYTE_BGR（5 的值）

我不确定是我做错了什么还是图书馆有问题。请让我知道你的想法。如果我没有任何意义，也可以问我任何问题！

【问题讨论】：

听起来像是库中的错误。它不应该对从ImageIO.read 返回的图像的ColorModel 做出假设。
这很可能取决于所使用的 Linux 版本和图形堆栈。对于具有合成支持的更现代的图形堆栈，它们将具有 alpha 通道。然而，正如DirectColorModel 所说，有些项目是最终的，因为 JVM 需要与操作系统/图形堆栈互操作才能实际显示内容。 OPs Linux 系统使用 3 字节 RGB 来节省内存；如果您转换模式（xrandr 等），它将转到另一个值，所以最好的办法是转换为您想要的模型。

标签： java image image-processing image-manipulation

【解决方案1】：

我不知道为什么你会得到两种不同颜色的模型，尽管我相信它们是完全一样的。 DirectColorModel 有 4 个分量，但 alpha 掩码为 0，所以实际上它和另一个一样只有 3 个分量。

我建议编写一个简单的辅助函数，在将图像传递给此图像库之前确保图像具有正确的颜色模型。辅助函数可以使用http://java.sun.com/j2se/1.4.2/docs/api/java/awt/image/ColorConvertOp.html 或使用类似以下代码（未经测试）：

私有静态 BufferedImage makeCompatible(BufferedImage image) { int w = image.getWidth(); int h = image.getHeight(); BufferedImage 结果 = new BufferedImage(w, h, BufferedImage.TYPE_4BYTE_ABGR); Graphics2D g = result.createGraphics(); g.drawRenderedImage（图像，新的仿射变换（））； //或其他一些drawImage函数 g.dispose(); 返回结果； }

假设库能够处理 BufferedImage.TYPE_4BYTE_ABGR。否则，您将不得不在此处放置其他内容。当然，您可以在转换之前检查原始图像是否已经具有正确的格式。

【讨论】：