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
January 2010

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

2010.01.20 03:40 "BigTiff as new file/mime type", by Richard Nolde
2010.01.20 06:04 "Re: BigTiff as new file/mime type", by <gene@pc-backup.com>
2010.01.20 13:58 "Re: BigTiff as new file/mime type", by Edward Lam

2010.01.20 03:40 "BigTiff as new file/mime type", by Richard Nolde

Tiff list subscribers,

I agree with Tom, BigTiff is still TIFF and the TIFF Spec says that 
beyond baseline TIFF, no application is required to deal with every 
possible variety of TIFF file (even without considering the additional 
possibilities of BigTiff).  Since MIME is defined in reference to email 
for the most part, according to 
http://www.iana.org/assignments/media-types/, do we really need to be 
concerned whether we need MIME support for a file type explicitly 
created to handle files over the 2 GB limit imposed by old style TIFF 
with signed 32 bit offsets?  Once you MIME encode a binary file, you are 
enlarging it by roughly 150 percent for transmission which makes the 
idea of sending it over the wire laughable.  What specific applications 
other than browsers and network mail use the MIME type to decide which 
helper application to call?

The current state of handling TIFF files, sometimes identified with 
.TIF, .TIFF, .tif, or .tiff, is only issue for people who run an OS that 
is silly enough to define the file type and/or application by the 
extension (which once lead a student with whom I worked to believe that 
he could convert the file from one format to another simply by changing 
the extension).  Nix systems use /etc/magic and other variations thereon 
to actually determine the file type, regardless of the file name.  Since 
BigTiff files have a unique signature, that will continue to work on any 
system that has that utility.

Any application that intends to support BigTIFF can check the first few 
bytes of the file whether or not /etc/magic exists. There is no way that 
BigTiff will be handled automatically by existing applications, so I 
don't see the problem with identifying BigTiff files as yet another TIFF 
variant.

Richard Nolde
Tiffcrop author

>
> FWIW, I agree with the position that it's still TIFF.  The argument to
> call it something different, or use a different extension, is pretty
> much equal to the argument that every different compression method
> within TIFF deserves a new name and a new extension.  For better or
> worse, "TIFF" covers a wide range of possibilities, and there's probably
> no single app that supports every one of them anyway.
>
> 			regards, tom lane
>
> ------------------------------
> From: Bob Friesenhahn<bfriesen@simple.dallas.tx.us>
> If these applications are written correctly, then they should then
> immediately reject a BigTIFF file as not being a TIFF file.  That is
> why there is not great cause for concern about existing applications.
> The main concern is for cases where different applications would be
> usefully selected based on MIME type.
>
> Bob
>