Hi folks, I mentioned this as a possibility during discussion in mid December, but I’ve been spending some time thinking about this over the last couple of weeks, and have taken the time to explore some of the details and write them up. There’s far too much for an email, so I’ve written up a detailed proposal (with some help from Claude Opus 4.5 for exploring the codebases in detail) and put it here: https://gitlab.com/libtiff/libtiff/-/issues/771
As a very brief bit of context and summary. I’ve long been unsatisfied with the base C API of libtiff. It’s unsafe, doesn’t support multi-threading well, is hard to use correctly, is stateful where it doesn’t need to be, and has inconsistent and hard to use error handling. Some alternatives for comparison: OME Files TIFF wrapper (by me): https://gitlab.com/codelibre/ome/ome-files-cpp/-/tree/master/lib/ome/files/tiff?ref_type=heads A set of C++ wrapper classes over libtiff’s C API. Adds compile-time type-safe field and pixel data access, supports multiple open directories (with limitations due to the libtiff API). Libertiff (by Even) https://github.com/libertiff/libertiff/tree/master Header-only, more modern and cleaner than OME Files TIFF wrappers, but exposes less functionality overall. But the interface is very clean, and very well done. Bio-Formats TIFF (by Melissa Linkert) https://github.com/ome/bioformats/tree/develop/components/formats-bsd/src/loci/formats/tiff Java implementation with a lot of features and a lot of performance optimisations. The proposal includes elements from all three of these implementations, and is really asking the question: what would libtiff look like if we implemented it wholly in C++, but also used extern "C” linkage to completely retain the C API and ABI as they are today. I think it could result in a dramatic improvement in the quality of implementation and its usability and performance, and open up libtiff to uses it currently can’t meet. But it’s clearly a large change to make. However, from the above examples, it’s something we’ve actually already done several times over independently, so it’s not in any way new, it would largely be a repeat of what we’ve already done but this time working within libtiff rather than trying to work around its limited C API. The above three implementations are in production use, some for well over a decade, so are not untested or unsafe—all of the design proposals have been well proven. Anyway, I’d be grateful for any feedback after you’ve looked over the linked proposal. It’s written as a plan but it’s really just a series of proposed ideas. This is trying to look at the future of libtiff, and how we can take it forward while also keeping it fully usable and stable for its existing user base. Kind regards, Roger _______________________________________________ Tiff mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/tiff
