In short, using PREDICTOR_FLOATINGPOINT on 32-bit images takes about as little time as using PREDICTOR_NONE, but produces files up to 20% smaller. It would be good to use it on 32-bit floating-point files. However, I can’t be sure whether the PREDICTOR_FLOATINGPOINT findings are valid, because neither GIMP-2.9.6 nor RawTherapee can open that image, so it could be a bug in saving.
I’ve been incorporating floating point TIFF into rawproc, as well as generally more robust file open/save, and I get the same results with this -dev version as @Carmelo_DrRaw gets with PhotoFlow.
Edit: Oh, and it’s probably pertinent to supply my TIFF library version: 4.0.6
The unlikelihood that several other programs would be unable to open a file using something which has been standard for many years means there’s most likely an issue saving using PREDICTOR_FLOATINGPOINT in RawTherapee’s tiff32float branch. @Hombre hinted yesterday that maybe it requires using ADOBE_DEFLATE compression.
I created that image using probably libtiff-4.0.8, though ldd shows RT linked against /usr/lib64/libtiff.so.5 which points to libtiff.so.5.2.6, so… ??? strings /usr/lib64/libtiff.so.5.2.6 shows LIBTIFF, Version 4.0.8
I clearly identified the bug, which is a mismatch of endianess between Exif tags and image data. So if you try with e.g. a Pentax K-3 which has Intel endianess for exif data should work fine. Now I have to fix it.
So, that was with rawproc 0.6.2, release, dynamically links to the system libtiff-4.0.6 thanks to wxWidgets.
I just compiled another dev version with a static link to libtiff-4.0.8, with all external options disabled, LZW opens but Deflate does not - due to no zlib?
