How to go about writing tiffs?

[feefladder]

Big change, but it would at some point also be useful to be able to write tiffs/cogs. I suppose this is not a design goal of this crate (as it says "reader" in readme)? However, would people here be open for abstractions/api that allow building a writer on top of this crate? I did think about encoding support in tiff2, (especially the entry enum I thought could help) so there's two options:

1. build a writer on top of async-tiff - needs some low-ish access to structs.
2. "revive" tiff2, now that it's also special because it supports encoding - harmonize decoding api with async-tiff for drop-in replacement

[kylebarron]

I'm not interested in adding write support to this crate, at least until read support is stable, well-tested, performant, etc.

Writing tiffs is much harder than reading, especially if you plan to also support overviews, COG metadata, etc.

[weiji14]

I think we're trying to keep async-tiff scoped to generic TIFFs only (even though there are geo-specific features right now, they will slowly go away after #100 is implemented). And agree that the focus should be on read/decoding support first.

For writing COGs specifically, we could perhaps put that effort into georust/geotiff#16?

[feefladder]

I'm not interested in adding write support to this crate, at least until read support is stable, well-tested, performant, etc.

Understood. But then more like a future ecosystem-level question, the place for an async generic tiff writer would be here? or a supplementary crate? - or better, do 1. I fork or 2. build on top (separate crate) to start experimenting sometime in the future? On second thought, I think COG writing is quite more specific and demanding than "regular" tiff writing due to the necessary planning involved, so then separate crate may be better.

Writing tiffs is much harder than reading, especially if you plan to also support overviews, COG metadata, etc.

and especially the planning needed for COGs, which I think makes it quite different from "traditional" writers that can write just anywhere in the file. -this needs a low-level (generic) api/abstraction.

I just realized some time ago that an uncompressed cog is actually rather deterministic and even overviews can be written out-of-order from only the full-res image -once CRS and full image width is known.

but for compressed images (which is obviously better), the variable compression rates of different tiles (and only fully tiles are compressed) make that difficult. So writing a compressed cog (as far as I could think of) has 2 steps: making overviews (out-of-order and compressing them into a nice, compressed cog (in-order).

What I think would be possible for COGs is something like:

1. how much space are you encoded? recursive, for IFD and (tile) data that is something like Enum EncodedSize{Unknown, UpperBound(usize), Exact(usize}}
2. then have some sort of "planner" that knows the sizes, corresponding data and status and where to write it to

but yeah, then again there's a question of what abstractions to make