Various changes. Not ready for merging.

[peterbraden]

This isn't ready for merging, but as I'm about to abandon it, and it's 90% of the way towards something useful I thought I'd leave it here so perhaps someone else can pick it up if it helps them.

• Adds support for Tiled images.
• Adds LZW compression support.
• Adds support for floating point data (changed the signature of the api to use f64, even for integer data)

Unfortunately the image I was hoping to decode uses the Floating point horizontal differencing. predictor which I cannot find documentation on anywhere (seems to be proprietary Adobe standard and the only implementation I could find is https://gitlab.com/libtiff/libtiff/-/blob/master/libtiff/tif_predict.c

This seems to be a dealbreaker, so I'm giving up.

[dominikbucher]

Nice, thanks a lot for the pull request, I didn't realize someone was continuing to work on it! As you might have guessed I'm also not so active in working on the library, but hopefully in August things should get a bit more calm. I'll make a note and take a look at it then!

[Farkal]

Why not use https://github.com/image-rs/image-tiff ? They already have implemented the compression and the support for f64. I am working on a geotiff implementation using this lib and asked for some changes to make the integration easier: image-rs/image-tiff#47

[jblindsay]

I've written a working GeoTIFF reader/writer into WhiteboxTools here:

https://github.com/jblindsay/whitebox-tools
https://github.com/jblindsay/whitebox-tools/tree/master/src/raster/geotiff

It works okay but it is pretty deeply embedded into the WhiteboxTools project and may be hard to extract. My coding style is also quite unidiomatic. It does however handle BigTIFFs and can read/write DEFLATE compressed files. I'm having problems with the LZW decompression though. I'm not going to lie, the GeoTIFF file format is one of my least favourite things in this world. It is so needlessly complex and infinitely flexible.

[Farkal]

Waow great work ! But 4785 lines of Rust in a single file ? I will take your tags for my fork and check your code for the big tiff impl of image-tiff thx !

[jblindsay]

Yes, this is a crazy file for sure. My interest in WBT is in creating useful spatial analysis tool but I need to have the groundwork of reading/writing various spatial file formats as well--you folks may also be interested in my Shapefile reader/writer. The GeoTIFF in particular is a mess of code because it has grown so organically. I just find that GeoTIFF is a particularly complex format. Also, this GeoTIFF reader/writer was one of the first things that I had ever developed in Rust, since it was a basic part of the WBT platform needed from the start. It is far from idiomatic because I didn't know the language very well at the time. Nonetheless, the code works. In fact, this weekend, I added support for reading LZW as well. I'm working on adding support for predictor=3 (floating point) as well.

[Farkal]

Yeah but why you don't use and improve image-tiff lib ? I am pushing bigtiff decoding and some other features to the lib (floating point support, custom tags...). It would simplify your lib and you would benefit from other peoples improvements and bug-fix.

I don't understand why you don't like the geotiff format, at first it seems complex but when you understand the design of tiff files it's pretty simple and very efficient (for cloud usage with http range request for example). Here are some scheme i made about the tiff design: cogeotiff/cog-spec#6
I tried to design my own format with json headers (packed with flexbuffer) but when you have to deal with hight resolution images i came back to the tiff design (you loose lot of space for your data even when you pack it, the tiff entry are the best choice to have juste the right space for your data and be able to decode the ifd without having to decode all the tags). When you have 10gb files and you only one some little part of your file i don't know better format than tiff.

[ruffson]

I also attempted to parse geo data from geotiffs on top of the image-tiff package here but will move any actual parsing of geo stuff out into a seperate crate as suggested by the maintainer.

And I think this is the way this should be tackled:

1. There is one library that knows how to deal with TIFF images and can decode and encode them. It allows to read out all tags and makes these available to outside functionality.
2. There should be a library that reads out the important tiff tags and parses the data into specific GEO types. Which then can be used by other geo libs of e.g. this organization.

What is happening right now that the geo people seem to implement TIFF features and the image people implement geo features. This could be consolidated to use the competences of each field better. I for my part are neither a member of the image or geo community, I just happen to be working on a project that needs both, so cannot offer much expertise myself. I just wish we could take an attempt at a more united effort.