java - ImageIO 读取的 RGB 值与其他方法略有不同

Question

我发现我在使用 Java(实际上是 paint.NET)时获得的 RGB 与使用 ImageMagick、Gimp、Python 和 Octave 时不同。最后4个都同意，所以我假设是正确的。

对于这些示例，我使用的是以下测试图像:http://farm3.static.flickr.com/2811/9177301733_9836174725_o.jpg

测试像素x=4144 y=2768

               R    G    B
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://farm3.static.flickr.com/2811/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://farm3.static.flickr.com/2811/9177301733_9836174725_o.jpg").read())

im = Image.open(file)
pix = im.load()
print pix[4144, 2768]

我尝试过使用 this 12monkeys library希望那会解决它，但没有骰子。还有其他想法如何使用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 个(3x3 平方)像素由三种不同工具解码的 RGB 值。如您所见，Python 和 ImageMagick 是一致的。 Java 有时会匹配。我在java不同意的地方放了一个X...:

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 会为某些像素提供不同的值？或者，是否有另一种(快速)使用 native Java 代码生成正确值的方法？

2016 年 9 月 26 日更新:

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

Answer 1

实际上，我想扭转这个问题，并说我很惊讶这么多不同的平台和工具实际上产生了相同的值。 :-)

JPEG 有损

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

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

另一个 excellent answer对一个类似的问题指出“JPEG 标准不要求解码器实现产生逐位相同的输出图像”，并引用 the Wikipedia JPEG entry :

[...] precision requirements for the decoding [...]; the output from the reference algorithm must not exceed:

• a maximum of one bit of difference for each pixel component
• low mean square error over each 8×8-pixel block
• very low mean error over each 8×8-pixel block
• very low mean square error over the whole image
• extremely low mean error over the whole image

(请注意，上面只讨论了引用实现)。

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

色彩空间

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

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

ICC 配置文件和颜色匹配

颜色差异的下一个可能来源是颜色匹配(由颜色匹配模块、CMM 或颜色管理系统、CMS 完成)不是 100% 精确的科学(例如参见 this document on black point compensation 或阅读一些来自 Little CMS blog 的更多技术帖子)。

Mac OS X 上运行的软件很可能使用 Apple 的 CMM，而 Java 始终使用 Little CMS(来自 OpenJDK 7 或 Oracle JDK/JRE 8)，Linux 平台上的大多数软件也可能使用开源Little CMS(根据 Little CMS 主页，“您可以在大多数 Linux 发行版中找到 Little CMS”)。 Windows 上的软件也可能会略有偏差(我无法验证 Paint.Net 是否使用 Little CMS、Windows 的内置 CMM 或其他东西)。当然，使用 Adob​​e 的 CMM(即 Photoshop)也可能会出现偏差。

同样，幸运的是，您测试的许多软件都使用相同的 CMM 或 CMS 引擎，Little CMS ，所以你会再次得到很多相同的结果。但您测试的某些软件似乎使用了不同的 CMM，并且可能是轻微色差的来源。

总结

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

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