AWARE [SYSTEMS] Imaging expertise for the Delphi developer
AWare Systems, Imaging expertise for the Delphi developer, Home TIFF and LibTiff Mailing List Archive

LibTiff Mailing List

TIFF and LibTiff Mailing List Archive
April 2004

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



Valid HTML 4.01!



Thread

2004.04.15 00:26 "Large TIFF files", by Lynn Quam
2004.04.15 01:57 "Re: Large TIFF files", by Frank Warmerdam
2004.04.15 02:17 "Re: Large TIFF files", by Lynn Quam
2004.04.15 04:41 "Re: Large TIFF files", by Chris Cox
2004.04.15 06:05 "Re: Large TIFF files", by Rob Tillaart
2004.04.15 12:23 "Re: Large TIFF files", by Dan Smith
2004.04.15 13:33 "Re: Large TIFF files", by Frank Warmerdam
2004.04.15 21:51 "Re: Large TIFF files", by Chris Cox
2004.04.16 17:23 "Re: Large TIFF files", by Joris Van Damme
2004.04.17 02:50 "Re: Large TIFF files", by Joris Van Damme
2004.04.20 08:29 "Re: Large TIFF files", by Rob Tillaart
2004.04.20 14:20 "Re: Large TIFF files", by Joris Van Damme
2004.04.21 07:06 "Re: Large TIFF files", by Rob Tillaart
2004.04.20 20:44 "Re: Large TIFF files", by Chris Cox
2004.04.21 07:30 "Re: Large TIFF files", by Rob Tillaart
2004.04.21 17:54 "Re: Large TIFF files", by Chris Cox
2004.04.22 07:38 "Re: Large TIFF files", by Rob Tillaart
2004.04.22 18:21 "Re: Large TIFF files", by Chris Cox
2004.04.22 18:34 "Re: Large TIFF files", by Thomas J Kacvinsky
2004.04.22 18:43 "Re: Large TIFF files", by Chris Cox
2004.04.22 18:49 "Re: Large TIFF files", by Bob Friesenhahn
2004.04.22 19:52 "Re: Large TIFF files", by Phillip Crews
2004.04.22 20:45 "Re: Large TIFF files", by Andrey Kiselev
2004.04.22 21:06 "Re: Large TIFF files", by Chris Cox
2004.04.22 21:35 "Re: Large TIFF files", by Joris Van Damme
2004.04.22 21:49 "Re: Large TIFF files", by Bob Friesenhahn
2004.04.22 21:59 "Re: Large TIFF files", by Chris Cox
2004.04.22 22:23 "Re: Large TIFF files", by Bob Friesenhahn
2004.04.22 22:31 "Re: Large TIFF files", by Joris Van Damme
2004.04.22 22:34 "Re: Large TIFF files", by Chris Cox
2004.04.22 23:03 "Re: Large TIFF files", by Joris Van Damme
2004.04.22 23:17 "Re: Large TIFF files", by Bob Friesenhahn
2004.04.22 23:59 "Re: Large TIFF files", by Chris Cox
2004.04.23 15:58 "Re: Large TIFF files", by Leonard Rosenthol
2004.04.26 14:50 "Re: Large TIFF files", by Marco Schmidt
2004.04.23 12:45 "Re: Large TIFF files", by John Aldridge
2004.04.23 13:12 "Re: Large TIFF files", by Joris Van Damme
2004.04.23 20:37 "Re: Large TIFF files", by Bob Friesenhahn
2004.04.23 22:31 "Re: Large TIFF files", by Chris Cox
2004.04.23 22:38 "Re: Large TIFF files", by Bob Friesenhahn
2004.04.23 22:58 "Re: Large TIFF files", by Chris Cox
2004.04.26 10:03 "Re: Large TIFF files", by Joris Van Damme
2004.04.26 14:32 "Re: Large TIFF files", by Bob Friesenhahn
2004.04.26 07:30 "Re: Large TIFF files", by Rob Tillaart
2004.04.26 09:58 "Re: Large TIFF files", by Joris Van Damme
2004.04.26 11:06 "Re: Large TIFF files", by Rob Tillaart
2004.04.26 11:28 "Re: Large TIFF files", by Joris Van Damme
2004.04.26 12:05 "Re: Large TIFF files", by John Aldridge
2004.04.26 12:33 "Re: Large TIFF files", by Joris Van Damme
2004.04.26 12:53 "Re: Large TIFF files: explicitly different format", by Dan Smith
2004.04.26 13:16 "Re: Large TIFF files: explicitly different format", by Joris Van Damme
2004.04.26 17:10 "Re: Large TIFF files: explicitly different format", by Chris Cox
2004.04.26 11:38 "Re: Large TIFF files", by Gerben Vos
2004.04.26 12:50 "Re: Large TIFF files", by Joris Van Damme
2004.04.27 06:12 "Re: Large TIFF files", by Rob Tillaart
2004.04.26 16:54 "Re: Large TIFF files", by Chris Cox
2004.04.23 13:16 "Re: Large TIFF files", by Phillip Crews
2004.04.23 20:28 "Re: Large TIFF files", by Andrey Kiselev
2004.04.23 15:54 "Re: Large TIFF files", by Leonard Rosenthol
2004.04.22 10:32 "Re: Large TIFF files", by Gerben Vos
2004.04.22 18:41 "Re: Large TIFF files", by Chris Cox
2004.04.22 19:45 "Re: Large TIFF files", by Dan Smith
2004.04.22 20:08 "Re: Large TIFF files", by Chris Cox

