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 11:38 "Re: Large TIFF files", by Gerben Vos

Rob wrote:
> > It goes through all tags and replaces all 64 bit tags with 32
> > bit tags leaving all data on the same position.

Joris wrote:
> - as much 'streamability' as possible (current library goes 
> back only to write offset to next ifd)

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).

> - 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.

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

Only in a particular case. 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.

> > [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.

> I vote  for feasability
> instead: changing minor things to LibTiff, so that 
> count/offsets can be 64bit.

Yes, that would be my idea too, but then change the spec as well as
libtiff. Note that this is largely independent of your previous
sentence!

> 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'm not so
sure libtiff or this mailing list has enough leverage to establish a
de-facto standard. Better to have Adobe and some other major players
(Kofax or other scanner manufacturers?) on board.

> So it is definitely possible that the
> new fileformat is defined by library only.

No, even if we would go solo, we should produce a comprehensive
specification. See how long PNG needed to take off even *with* a good
spec. With only a reference implementation, our attempt is doomed.

> > It is not possible to select allways in advance the right mode, as a
> > user can
> > decide to enlarge a bitmap to > 4GB. When 32 bit mode was chosen and
> > there is
> > a sudden runtime switch to 64bit mode I can imagine quite some
> > difficulties.
> > => So the library must work internally in 64 bit mode.

> The premis, I agree with, but my conclusion is
> => so the library user must specify if it wants to write a 
> 32bit or 64bit file
> in advance, using a flag in the primary TIFFOpen call.

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.

					Gerben.