ImageIO读取的RGB值略微不同于其他方法

我发现在使用Java（实际上是绘制.NET ）时，我使用的不同是RGB，而不是使用ImageMagick，Gimp，Python和Octave。 最后4个都同意彼此，所以我假设是正确的。

对于这些示例，我正在使用此测试图像： http://farm3.static.flickr.com/2811/9177301733_9836174725_o.jpg ： http://farm3.static.flickr.com/2811/9177301733_9836174725_o.jpg

测试像素x=4144 y=2768

  RGB Java = (125, 107, 69) Paint.NET = (125, 107, 69) ImageMagick = (128, 106, 67) Python = (128, 106, 67) Octave = (128, 106, 67) Gimp = (128, 106, 67) 

是什么赋予了？

这是使用imagemagick的快速测试：

 convert image.jpg -crop 1x1+4144+2768 -depth 8 txt: 

输出：

 # ImageMagick pixel enumeration: 1,1,65535,srgb 0,0: (32896,27242,17219) #806A43 srgb(128,106,67) 

这里有一些java和python代码也演示了这个问题：

 import org.apache.commons.io.FileUtils; import org.junit.Test; import javax.imageio.ImageIO; import java.awt.image.BufferedImage; import java.io.File; import java.io.IOException; import java.net.URISyntaxException; import java.net.URL; public class ImageIOTest { @Test public void can_read_file() throws IOException, InterruptedException, URISyntaxException { File tempFile = File.createTempFile("image", "jpg"); FileUtils.copyURLToFile(new URL("http://sofzh.miximages.com/java/9177301733_9836174725_o.jpg"), tempFile); BufferedImage image = ImageIO.read(tempFile); int javaRGB = image.getRGB(4144, 2768); int javaRed = (javaRGB >> 16) & 0xFF; int javaGreen = (javaRGB >> 8) & 0xFF; int javaBlue = (javaRGB >> 0) & 0xFF; System.out.printf("rgb: (%d, %d, %d)", javaRed, javaGreen, javaBlue); } } 

这是相应的python脚本：

 from PIL import Image import sys, urllib, cStringIO file = cStringIO.StringIO(urllib.urlopen("http://sofzh.miximages.com/java/9177301733_9836174725_o.jpg").read()) im = Image.open(file) pix = im.load() print pix[4144, 2768] 

我已经尝试过使用这个12monkeys库 ，希望能解决这个问题，但不会骰子。 如何使用java提取正确的RGB值？ 当然，我不是第一个遇到这个问题的人！

更新

我尝试了getRaster().getSample()但得到了相同的无效结果： System.out.println(raster.getSample(4144, 2768, 0)+","+ raster.getSample(4144, 2768, 1)+","+ raster.getSample(4144, 2768, 2)); 产量： 125,107,69

更多信息

下面是一些输出，显示了三个不同工具为图像左上角的前9个（3×3平方）像素解码的RGB值。 如您所见，Python和ImageMagick是齐声的。 Java有时会匹配。 我把一个X放在java不同意的地方……：

 Tool [x, y] = (R , G , B ) ImageIO : [0, 0] = (86, 90, 93) Python : [0, 0] = (86, 90, 93) ImageMagick : [0, 0] = (86, 90, 93) ImageIO : [1, 0] = (86, 90, 93) Python : [1, 0] = (86, 90, 93) ImageMagick : [1, 0] = (86, 90, 93) ImageIO : [2, 0] = (90, 91, 95) X Python : [2, 0] = (88, 92, 95) ImageMagick : [2, 0] = (88, 92, 95) ImageIO : [0, 1] = (85, 93, 95) Python : [0, 1] = (85, 93, 95) ImageMagick : [0, 1] = (85, 93, 95) ImageIO : [1, 1] = (85, 93, 95) X Python : [1, 1] = (87, 92, 95) ImageMagick : [1, 1] = (87, 92, 95) ImageIO : [2, 1] = (87, 92, 95) Python : [2, 1] = (87, 92, 95) ImageMagick : [2, 1] = (87, 92, 95) ImageIO : [0, 2] = (83, 93, 94) Python : [0, 2] = (83, 93, 94) ImageMagick : [0, 2] = (83, 93, 94) ImageIO : [1, 2] = (83, 93, 94) X Python : [1, 2] = (84, 92, 94) ImageMagick : [1, 2] = (84, 92, 94) ImageIO : [2, 2] = (83, 91, 93) Python : [2, 2] = (83, 91, 93) ImageMagick : [2, 2] = (83, 91, 93) 

