Open Silence-Soul opened 5 years ago
Extra information about how to reproduce the bug:
val tiff =
GeoTiffReader
.readSingleband("/.../18FEB28040147-P2AS-058185565030_01_P001.TIF", streaming = true)
//> java.lang.IllegalArgumentException: Negative position
// at sun.nio.ch.FileChannelImpl.map(FileChannelImpl.java:863)
// at geotrellis.util.FileRangeReader.readClippedRange(FileRangeReader.scala:38)
// at geotrellis.util.RangeReader$class.readRange(RangeReader.scala:42)
// at geotrellis.util.FileRangeReader.readRange(FileRangeReader.scala:31)
// at geotrellis.util.StreamingByteReader.readChunk(StreamingByteReader.scala:99)
// at geotrellis.util.StreamingByteReader.ensureChunk(StreamingByteReader.scala:110)
// at geotrellis.util.StreamingByteReader.getShort(StreamingByteReader.scala:138)
// at geotrellis.raster.io.geotiff.reader.TiffTagsReader$.read(TiffTagsReader.scala:67)
// at geotrellis.raster.io.geotiff.reader.GeoTiffReader$.readGeoTiffInfo(GeoTiffReader.scala:359)
// at geotrellis.raster.io.geotiff.reader.GeoTiffReader$.readSingleband(GeoTiffReader.scala:118)
// at geotrellis.raster.io.geotiff.reader.GeoTiffReader$.readSingleband(GeoTiffReader.scala:70)
// ... 40 elided
There is smth wrong with how the metadata is constructed and we don't support this kind of structure. The tiff can be easily fixed by the following GDAL command:
gdal_translate 18FEB28040147-P2AS-058185565030_01_P001.TIF 18FEB28040147-P2AS-058185565030_01_P001_TST.TIF
@pomadchin Hey I fixed the TIFF file with GDAL command
gdal_translate 18FEB28040147-P2AS-058185565030_01_P001.TIF 18FEB28040147-P2AS-058185565030_01_P001-1.TIF
,
when I read the file with
GeoTiffReader.readSingleband("d:\\TIFF文件\\058185565030_01\\058185565030_01_P001_PAN\\18FEB28040147-P2AS-058185565030_01_P001-1.TIF")
the file size is 2.07 GB (2,226,131,844 bytes)
val size = f.length.toInt
size is negative number
Some further investigations that were posted by @Silence-Soul in #3066:
Hey, @pomadchin #3065 The reason maybe when the offset is read from the IFH of the TIFF. Bytes 4-7 are the addresses of the first offset. Below is the hexadecimal content of the TIFF file. Bytes 4-7 are b0, 23, af, 84.
But the decimal value obtained during the debugging negative number. The decimal: -80, 35, -81, -124
byte is 8 bits and int is 32 bits, when the byte may be converted to int or byte and int type operation, it will expand the byte memory high bit complement 1 (that is, by sign bit complement) to 32 bits.
So byte & 0xff
0xff can set the high 24 bits to 0, and the lower 8 bits remain unchanged, ensure the consistency of the binary data.
String path ="d:\\tmp\\18FEB28040147-P2AS-058185565030_01_P001.TIF";
FileInputStream in = new FileInputStream(path);
DataInputStream din = new DataInputStream(in);
byte[] bytes = new byte[10];
din.read(bytes, 0, 8);
for (byte b: bytes){
String str1 = Integer.toHexString(b);
System.out.print(str1);
System.out.print("--------");
System.out.print("HEX:"+Integer.parseUnsignedInt(str1, 16));
System.out.print(" ");
String str2 = Integer.toHexString((b & 0xff) + 256).substring(1);
System.out.print(str2);
System.out.print("--------");
System.out.println("HEX:"+Integer.parseUnsignedInt(str2, 16));
}
At first, I used GT 2.1.0, and the files could not be ingested RDD Now it is replaced with the GT 2.3.1. But it failed In both versions, the error message is the same. The following is the error log messages and pom.xml
tiff 文件
ERROR:
POM.XML