ImageIO 读数与其他方法的 RGB 值略有不同

2022-09-01 10:49:41

我发现我在使用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]

我尝试过使用这个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 个(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为某些像素提供不同的值?或者,是否有另一种(快速)方法可以使用本机Java代码生成正确的值?

2016-09-26更新:

我提交了演示此问题的代码,并将其推送到github(imageio-test),以便我可以在不同的计算机上轻松测试它。事实证明,Java在OSX和Ubuntu Linux上都是一致的,但Python,ImageMagick和Octave是不一致的。换句话说,在Linux盒子上,所有工具都彼此一致,因此,我现在认为java一直都是正确的,而其他工具在OSX上给出了不正确的结果!我仍然不明白为什么,我也没有得到任何具体的证据来证明哪些值是正确的,但我正在得到一些东西......


答案 1

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

JPEG 是有损的

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

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

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

[...]de编码的精度要求[...];参考算法的输出不得超过:

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

(请注意,上面仅讨论参考实现)。

但是,运气好的话,似乎您的所有软件/工具实际上最终都使用(某个版本的)libjpeg。因为它们都使用 libjpeg,所以您看到的差异的来源很可能与 JPEG 解码无关。

色彩空间

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

似乎您正在使用的所有软件实际上都在sRGB色彩空间中显示RGB值。这可能是主流计算中使用的最标准、使用最广泛的色彩空间,所以这毕竟不足为奇。由于色彩空间始终是 sRGB,因此您看到的差异的来源很可能不是色彩空间。

ICC 配置文件和颜色匹配

颜色差异的下一个可能来源是颜色匹配(由颜色匹配模块,CMM或颜色管理系统CMS完成)不是100%精确的科学(例如,请参阅有关黑点补偿的文档或阅读Little CMS博客中的一些技术性更强的文章)。

最有可能在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或其他东西)。当然,使用Adobe的CMM(即。Photoshop)也可能会偏离。

同样,运气好的话,您测试的许多软件都使用相同的CMM或CMS引擎,Little CMS,因此您将再次获得很多相同的结果。但似乎您测试的一些软件使用不同的CMM,并且可能是轻微颜色差异的来源。

总结

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

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


答案 2

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

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

在 Mac 上,如果您通过 或 via 安装,那么您会注意到它们使用的是 libjpeg v9 (),而 Java 7 和 8 JDK 附带了自己的 libjpeg 捆绑包,这是完全不同的。jpeghomebrewPillowpiplibjpeg.9.dylib

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 代码绑定到其他应用程序正在使用的相同版本 - 即:从 Java 应用程序中加载并使用它。我不是100%确定你会怎么做。libjpeg.9.dylib
  3. 重新编译你的JDK以使用正确的JDK - 这个答案引用的一个选项是使用openjdk并针对所需的libjpeg版本进行编译,这听起来更容易实现。

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

注意:
我肯定会投票@haraldk的答案,因为他的结论几乎相同。

我还尝试使用不同的icc配置文件,他们给出了完全不同的答案。因此,值得对此保持警惕。

我只是想添加一个答案,更加强调libjpeg的实现,因为我相信这就是在你的特定实例中吸引你的原因。

更新

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

实际上,我认为这更有可能是这里的答案。