2020.12.11 15:22 "[Tiff] SIGSEGV within TIFFGetField()", by OnlineCop

2020.12.11 20:53 "Re: [Tiff] SIGSEGV within TIFFGetField()", by Roger Leigh

Yes, in my code all custom tags are read in by the same line, and this has worked fine so far. But you have to know which tags are custom and which are not, non-custom ASCII tags require a 3-argument call and an extra strlen().

I’m not suggesting you should use this directly, but it might be useful for inspiration:

Field access via templated proxy: https://gitlab.com/codelibre/ome/ome-files-cpp/-/blob/master/lib/ome/files/tiff/Field.h

Tag enums and type mapping: https://gitlab.com/codelibre/ome/ome-files-cpp/-/blob/master/lib/ome/files/tiff/Tags.h

Custom TIFF tag usage: https://gitlab.com/codelibre/ome/ome-files-cpp/-/blob/master/lib/ome/files/tiff/ImageJMetadata.cpp#L68

In hindsight, I’m not happy with all of the design choices made here. Some of the ugliness is trying to wrap the libtiff API in a type-safe manner (which it does achieve). It’s extensible for arbitrary custom user types (just add additional enums and type mappings as for the ImageJ example above).

If there is interest in working on a better C++ libtiff wrapper for direct inclusion in libtiff git, I would certainly be happy to participate. The above TIFF wrapper classes referenced above are all open source, and were developed with a specific use case in mind, but could potentially provide some ideas for a reimplementation.

One thing which has frustrated me with custom tags is that (AFAICT) you can only register a custom tag on an open TIFF handle, which means you still get a bunch of warnings about unknown tags when you open the file and it reads the first IFD, before you have a chance to do the registration. Anyone know if there’s a way around that?

Kind regards,

Roger