为什么Java为某些像素提供不同的值？ 或者，是否有另一种（快速）方法使用本机Java代码生成正确的值？

更新2016-09-26：

我提交了我的代码来演示这个问题并将其推送到github（ imageio-test ），以便我可以在不同的机器上轻松测试它。 事实certificate，Java在OSX和Ubuntu Linux上都是一致的，但是Python，ImageMagick和Octave是不一致的。 换句话说，在Linux机器上，所有工具都互相认同，因此，我现在认为java一直都是正确的，而且其他工具在OSX上给出了错误的结果！ 我仍然不明白为什么，我没有任何具体的证据certificate哪些值是正确的，但我到了某个地方……

Answer 1

实际上，我想解决这个问题，并说我很惊讶这么多不同的平台和工具实际上产生了相同的价值。 🙂

JPEG是有损的

首先，JPEG是一种有损图像压缩方法。 这意味着无法再现原始的精确数据。 或者，如果您愿意，几个不同的像素值可能在某种程度上都是“正确的”。

不是所有JPEG软件都从同一源文件生成完全相同的值的技术原因通常是值的不同舍入/钳位，或者浮点运算的整数近似以获得更好的性能。 例如，其他变化可能源于应用于恢复二次采样的色度值的不同插值算法（即，更平滑的图像可能看起来更令人愉悦，但不一定更正确）。

类似问题的另一个优秀答案表明“JPEG标准不要求解码器实现产生逐位相同的输出图像” ，并引用维基百科JPEG条目 ：

[…]编码的精确要求[…]; 参考算法的输出不得超过：

• 每个像素分量最多有一位差异
• 每个8×8像素块的均方误差较小
• 每个8×8像素块的平均误差非常低
• 整个图像的均方误差非常小
• 整个图像的平均误差极低

（注意，上面仅讨论了参考实现 ）。

但是，幸运的是，似乎所有的软件/工具最终都使用了（某些版本的） libjpeg 。 因为它们都使用libjpeg，所以您看到的差异来源很可能与JPEG解码无关。

色彩空间

即使您的所有软件都使用RGB值将JPEG文件转换为表示，但它们用于此表示的颜色空间可能存在差异。

看起来您使用的所有软件实际上都在sRGB颜色空间中显示RGB值。 这可能是主流计算中使用的最标准和最广泛使用的色彩空间，所以这并不奇怪。 由于颜色空间始终是sRGB，因此您看到的差异来源很可能不是颜色空间。

ICC配置文件和颜色匹配

下一个可能的色差来源是色彩匹配（由色彩匹配模块，CMM或色彩管理系统，CMS完成）不是100％精确的科学（参见本文关于黑点补偿或阅读一些来自Little CMS博客的更多技术post）。

很可能Mac OS X上运行的软件使用Apple的CMM，而Java总是使用Little CMS（来自OpenJDK 7或Oracle JDK / JRE 8），Linux平台上的大多数软件也可能使用开源Little CMS（根据Little CMS主页，“你可以在大多数Linux发行版中找到Little CMS”。 Windows上的软件也可能略有偏差（我无法validationPaint.Net是否使用Little CMS，Windows内置CMM或其他东西）。 当然，使用Adobe的CMM（即Photoshop）也可能会有所偏差。

再说一次，幸运的是，您测试的很多软件都使用相同的CMM或CMS引擎， Little CMS ，所以您将获得大量相同的结果。 但似乎您测试的某些软件使用不同的CMM，并且可能是轻微颜色差异的来源。

综上所述

您看到的不同像素值都是“正确的”。 差异源于软件中算法的不同实现或近似，但这并不一定意味着一个值是正确的而其他值是错误的。

PS：如果需要在多个平台上重现完全相同的值，请在所有平台上使用相同的工具堆栈/相同算法。

Answer 2

根据我的评论，您用于检索像素颜色值的各种应用程序/库之间的主要区别在于它们都使用不同版本的libjpeg – 至少在Mac OSX上。

当您将Github项目签出到某些版本的Ubuntu时，您会看到所有值都报告相同。 在这些情况下，python ImageMagick和Java JDK / JRE使用相同的libjpeg实现。

在Mac上，如果您通过homebrew安装了jpeg ，或者通过pip安装了Pillow ，那么你会注意到他们正在使用libjpeg v9（ libjpeg.9.dylib ），而Java 7和8 JDK附带了他们自己的libjpeg捆绑的相当不同。

