geotiff.js
geotiff.js copied to clipboard
Error out on unsupported predictor instead of decoding incorrectly.
Files using the floating-point predictor (GDAL's -co PREDICTOR=3
) were silently decoding corrupt data because the algorithm implemented corresponds to predictor 2.
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!
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.