This GeoTIFF Rust library seems 5-10 times slower than a GeoTIFF Javascript library
I have tried this library for reading elevation data of TIFF-files with size of 1,6GB. My experience with this library is that it is around 5-10 times slower than the Javascript library https://github.com/geotiffjs/geotiff.js/. Do you have any comments on this? Is this believable or is there rather an error on how i use this Rust library? I have not made any concrete benchmarks yet, but if you like, i could try to do a benchmark on the two and share the code:)
It probably depends on the use case, but it might well be for large TIFFs, as this library was not optimized towards that use case. Would be happy to see the benchmarks if you do it, but please also note that this library is "stuck" at version 0.0.1, meaning that whatever is contained in the repository is likely unfinished and unoptimized. If you want to help improving it, feel free to make a PR! 😊
Okay, that explains alot, then i can start scratching my head a little less around this topic:). And off topic, now when you're here, do you know any other Rust library that can read large TIFFs with the "true speed" of a low-level language? The Javascript library is just little too slow, and therefore i was hoping that Rust together with a library could do this task fast enough for my likings. I tried GDAL, but could not make it work because of errors with the gdal-sys library... But do you know if it would be faster than GeoTIFF and maybe also the Javascript library?
You might look at:
- https://github.com/image-rs/image-tiff (this is not specifically about GeoTIFFs, but just TIFFs in general)
- https://github.com/jblindsay/whitebox-tools/blob/master/whitebox-tools-app/src/tools/image_analysis/mosaic.rs (this is not specifically about GeoTIFFs either, but about creating mosaics (e.g., https://support.esri.com/en-us/gis-dictionary/mosaic) - it should be able to read GeoTIFFs, though)
I don't know how "fast" they are, though. On the note of GDAL, that's likely the most performant and complete currently, but setting it up is a mess... If you have no restrictions to use Rust or JS, you might install it via Python / Anaconda, or use https://trac.osgeo.org/osgeo4w/wiki to install it alongside QGIS or such.
Seems like it is beause it immediately reads in all offset tags, with call chaing as I said here: The call chain that slows execution is: decoder.next_image()->tag_reader.find_tag(tag)->entry.clone().val()->case 4 entry.decode_offset() where decode_offset possibly goes out of the currently read buffer.