2004.04.26 12:50 "Re: Large TIFF files", by Joris Van Damme

Gerben Vos wrote:
> Rob's proposal would keep streamability unless you (a) don't know
> whether you'll be writing 32-bit or 64-bit in advance *and* (b) you want
> to write 32-bits downward compatible TIFF as long as that's possible. I
> think that's reasonable. You can have two, but not all three. He's just
> extending the possibilities. We don't have to implement it yet (see my
> later comments on the specification vs. the library).

Either you didn't understand Rob, or I didn't, or you didn't understand me, or
I'm not understanding you. Or something. Not quite sure.

Further down you write:
> Yes, the library should always internally work with 64 bit pointers,
> also to prevent doubling the code size, but it should be possible for a
> user to specify in advance which of the two is going to be written. Or
> maybe even leave it open.

Rob said: internally start working with 64bit pointers, correct to 32bit if upon
closing filesize <4gig
I said: better let user specify in advance.

Or at least, I think we said that, but you're confusing the hell out of me. ;-)

> > - total relocatability (definite requirement)
>
> Not sure what you mean here. Do you mean that it should be possible for
> everything to appear anywhere in the file? I.e., everything should be
> addressed by 64-bit offsets? Although it may be the best thing to do,
> I'm not so sure if it's a definite requirement.

Yes, that is what I mean. In my humble opinion, that is like *the major* corner
stone of the format.

> > Just my two cents: I don't like the idea of going back and
> > rewriting all IFD.
>
> Only in a particular case.

Particular case being: all 32bit tiffs, all tiff <=4gig. If I understood Rob
correctly. That's about 99% of the files we expect the library to write first
year or so, I guess, so it may not be that particular a case at all.

> I suppose a libtiff user would have to turn
> on this behaviour. Streamability is important for some people, but it
> isn't necessary for everyone. I think it could be a reasonable way to
> have some extra backwards compatibility.

Again, you're really confusing the hell out of me. I'm not sure what exactly
'some extra backwards compatibility' referers to.

> > > [fileformat and library are closely related but two
> > > different things]
>
> > Depends. If there is a complete and independent
> > specification, then, yes, there
> > is a fileformat that is not defined by the library.
>
> I think it is an absolute must that there is a complete specification
> (whoever makes it). Having the format defined by the library would make
> updating existing non-libtiff implementations to 64 bits almost
> unfeasible.

OK, I'm not going to argue about that, you may be very right in stressing the
importance of good spec. But I still also stress that I'd like to see
*something* happening, besides this discussion, either way.

Note that my proposal (logically forking all reference to 32bit count/offsets in
libtiff to either 32bit or 64 bit depending on a single flag in the TIFF
structure that gets set with a parameter of new TIFFOpen call, and adding a
single datatype, *not* changing anything else, *not* changing tag codes,
meanings, or anything, plus keeping single tiles/strips restricted to <4gig)
probably takes less effort then the combined effort of this discussion already,
and is clean and easilly communicated, this is likely to be equally easilly
adopted by non-libtiff implementations.

> Note that this is largely independent of your previous
> sentence!

My subtle attempt was to link both seemingly unrelated things with the word
'feasability', implying that whether things do or do not start moving may depend
upon whether we choose to discuss seemingly grand things like re-inventing some
wheels or to simply do the job that needs to be done.

> > Adobe may be bothering to write a spec, which is a good
> > thing, but I don't think
> > this list is going to be bothered by that.
>
> We have let that bother us for many years, why stop now? :-)

I can see I expressed myself badly. I meant to say the list is most probably not
going to bother with writing a spec. But of course we do like Adobe to take care
of that, of course I'm awaiting TIFF 7.0 spec, as we all have been for what
seems like decades. Of course I care!

Note that Chris seemed to have implied that a TIFF 7.0 spec may actually be in
the pipeline. I think we ought to consider hiring a group of chearleaders or
something for moral support.



Joris Van Damme
info@awaresystems.be
http://www.awaresystems.be
Download your free TIFF tag viewer for windows here:
http://www.awaresystems.be/imaging/tiff/astifftagviewer.html