Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

This GeoTIFF Rust library seems 5-10 times slower than a GeoTIFF Javascript library #5

Open
OTheNonE opened this issue Mar 20, 2023 · 4 comments

Comments

@OTheNonE
Copy link

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:)

@dominikbucher
Copy link
Member

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! 😊

@OTheNonE
Copy link
Author

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?

@dominikbucher
Copy link
Member

You might look at:

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.

@feefladder
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants