某些图像文件类型是否始终与某些BufferedImage常量类型相对应? [英] Do certain image file types always correspond with certain BufferedImage constant types?

问题描述

其中的 BufferedImage 类Java包含一个getType()方法，该方法返回一个与BufferedImage常量类型变量相关的整数，该变量描述有关图像编码方式的一些信息(您可以查看

The BufferedImage class in Java contains a getType() method which returns an integer correlating with a BufferedImage constant type variable describing some information about how the image is encoded (you can look at the BufferedImage source to determine what number corresponds to what constant type variable). For instance, if it returns the integer corresponding with BufferedImage.TYPE_3BYTE_BGR, then that means that the BufferedImage is an 8-bit RGB image with no alpha and with blue, green, and yellow each being represented by 3 bits.

其中一些图像类型似乎与特定格式的某些属性相关.例如，TYPE_BYTE_INDEXED说它是从"256色6/6/6彩色立方体调色板"创建的.这听起来很像是由256种颜色创建的GIF图像.

Some of these image types seem to correlate with certain properties of a particular format. For instance, TYPE_BYTE_INDEXED says that it is created from "a 256-color 6/6/6 color cube palette". This sounds a lot like GIF images, which are created from 256 colors.

好奇的是，我扫描了硬盘上的几百张照片，并使用ImageIO.read(File file)将它们转换为BufferedImage，然后在它们上调用了BufferedImage.getType().我确定从某些图像类型生成的只有BufferedImage类型.结果如下:

Curious, I scanned several hundred photos on my hard drive and converted each of them to a BufferedImage, using ImageIO.read(File file), then called BufferedImage.getType() on them. I determined that there were only a few BufferedImage types that were generated from certain image types. The results were as follows:

JPG :TYPE_3BYTE_BGR，TYPE_BYTE_GRAY

JPG: TYPE_3BYTE_BGR, TYPE_BYTE_GRAY

PNG :TYPE_3BYTE_BGR，TYPE_BYTE_GRAY，TYPE_4BYTE_BGRA

PNG: TYPE_3BYTE_BGR, TYPE_BYTE_GRAY, TYPE_4BYTE_BGRA

GIF :TYPE_BYTE_INDEXED

GIF: TYPE_BYTE_INDEXED

虽然看起来JPG和PNG都共享一些相似的BufferedImage常量类型，但在我的测试中只有一个PNG导致了TYPE_4BYTE_BGRA，而每个GIF都导致了TYPE_BYTE_INDEXED.

While it looks like both JPGs and PNGs shared some similar BufferedImage constant types, only a PNG in my test resulted in a TYPE_4BYTE_BGRA and every GIF resulted in a TYPE_BYTE_INDEXED.

我对图像格式不太熟悉，的确，我的样本大小并没有那么大.所以我想问一下:假设图像格式正确，某些图像类型是否总是导致某些恒定类型的BufferedImages?举一个具体的例子，正确格式化的GIF图像是否总是与TYPE_BYTE_INDEXED相对应?还是所有正确格式化的图像都可能与所有BufferedImage常量类型相对应?

I'm not too familiar with image formats and it's true that my sample size isn't all that large. So I figured I'd ask: assuming that an image is properly formatted, do certain image types always result in BufferedImages with certain constant types? To provide a specific example, would a properly formatted GIF image always correspond to TYPE_BYTE_INDEXED? Or is it possible for all properly formatted images to correspond with all of the BufferedImage constant types?

推荐答案

[是否]某些图像类型总是导致具有某些常量类型的BufferedImage?

与在您的其他问题中一样； 否，BufferedImage类型和文件格式之间没有直接关系.

As in in your other question; No, there is no direct relationship between the BufferedImage types and file formats.

或者是否所有正确格式化的图像都可以与所有BufferedImage常量类型相对应?

Or is it possible for all properly formatted images to correspond with all of the BufferedImage constant types?

基本上是.当然，如果将彩色图像转换为灰色，则会丢失信息， 如果将每个样本图像中的16位转换为每个样本8位等，则会丢失精度.

Basically, yes. Of course, a color image would lose information if converted to gray, a 16 bit per sample image would lose precision if converted to 8 bits per sample, etc.

但是，不同的文件格式具有不同的像素和颜色存储方式，通常，某些BufferedImage类型更接近地表示文件格式中使用的版式".

However, different file formats have different ways of storing pixels and colors, and usually a certain BufferedImage type more closely represent the "layout" used in the file format.

让我们使用您的GIF示例:

GIF的存储布局"(在应用LZW压缩之前)通常最接近TYPE_BYTE_INDEXED的存储，因此通常是Java中最便宜的转换.对于最多16种颜色的GIF，TYPE_BYTE_BINARY也可以正常工作.而且，始终有可能将GIF解码为TYPE_4BYTE_ABGR或TYPE_INT_ARGB(如果没有透明色，甚至可以解码为TYPE_3BYTE_BGR或TYPE_INT_RGB).

The storage "layout" of a GIF (before applying LZW compression) is normally closest to that of TYPE_BYTE_INDEXED, so that is usually the "cheapest" conversion to do in Java. For GIFs with up to 16 colors, TYPE_BYTE_BINARY would work just as well. And it's always possible for a GIF to be decoded into TYPE_4BYTE_ABGR or TYPE_INT_ARGB (or even TYPE_3BYTE_BGR or TYPE_INT_RGB if no transparent color).

换句话说，图像的类型取决于解码器，在某些情况下(例如

In other words, the type of image depends on the decoder, and in some cases (like for the ImageIO API) the user.

总而言之，您发现，默认情况下，用于ImageIO的GIF插件(GIFImageReader)会将具有16种以上颜色的GIF解码为TYPE_BYTE_INDEXED.使用不同的解码器/框架可能会产生不同的结果.

To summarize, what you have found, is that the GIF plugin for ImageIO (GIFImageReader) by default will decode a GIF with more than 16 colors to TYPE_BYTE_INDEXED. Using a different decoder/framework may yield different results.

一些历史可以启发好奇的读者:

A little bit of history that might enlighten the curious reader:

未建模为与图像格式相对应的BufferedImage的类型.它们被建模为与显示硬件相对应.与显示硬件具有相同像素布局的图像将始终显示得更快.其他布局首先需要进行某种转换.现在，由于现代显示硬件的速度非常快，因此当然不必担心，但是在古代"时代这很重要.

The types of BufferedImages where not modeled to correspond to image formats. They were modeled to correspond to display hardware. An image having the same pixel layout as the display hardware is always going to be faster to display. Other layouts would first need to go through some kind of conversion. Now with modern display hardware being very fast, this is of course less of a concern, but in "ancient" times this was important.

偶然地，许多古老的"图像格式是临时创建的，或者是针对在特定显示硬件上运行的特定应用程序创建的.因此，显示硬件的像素布局经常以文件格式使用.再一次，因为不需要转换，这是实现最快/最简单的事情.

Incidentally, many "ancient" image formats were created ad hoc, or for specific applications running on specific display hardware. Because of this, the pixel layout of the display hardware were often used in the file format. Again, because no conversion was needed, and it was the fastest/simplest thing to implement.

所以，是的，有关系.这不是直接的给定A => B"关系，而是给定A 和 C => B".

So, yes, there is a relationship. It's just not a direct "given A => B" relationship, it's a "given A and C => B".

这篇关于某些图像文件类型是否始终与某些BufferedImage常量类型相对应?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！