TIFFPackBitsCompressor - NPE？
TIFFPackBitsCompressor - NPE?
我正在使用 com.sun.media.imageioimpl.plugins.tiff.TIFFPackBitsCompressor 尝试对我使用 PackBits 的 tiff 字节数组进行编码。我不熟悉这个 class，也没有找到很多关于如何使用它的例子。但是，在遵循 javadoc 时，每次尝试对数据进行编码时，我都会遇到 NPE。据我所知，我的 none 值为空。此时我已经用多个值尝试了这些测试，但下面是我最近的迭代：
TIFFPackBitsCompressor pack = new TIFFPackBitsCompressor();
//bImageFromConvert is a 16-bit BufferedImage with all desired data.
short[] bufferHolder = ((DataBufferUShort) bImageFromConvert.getRaster().getDataBuffer()).getData();
//Since bImageFromConvert is 16-bits, the short array isn't the right length.
//The below conversion handles tihs issue
byte[] byteBuffer = convertShortToByte(bufferHolder);
//I'm not entirely sure what this int[] in the parameters should be.
//For now, it is a test int[] array containing all 1s
int[] testint = new int[byteBuffer.length];
Arrays.fill(testint, 1);
//0 offset. dimWidth = 1760, dimHeight = 2140. Not sure what that last param is supposed to be in layman's terms.
//npe thrown at this line.
int testOut = pack.encode(byteBuffer, 0, dimWidth, dimHeight, testint, 1);
有人知道发生了什么事吗？另外，如果可用的话，有人知道在 java 程序中使用 PackBits 对我的 TIFF 文件进行编码的更好方法吗？
如果有什么可以让我的问题更清楚，请告诉我。
谢谢！
如评论中所述，您不应该直接使用 TIFFPackBitsCompressor，而是在您指定 [=39= 时由 JAI ImageIO TIFF 插件（TIFFImageWriter）在内部使用它] 作为 ImageWriteParam 中的压缩类型。如果您首先将其转换为 TIFFImageWriteParam，您也可以在参数中传递一个压缩器实例，但这对于插件不知道的自定义压缩更有用。
另请注意，压缩器只会写入 PackBits 压缩像素数据，它不会创建完整的 TIFF 文件。
写入 PackBits 压缩 TIFF 文件的正常方法是：
BufferedImage image = ...; // Your input image
ImageWriter writer = ImageIO.getImageWritersByFormatName("TIFF").next(); // Assuming a TIFF plugin is installed
try (ImageOutputStream out = ImageIO.createImageOutputStream(...)) { // Your output file or stream
writer.setOutput(out);
ImageWriteParam param = writer.getDefaultWriteParam();
param.setCompressionMode(ImageWriteParam.MODE_EXPLICIT);
param.setCompressionType("PackBits");
writer.write(null, new IIOImage(image, null, null), param);
}
writer.dispose();
以上代码在使用 JAI ImageIO 和 TwelveMonkeys ImageIO TIFF 插件时应该可以正常工作。
PS：PackBits is a very simple compression algorithm based on run-length encoding 个 字节 数据。由于 16 位数据在单个样本的高字节和低字节之间可能变化很大，因此 PackBits 通常不是压缩此类数据的好选择。
如我的评论所述，使用完全随机的值我得到了以下结果：
Compression | File size
-----------------|-----------------
None | 7 533 680 bytes
PackBits | 7 593 551 bytes
LZW w/predictor | 10 318 091 bytes
ZLib w/predictor | 10 318 444 bytes
这并不奇怪，因为完全随机的数据通常不可压缩（不会丢失数据）。对于线性渐变，它可能更类似于 "photographic" 图像数据，我得到了完全不同的结果：
Compression | File size
-----------------|-----------------
None | 7 533 680 bytes
PackBits | 7 588 779 bytes
LZW w/predictor | 200 716 bytes
ZLib w/predictor | 144 136 bytes
如您所见，此处 LZW 和 Deflate/Zlib 算法（带有预测器步骤）的性能要好得多。对于 "real" 数据，噪声可能更多，因此您的结果可能介于这两个极端之间。
我正在使用 com.sun.media.imageioimpl.plugins.tiff.TIFFPackBitsCompressor 尝试对我使用 PackBits 的 tiff 字节数组进行编码。我不熟悉这个 class，也没有找到很多关于如何使用它的例子。但是，在遵循 javadoc 时，每次尝试对数据进行编码时，我都会遇到 NPE。据我所知，我的 none 值为空。此时我已经用多个值尝试了这些测试，但下面是我最近的迭代：
TIFFPackBitsCompressor pack = new TIFFPackBitsCompressor();
//bImageFromConvert is a 16-bit BufferedImage with all desired data.
short[] bufferHolder = ((DataBufferUShort) bImageFromConvert.getRaster().getDataBuffer()).getData();
//Since bImageFromConvert is 16-bits, the short array isn't the right length.
//The below conversion handles tihs issue
byte[] byteBuffer = convertShortToByte(bufferHolder);
//I'm not entirely sure what this int[] in the parameters should be.
//For now, it is a test int[] array containing all 1s
int[] testint = new int[byteBuffer.length];
Arrays.fill(testint, 1);
//0 offset. dimWidth = 1760, dimHeight = 2140. Not sure what that last param is supposed to be in layman's terms.
//npe thrown at this line.
int testOut = pack.encode(byteBuffer, 0, dimWidth, dimHeight, testint, 1);
有人知道发生了什么事吗？另外，如果可用的话，有人知道在 java 程序中使用 PackBits 对我的 TIFF 文件进行编码的更好方法吗？
如果有什么可以让我的问题更清楚，请告诉我。
谢谢！
如评论中所述，您不应该直接使用 TIFFPackBitsCompressor，而是在您指定 [=39= 时由 JAI ImageIO TIFF 插件（TIFFImageWriter）在内部使用它] 作为 ImageWriteParam 中的压缩类型。如果您首先将其转换为 TIFFImageWriteParam，您也可以在参数中传递一个压缩器实例，但这对于插件不知道的自定义压缩更有用。
另请注意，压缩器只会写入 PackBits 压缩像素数据，它不会创建完整的 TIFF 文件。
写入 PackBits 压缩 TIFF 文件的正常方法是：
BufferedImage image = ...; // Your input image
ImageWriter writer = ImageIO.getImageWritersByFormatName("TIFF").next(); // Assuming a TIFF plugin is installed
try (ImageOutputStream out = ImageIO.createImageOutputStream(...)) { // Your output file or stream
writer.setOutput(out);
ImageWriteParam param = writer.getDefaultWriteParam();
param.setCompressionMode(ImageWriteParam.MODE_EXPLICIT);
param.setCompressionType("PackBits");
writer.write(null, new IIOImage(image, null, null), param);
}
writer.dispose();
以上代码在使用 JAI ImageIO 和 TwelveMonkeys ImageIO TIFF 插件时应该可以正常工作。
PS：PackBits is a very simple compression algorithm based on run-length encoding 个 字节 数据。由于 16 位数据在单个样本的高字节和低字节之间可能变化很大，因此 PackBits 通常不是压缩此类数据的好选择。
如我的评论所述，使用完全随机的值我得到了以下结果：
Compression | File size
-----------------|-----------------
None | 7 533 680 bytes
PackBits | 7 593 551 bytes
LZW w/predictor | 10 318 091 bytes
ZLib w/predictor | 10 318 444 bytes
这并不奇怪，因为完全随机的数据通常不可压缩（不会丢失数据）。对于线性渐变，它可能更类似于 "photographic" 图像数据，我得到了完全不同的结果：
Compression | File size
-----------------|-----------------
None | 7 533 680 bytes
PackBits | 7 588 779 bytes
LZW w/predictor | 200 716 bytes
ZLib w/predictor | 144 136 bytes
如您所见，此处 LZW 和 Deflate/Zlib 算法（带有预测器步骤）的性能要好得多。对于 "real" 数据，噪声可能更多，因此您的结果可能介于这两个极端之间。