Octave将其jpeg依赖项列为libjpeg8-dev 。

GIMP，Inkscape，Scribus等也捆绑了自己的。 在我的例子中，GIMP捆绑了与python和ImageMagick相同的版本，这将解释类似的值（即： /Applications/GIMP.app/Contents/Resources/lib/libjpeg.9.dylib ）

如果您想保证应用程序中的值相同，您可以选择：

1. 坚持使用相同的平台/堆栈（由@haraldk建议） – 坚持在Linux平台上开发/运行你的东西，保证所有人都使用相同的libjpeg版本
2. 将Java代码绑定到与其他应用程序使用的版本相同的版本 – 即：加载libjpeg.9.dylib并使用Java应用程序中的代码。 我不是百分百肯定你怎么做的。
3. 重新编译JDK以使用正确的JDK – 这个答案引用的一个选项是使用openjdk并根据所需的libjpeg版本进行编译，这听起来更容易实现。

我承认选项2和3是选项1的更难的版本！

注意：
我肯定会对@haraldk的回答进行投票，因为他的结论几乎是一样的。

我也玩过使用不同的icc配置文件，它们给出了完全不同的答案。 所以值得警惕。

我只是想添加一个更加强调libjpeg实现的答案，因为我相信这就是你在特定实例中捕捉到的东西。

更新

实际上，在@ haraldk的回答中还有另一个主要区别，即CMM和Little CMS之间的差异。 正如他所说：Java使用的是Little CMS， Ubuntu也使用它

我实际上认为这更有可能成为答案。

Answer 3

颜色一致性和ICC配置文件

上传图像时，Java不尊重颜色配置文件。 不同的操作系统也有不同的处理RGB颜色。

以下是Oracle编写的关于import java.awt.color ：

通常，Color或ColorModel将与ICC配置文件相关联，ICC配置文件是输入，显示或输出配置文件。 还有其他类型的ICC配置文件，例如抽象配置文件，设备链接配置文件和命名颜色配置文件，它们不包含适合表示颜色，图像或设备的颜色空间的信息。 尝试从不适当的ICC配置文件创建ICC_ColorSpace对象是一个错误。

ICC配置文件表示从配置文件的颜色空间（例如监视器）到配置文件连接空间（PCS）的转换。 用于标记图像或颜色的感兴趣的配置文件具有PCS，其是ICC配置文件格式规范中定义的设备无关空间（一个CIEXYZ空间和两个CIELab空间）之一。 大多数感兴趣的配置文件要么具有可逆转换，要么明确指定两个方向的转换。 如果ICC_ColorSpace对象以需要从PCS转换到配置文件的本机空间的方式使用，并且没有足够的数据来正确执行转换，ICC_ColorSpace对象将在指定类型的颜色空间中生成输出（例如TYPE_RGB，TYPE_CMYK等。），但输出数据的特定颜色值将是不确定的。

ICC_ColorSpace类的详细信息对于简单的applet并不重要，这些applet绘制默认颜色空间或操纵和显示具有已知颜色空间的导入图像。 最多，这样的applet需要通过ColorSpace.getInstance()获得一个默认颜色空间。 （摘自docs.oracle.com） https://docs.oracle.com/javase/7/docs/api/java/awt/color/ICC_ColorSpace.html

Java中的Colorspace转换

颜色空间转换由目标类型控制，用于读取和写入图像。 读取栅格时，不执行颜色空间转换，并忽略任何目标类型。 如果在这种情况下指定了目标类型，则会向任何侦听器发送警告。 写入栅格时，任何目标类型都用于解释频段。 这可能导致写入JFIF或Adobe标头，或者将不同的组件ID写入帧和扫描标头。 如果元数据对象中存在的值与目标类型不匹配，则使用目标类型，并向任何侦听器发送警告。 （摘自docs.oracle.com） https://docs.oracle.com/javase/7/docs/api/javax/imageio/metadata/doc-files/jpeg_metadata.html

有用的链接

看看触摸RGB转换的信息。 Rolf W. Rasmussen对标准化的float / int颜色组件有一些问题：

http://opensource.apple.com/source/gcc3/gcc3-1041/libjava/java/awt/image/ColorModel.java

阅读The Sad Story of PNG Gamma “Correction” （问题是：JPEG和TIFF遭受同样的“疾病”）。

