2010.01.15 13:40 "Re: [Tiff] eta for bigtiff support?", by Phil Harvey

2010.01.20 03:40 "[Tiff] 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.

> ------------------------------

> 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