Error out on unsupported predictor instead of decoding incorrectly.

[kevinmehall]

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

[constantinius]

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!

[kevinmehall]

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.