Admitting I have not read through all the other replies, just wanting to make come comments.
In general it would be ideal to have a C++ library with C API interface. However, converting the codebase to C++ would probably mean several years of instabilities.
Side remark; with implementation in C, I know I would never want to contribute to it, with C++ I might.
Having a direct C++ API for the actual implementation is not feasible as there is no common C++ ABI. So C API it is. But it could be made better! How come I have to know in advance what type of variable certain tag value must be read into, if the type of the value is encoded in the TIFF file itself in the first place? For starters, no typeless ... functions please!
For C++ one can in principle also provide a header-only C++ API on top of the C API.
As for building it, CMake seems to be the best at the moment for cross-platform development. One moment, checking... yes, libtiff is built with CMake, so everything good!
Just my 2 euro cents Paavo On Mon, 29 Dec 2025, Roger Leigh via Tiff wrote:
Date: Mon, 29 Dec 2025 11:08:45 +0000 From: Roger Leigh via Tiff <[email protected]> Reply-To: Roger Leigh <[email protected]> To: Roger Leigh via Tiff <[email protected]> Subject: [Tiff] Proposal for conversion of the codebase to C++ while retaining the existing C API 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
_______________________________________________ Tiff mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/tiff
