Fee Fladder

Thanks for the uplifting responses :) I think the aiocogeo approach is a good one - having an async tiff reader specifically for COGs. That could have a smaller code/exec...

So I've mumbled up something [over here](https://github.com/feefladder/tiff2) in the past week: - I looked at `aicogeo-rs` and thought it didn't "look enough like image-tiff", making possible integration later more difficult...

ah yes, sort of: The idea was that my crate would be a try-out where the implementation is tested, to be pulled in upstream later and then deprecated. I don't...

That's also why I decided not to build it on top of aiocogeo-rs, because I want to be a (rather big) changelog away from `image-tiff`. If I understand correctly, some...

@kylebarron thanks for the in-depth answers. I've grouped them loosely by topic ### image-tiff bandwidth and crate organization > > What I was currently thinking of is to put all...

> I've made significant progress at https://github.com/developmentseed/async-tiff, and plan to make an initial release within a week or so. So far, reading all tag data (including geospatial tags) seems to...

Is this going off-topic for this crate? Do we want separate async-geotiff and geotiff crates? I did notice that the geotiff crate directly reads in the entire image, whereas I...

My crate [tiff2](https://github.com/feefladder/tiff2) for experimentation on making image-rs/image-tiff async, to be merged into image-tiff whenever. upstream issue: georust/geotiff#13 So asyncness has to "stabilize" in my crate, then pass through geotiff,...

> This will probably have to be built as a GPU-accelerated architecture since the current CPU processing using GDAL is quite slow. On the rust side of things, that would...

I cannot convert to draft, but it is very exploratory/draft