geotiff.js icon indicating copy to clipboard operation
geotiff.js copied to clipboard

Error out on unsupported predictor instead of decoding incorrectly.

Open kevinmehall opened this issue 7 years ago • 2 comments

Files using the floating-point predictor (GDAL's -co PREDICTOR=3) were silently decoding corrupt data because the algorithm implemented corresponds to predictor 2.

kevinmehall avatar Jun 22 '17 18:06 kevinmehall

Hi @kevinmehall Actually, PREDICTOR=3 is supported (AFAIK, the mechanism is the same as with PREDICTOR=2, just with floating point arithmetic instead of the integer one), thus the check predictor !== 1. If you say that corrupted data is read there must be something else that is wrong, as far as I can tell. Can you make your test file and a sample code available to reproduce the bug?

Thanks for your contribution anyways!

constantinius avatar Jun 23 '17 11:06 constantinius

Predictors 2 and 3 are not the same. The floating point predictor 3 rearranges the bytes to take advantage of patterns in the IEEE754 floating point representation, and then performs byte-level differencing. See Technical Note 3, page 3 and the libtiff implementation.

However, I've also discovered different data corruption when decoding float32 data with predictor=2 with this library, so I've opened #28 with a test case.

kevinmehall avatar Jun 23 '17 17:06 kevinmehall