AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

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

2016.07.06 14:25 "Re: [Tiff] Proposed API improvements", by Yakov Galka

On Tue, Jul 5, 2016 at 5:51 PM, Olivier Paquet <olivier.paquet@gmail.com> wrote:

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.

This will effectively store two clientdatas, which I don't like very much... but perhaps it is the right solution.

On Tue, Jul 5, 2016 at 6:41 PM, Bob Friesenhahn < bfriesen@simple.dallas.tx.us> wrote:

> Historically, a problem has been that applications support reading > scanlines or strips but fail to offer code to read tiles. A new

> tile-oriented interface would represent a third case which no applications > would support when it is introduced. A concern would be that most using

> applications are already written, existing applications still need to work > with many existing libtiff versions, and so the new interface would not be

> used.
>

I think it proves the point: Applications fail to support reading tiles because there are currently two incompatible APIs, one for tiled and one for stripped tiffs. Some developers simply don't bother implementing both.

Maybe I wasn't clear enough, but the proposed solution *does not* introduce a third interface. What I proposed is to make the tiled interface a universal one, so that future applications can use it exclusively. The strip interface may be declared deprecated, pointing to the tiled interface, or even made read tiled tiffs as stripped. There is only one new function proposed, which maps all the different tag names to uniform tile size.

Applications won't really "switch" to anything. Instead those willing to use the new functionality will just pretend that all tiffs are tiled and benefit from simplified logic in their code.

--

Yakov