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
June 1999

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

1999.06.03 19:48 "Large File Support", by Bruce Forsberg
1999.06.04 03:45 "Re: Large File Support", by Frank Warmerdam
1999.06.04 07:32 "Re: Large File Support", by Rob Tillaart
1999.06.07 07:05 "Re: Large File Support", by Rainer Wiesenfarth
1999.06.08 21:14 "Re: Large File Support", by Peter Smith
1999.06.08 21:58 "Re: Large File Support", by Ed Grissom
1999.06.08 22:52 "Re: Large File Support", by Peter Smith
1999.06.09 01:27 "Re: Large File Support", by Martin Bailey
1999.06.09 06:50 "Re: Large File Support", by Owen Pearn
1999.06.09 14:33 "Re: Large File Support", by Martin Bailey
1999.06.09 08:07 "Re: Large File Support", by Rob Tillaart
1999.06.04 18:35 "Re: Large File Support", by Bruce Forsberg
1999.06.07 13:03 "Re: Large File Support", by Frank Warmerdam
1999.06.09 03:05 "Re: Large File Support", by <glen@lumisys.com>
1999.06.09 13:13 "Re: Large File Support", by Ed Grissom
1999.06.09 13:33 "Re: Large File Support", by Frank Warmerdam
1999.06.09 14:08 "Re: Large File Support", by Ed Grissom
1999.06.09 18:50 "Re: Large File Support", by Chris Barker
1999.06.09 18:41 "Large File Support", by Chris Barker
1999.06.10 13:21 "Re: Large File Support", by Chris Hanson
1999.06.10 13:52 "Re: Large File Support", by Frank Warmerdam
1999.06.10 14:37 "Re: Large File Support", by John Aldridge
1999.06.10 15:10 "Re: Large File Support", by Peter Smith
1999.06.10 16:56 "Re: Large File Support", by Chris Barker
1999.06.14 11:16 "Re: Large File Support", by Martin Bailey
1999.06.14 14:58 "Re: Large File Support", by Tom Lane
1999.06.14 15:30 "Re: Large File Support", by Eric Shapiro
1999.06.14 16:27 "Re: Large File Support", by Chris Barker
1999.06.14 15:51 "Re: Large File Support", by Martin Bailey
1999.06.09 15:52 "Re: Large File Support", by Ed Grissom
1999.06.10 09:48 "Re: Large File Support", by Klaus Bartz
1999.06.10 13:05 "Re: Large File Support", by Chris Hanson
1999.06.11 01:48 "Re: Large File Support", by <glen@lumisys.com>

1999.06.09 03:05 "Re: Large File Support", by <glen@lumisys.com>

Folks,

Here's my two cents.  Being just a _little_ incompatible is just about as bad as
being a _lot_ incompatible.  Therefore, "in for a penny, in for a pound".  Let's
just do the whole thing at once, make a completely new header and solve this thing
more or less all at once.

A nice way to handle it would be to add a layer to handle TIFF files like a
Microsoft "COM" object.  The idea is that you query the layer as to what interface
(e.g., 64-bit vs. 32-bit) the object (i.e., TIFF file) supports.  So a new program
with the ability to handle 64-bit integers would ask for the 64-bit interface
first, and if the header is an "old" version with 32-bit stuff, than that query
fails.  The program would then ask if the file supports the 16-bit version, and of
course it does.  Fine.

If your program only can handle the 32-bit integers, don't even ask for the 64-bit
interface.  Just ask for the 32-bit.  Now, if the file is a "native" 32-bit
version, the query will succeed.  If it is a newer 64-bit version, then it would
fail (unless, *perhaps*, the new layer could scan the header and guarantee that all
64-bit integers could fit in 32 bit.

I think anything we do is apt to be major.  At least this would be an elegant way
of handling the differences between old and new files and old and new programs /
TIFF libraries.  Eventually all (yes, *ALL*) programs would have to / should be
changed to use the new layer.  But at least this would eventually solve the
problem.

What do you all think?

P.S. -- Any bets as to when 64 bits will not be enough?

Frank Warmerdam wrote:

> Rainer Wiesenfarth wrote:
> > I'd prefer the professional way rather than the quick-and-dirty one: If
> > offsets in the file are changed to be 64 Bit, then ALL offsets should
> > be changed.
>
> Rainer,
>
> Given time to reflect, I agree that my proposal would lead into a morass
> of problems somewhat akin to segmented programming on the x86.  I agree
> that a better approach is 64bit offsets used everywhere offsets apply.

> <snip>

> I suppose so.
>
> Because this approach requires fundamental changes to the directory format
> I think it will be significantly harder to pull off than the offset32 approach.
> Now I am waffling again.   It makes my brain hurt.
>
> Regards,
>
> ---------------------------------------+--------------------------------------
> I set the clouds in motion - turned up | Frank Warmerdam, warmerda@home.com
> light and sound - activate the windows | http://members.home.com/warmerda
> and watch the world go round - Rush    | Geospatial Programmer for Rent