https://hsivonen.fi/png-gamma/

看看SOpost。 有可能为您解决方案：

在Java中，将图像转换为sRGB会使图像太亮

如果在所有尝试后仍然有不一致的颜色，请尝试将图像转换为sRGB配置文件，但不要嵌入它们：

https://imageoptim.com/color-profiles.html

另外，我希望Kenny Hunt的这本书有用 。

…以下代码（在www.physicsforums.com上发布）可让您了解各种RGB的外观：

 import java.awt.*; import javax.swing.*; public class RGB { public static void main(String[] args) { JFrame frame = new JFrame("RGB"); frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); RGBpanel panel = new RGBpanel(); frame.getContentPane().add(panel); frame.pack(); frame.setVisible(true); } } class RGBpanel extends JPanel { public RGBpanel() { setPreferredSize(new Dimension(300,300)); int red = Integer.parseInt(JOptionPane.showInputDialog("Enter red value")); int green = Integer.parseInt(JOptionPane.showInputDialog("Enter green value")); int blue = Integer.parseInt(JOptionPane.showInputDialog("Enter blue value")); Color colour = new Color(red,green,blue); setBackground(colour); } } 

概括

颜色不一致的问题源于颜色配置文件。 尝试为所有图像指定统一的颜色配置文件，无论是手动（在Photoshop中）还是以编程方式（在Java中）。

Answer 4

请参见此处 ： WARNING: Color space tagged as sRGB, without an embedded color profile. Windows and Mac browsers and apps treat the colors randomly. WARNING: Color space tagged as sRGB, without an embedded color profile. Windows and Mac browsers and apps treat the colors randomly.

编辑：根据版本舍入错误和实现差异; 他们根本不是这种形象的情况。 Mac上有一些神奇的function，可以在颜色匹配曲线上使蓝色和绿色更亮。 纠正色彩空间，色彩匹配会给出相同的结果。 我对Andy Fedoroff的回答进行了投票，但我也注意到没有人真正给你一个解决方案……你已经得出结论，Java是正确的。 去吧。 Libjpeg在很长一段时间内没有改变。 它稳定，可以在许多平台和环境中可靠地再现颜色。 未对解码老化的标准jpeg进行重大（以任何方式）改变。

编辑2：尝试创建一个示例，根据您的项目生成与Mac配置文件相同的值。 需要来自Library/ColorSync/Profiles Mac的工厂ICC配置Library/ColorSync/Profiles 。

这就是我在的地方。 以下是应用sRGB ICC v4配置文件的示例。 这在技术上应用sRGB而不是sRGB，但它正在解释这个概念。

 private ICC_Profile cp = ICC_Profile.getInstance("src/test/resources/sRGB_ICC_v4_Appearance.icc"); private ICC_ColorSpace cs = new ICC_ColorSpace(cp); private int[] getRGBUsingImageIO2(File file, int x, int y) throws IOException { BufferedImage image = ImageIO.read(file); ColorConvertOp cco = new ColorConvertOp( cs, null ); BufferedImage result = cco.filter( image, null ); int javaRGB = result.getRGB(x, y); int javaRed = (javaRGB >> 16) & 0xFF; int javaGreen = (javaRGB >> 8) & 0xFF; int javaBlue = (javaRGB >> 0) & 0xFF; return new int[]{javaRed, javaGreen, javaBlue}; } 

图像IO 1：[0,0] = [145,146,164] 
图像IO 2：[0,0] = [145,147,165] 
图像IO 1：[1,0] = [137,138,156] 
图像IO 2：[1,0] = [137,139,157] 
图像IO 1：[2,0] = [148,147,161] 
图像IO 2：[2,0] = [148,148,162] 
图像IO 1：[0,1] = [150,153,168] 
图像IO 2：[0,1] = [150,154,169] 
图像IO 1：[1,1] = [138,141,156] 
图像IO 2：[1,1] = [138,142,157] 
图像IO 1：[2,1] = [145,147,159] 
图像IO 2：[2,1] = [145,148,160] 
图像IO 1：[0,2] = [154,160,172] 
图像IO 2：[0,2] = [154,161,173] 
图像IO 1：[1,2] = [146,152,164] 
图像IO 2：[1,2] = [146,153,165] 
图像IO 1：[2,2] = [144,148,157] 
图像IO 2：[2,2] = [144,149,158] 

你能将你的颜色配置文件提交给你的imageio-test repo吗？