2016.07.05 14:51 "Re: [Tiff] Proposed API improvements", by Olivier Paquet

2016-07-05 5:41 GMT-04:00 Yakov Galka <ybungalobill@gmail.com>:

that others will benefit if this makes it into libtiff. Since libtiff can extend the behavior of its APIs, we can change the TIFFTileXXX interface to support reading strips rather than introducing new API like I did. The only

That appears to make sense. We have something similar in our code, where the layer calling TIFF functions handles strips as wide tiles and presents a single interface to the rest of the application. That it can be done with the existing tile interface makes it an obvious improvement.

function that has to be added is TIFFTileDims(TIFF *t, uint32 *tw, uint32 *th, uint32 *td) which will return the dimensions by looking at the tags appropriate for the tiff at hand.

This is also interesting to handle some corner cases like missing tags or values greater than the image size. There doesn't seem to be any shortened name in the API though so I believe TIFFTileDimensions would fit better.

Having something like this for writing TIFFs would be useful too, though I haven't looked into it yet.

I suspect there are far fewer applications writing tiles than wanting to just support reading them so it may not be as important.

Current error handling routines are overridden globally, thus causing trouble in multi-threaded environments or in library code that uses libtiff internally but cannot interfere with other users of libtiff (i.e. from application code or sibling libraries using libtiff).

In one of the above threads, it was proposed to duplicate each of the TIFFOpen, TIFFOpenW, TIFFFdOpen, TIFFClientOpen functions to accept the error handling procedure. I want to note that this is nonsensical either, because if the clientdata isn't specified by the author of the error handler (like in the TIFFOpen, TIFFOpenW and TIFFFdOpen) then there is nothing she can do with it in the callback. Therefore it's only the TIFFClientOpen which has to be extended.

TIFFOpen and friends can still be extended, they just need to also be given the a "client data" handle for the error handler. Then they need to wrap it inside their own struct which is given as client data to TIFFClientOpen. A bit messy on the inside but clean on the outside and I think it has value. Being forced to use TIFFClienOpen just to get proper error handling is not nice. But at least having one way to do it right is a good first step.

Using this extended TIFFOpen would break TIFFGetReadProc, TIFFGetWriteProc etc but I'm honestly not sure why we even have those in the first place. They were dumped in with a BigTIFF commit with no further explanation.

We could also use a second opaque handle just for the error handler but I don't like the implications very much.

Surely these features require a lot of laborious work (mostly the second one). I may participate in some of the effort. Therefore, considering the scope of the changes, I wish a consensus is reached of whether such changes would be welcome at all.

I think fixing the error handling is important as it really is broken. I'm more neutral on the tile/strip situation.

Olivier