On Sat, Sep 7, 2024, at 17:49, Even Rouault via gdal-dev wrote:
> It could be argued that coding it in C wouldn't be the best idea. I've
> spotted a TIFF Rust library (https://github.com/image-rs/image-tiff) but it
> is functionally limited (at least in terms of supported codecs. didn't check
> thourougly) and also associates the TIFF "object" with a file reader with
> read+seek capabilities, and thus methods like read_chunk()
> (https://github.com/image-rs/image-tiff/blob/6dc7a266d30291db1e706c8133357931f9e2a053/src/decoder/mod.rs#L1012)
> take a mutable self reference, making it incompatible of thread-safety.
I think there are two aspects to this:
- few image Rust libraries are going to be as battle-hardened as libtiff.
People just started working on competing implementations because they had a
need or they wanted to, but didn't implement any advanced features, or they
moved on to other projects. I think tiff, for example, doesn't support writing
tiled images [1]. The API is just what happened to be required, but it can
still change, more easily than that of libtiff [2]
- however, the decoder is generic over the input stream, so it can be used
even today with a pread/mmap wrapper over a reference-counted file handle (you
could point multiple decoders to the same file)
Laurentiu
[1] https://github.com/image-rs/image-tiff/issues/205
[2] the Rust community is more tolerant of breaking changes because the tooling
makes them less of a problem
[3] https://docs.rs/tiff/latest/tiff/decoder/struct.Decoder.html
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
