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 18:41 "Large File Support", by Chris Barker

I think getting Adobe involved is a bad idea. We have already suffered
too
long because tiff is not in the public domain. I don't think they can
have
a patent on the idea of tags, but if they can we are screwed. If we
leave
it to Adobe we will get stuck with flashpix or something similar that is
full of someone or other's intellectual property.

We need a public process for making a new format to handle large files.
While we are at it we can make tiff better.

I would suggest improving the tiling specification (a natural for large
formats anyway) to include a "tile type" (this allows for zero-size
white
or black tiles, and optimal compression for complex tiles). Anyway, I'm
getting ahead of myself here.

We need a real honest-to-goodness *standard* (without options) so we can
write good (and freely available) software. While standardizing the
format
it would also be an excellent idea to standardize the programming
interface
to read/write/verify/info-extract libraries. Decoupling compression
methods
and photometric stuff from page, tiling and overview info is definitely
the
right way to go. This will allow the new spec to be used as a component
in
something like IIP, where a client can request the tiles it needs at the
nearest available resolution, and receive the minimal set of tiles. This
can make internet-based imaging practical over lower bandwidth
connections.

"Grissom, Ed" wrote:
> 
> In a previous message, Glen said:
> 
> > 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?
> >
> Glen, I think your idea has merit, and something like this would probably be
> the right way to go for any TIFF library.
> 
> However, we first need a specification that describes the details of the new
> format.   This new format would _have_ to have the "magic" number changed
> since the initial IFD offset will be 8 bytes instead of 4.  If we don't
> change the magic we will break all existing TIFF readers.
> 
> Could we call this TIFF ? I believe that Adobe has the name trademarked or
> copyrighted (whichever is appropriate).  Could we use all the ideas in TIFF
> (tags, tag names, etc..) without Adobe's blessing ?  At the start of the
> TIFF 6.0 document there is some info on how to request changes to TIFF, but
> I have had no success trying to get Adobe to pay attention to me.
> 
> Perhaps if everyone on the TIFF list sent email to Adobe, we would get some
> action...
> 
> > P.S. -- Any bets as to when 64 bits will not be enough?
> >
> Even with the exponential growth we have seen in the last 10 years, I think
> that a number that is on the order of the number of atoms in Earth should be
> enough to get thru my lifetime :)
> 
> --
> ed grissom
> egrissom@ziimaging.com

-- 
========================================================================
Barker's law: For every inaction, there is an equal and opposite excuse.

Check out Interlinear's web page at http://www.ilt.com
========================================================================