我发现在使用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有时匹配。我把一个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代码生成正确的值?
我提交了演示此问题的代码并将其推送到github(imageio-test),以便我可以在不同的计算机上轻松测试它。事实证明,Java在OSX和Ubuntu Linux上都是一致的,但是Python,ImageMagick和Octave是不一致的。换句话说,在Linux机器上,所有工具都相互认同,因此,我现在认为java一直都是正确的,而且它是在OSX上提供错误结果的其他工具!我仍然不明白为什么,我还没有得到任何具体的证据证明哪些价值观是正确的,但我到了某个地方......
答案 0 :(得分:19)
实际上,我想解决这个问题,并说我很惊讶这么多不同的平台和工具实际上产生了相同的价值。 : - )
首先,JPEG是一种有损图像压缩方法。这意味着无法再现原始的确切数据。或者,如果您愿意,几个不同的像素值可能在某种程度上都是“正确的”。
为什么并非所有JPEG软件从同一源文件生成完全相同的值的技术原因通常是值的不同舍入/钳位,或浮点运算的整数近似以获得更好的性能。例如,其他变化可能源于应用于恢复二次采样的色度值的不同插值算法(即,更平滑的图像可能看起来更令人愉悦,但不一定更正确)。
类似问题的另一个excellent answer指出“JPEG标准不要求解码器实现产生逐位相同的输出图像”,并引用the Wikipedia JPEG entry :
[...] de 编码的精度要求[...];参考算法的输出不得超过:
- 每个像素组件最多有一位差异
- 每个8×8像素块的低均方误差
- 每个8×8像素块的平均误差非常低
- 整个图像的均方误差非常低
- 整个图像的平均误差极低
(请注意,上面仅讨论了参考实现)。
然而,幸运的是,似乎所有的软件/工具实际上都在使用(某些版本的)libjpeg。因为它们都使用libjpeg,所以你看到的差异来源很可能与JPEG解码无关。
即使您的所有软件都使用RGB值将JPEG文件转换为表示形式,它们用于此表示的颜色空间也可能存在差异。
您使用的所有软件似乎都会在sRGB color space中显示RGB值。这可能是主流计算中使用的最标准和最广泛使用的色彩空间,所以这并不奇怪。由于色彩空间始终是sRGB,因此您看到的差异来源很可能不是色彩空间。
下一个可能的色差来源是色彩匹配(由色彩匹配模块,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或其他东西)。当然,使用Adobe的CMM(即Photoshop)也可能会有所偏差。
再说一次,幸运的是,您测试的很多软件都使用相同的CMM或CMS引擎Little CMS,因此您将获得大量相同的结果。但似乎您测试的某些软件使用不同的CMM,并且可能是轻微颜色差异的来源。
您看到的不同像素值都是“正确的”。差异源于软件中不同的实现或算法的近似,但这并不一定意味着一个值是正确的而其他值是正确的错。
PS:如果您需要在多个平台上重现完全相同的值,请在所有平台上使用相同的工具堆栈/相同算法。
答案 1 :(得分:8)
根据我的评论,您用来检索像素颜色值的各种应用程序/库之间的主要区别在于它们全部使用不同版本的libjpeg - 至少在Mac OSX。
当您将Github项目签出到某些版本的Ubuntu上时,您会发现所有值都报告相同。在这些情况下,python ImageMagick和Java JDK / JRE使用相同的libjpeg实现。
在Mac上,如果您通过jpeg
或homebrew
通过Pillow
安装了pip
,那么您会注意到他们正在使用libjpeg v9 (libjpeg.9.dylib
),而Java 7和8 JDK附带了他们自己的libjpeg捆绑,它们完全不同。
Octave lists its jpeg dependencies为libjpeg8-dev
。
GIMP,Inkscape,Scribus等也捆绑了自己的。就我而言,GIMP捆绑了与python和ImageMagick相同的版本,这将解释类似的值(即:/Applications/GIMP.app/Contents/Resources/lib/libjpeg.9.dylib
)
如果您想保证各个应用的价值相同,您可以选择:
libjpeg.9.dylib
并使用Java应用程序中的代码。我不是100%确定你是怎么做到的。我承认选项2和3是选项1的更难的版本!
注意:强>
我绝对会对@haraldk的回答进行投票,因为他的结论几乎是一样的。
我也玩过使用不同的icc配置文件,他们给出了完全不同的答案。所以值得警惕。
我只是想添加一个更加强调libjpeg实现的答案,因为我相信这就是你在特定实例中捕捉到的东西。
实际上,在@ haraldk的答案中还有另一个主要区别,即CMM和Little CMS之间的差异。正如他所说:Java使用Little CMS,which is also used by Ubuntu
我实际上认为这更有可能成为答案。
答案 2 :(得分:6)
颜色一致性和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绘制默认颜色空间或操纵和显示具有已知颜色空间的导入图像。最多,此类小程序需要通过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/
看看S.O.帖子。有适合您的解决方案:
In Java converting an image to sRGB makes the image too bright
如果在所有尝试后仍然有不一致的颜色,请尝试将图像转换为sRGB配置文件,但不要嵌入它们:
https://imageoptim.com/color-profiles.html
另外,我希望肯尼·亨特的这本书有用。
...以下代码(发布于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)。
答案 3 :(得分:4)
请参阅here:WARNING: Color space tagged as sRGB, without an embedded color profile. Windows and Mac browsers and apps treat the colors randomly.
编辑:根据版本舍入错误和实现差异;他们根本不是这种形象的情况。 Mac上有一些神奇的功能,可以在颜色匹配曲线上使蓝色和绿色更亮。纠正色彩空间,色彩匹配会给出相同的结果。我对Andy Fedoroff的回答进行了投票,但我也注意到没有人真正给你一个解决方案......你得出的结论是Java是正确的。去吧。 Libjpeg在很长一段时间内没有改变。它稳定,可以在许多平台和环境中可靠地再现颜色。未对解码老化的标准jpeg进行重大(以任何方式)更改。
编辑2:尝试创建一个示例,根据您的项目生成与Mac配置文件相同的值。需要来自Library/ColorSync/Profiles
的Mac的工厂ICC配置文件。
这是我在的地方。以下是应用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};
}
Image IO 1 : [0, 0] = [145, 146, 164] Image IO 2 : [0, 0] = [145, 147, 165] Image IO 1 : [1, 0] = [137, 138, 156] Image IO 2 : [1, 0] = [137, 139, 157] Image IO 1 : [2, 0] = [148, 147, 161] Image IO 2 : [2, 0] = [148, 148, 162] Image IO 1 : [0, 1] = [150, 153, 168] Image IO 2 : [0, 1] = [150, 154, 169] Image IO 1 : [1, 1] = [138, 141, 156] Image IO 2 : [1, 1] = [138, 142, 157] Image IO 1 : [2, 1] = [145, 147, 159] Image IO 2 : [2, 1] = [145, 148, 160] Image IO 1 : [0, 2] = [154, 160, 172] Image IO 2 : [0, 2] = [154, 161, 173] Image IO 1 : [1, 2] = [146, 152, 164] Image IO 2 : [1, 2] = [146, 153, 165] Image IO 1 : [2, 2] = [144, 148, 157] Image IO 2 : [2, 2] = [144, 149, 158]
你能将你的颜色配置文件提交给你的imageio-test repo吗?