AWARE [SYSTEMS]
AWare Systems, , Home TIFF and LibTiff Mailing List Archive

LibTiff Mailing List

TIFF and LibTiff Mailing List Archive
July 2016

Previous Thread
Next Thread

Previous by Thread
Next by Thread

Previous by Date
Next by Date

Contact

The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems



New Datamatrix section



Valid HTML 4.01!



Thread

2016.07.05 09:41 "Proposed API improvements", by Yakov Galka
2016.07.05 14:51 "Re: Proposed API improvements", by Olivier Paquet
2016.07.05 15:41 "Re: Proposed API improvements", by Bob Friesenhahn
2016.07.05 16:14 "Re: Proposed API improvements", by Olivier Paquet
2016.07.05 17:18 "Re: Proposed API improvements", by Bob Friesenhahn
2016.07.05 19:52 "Re: Proposed API improvements", by Olivier Paquet
2016.07.06 14:25 "Re: Proposed API improvements", by Yakov Galka
2016.07.06 14:48 "Re: Proposed API improvements", by Bob Friesenhahn
2016.07.19 13:36 "Re: Proposed API improvements", by Yakov Galka
2016.07.19 14:17 "Re: Proposed API improvements", by Olivier Paquet
2016.07.19 14:41 "Re: Proposed API improvements", by Bob Friesenhahn

2016.07.05 14:51 "Re: 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