2010.01.20 06:04 "Re: [Tiff] BigTiff as new file/mime type", by

While I find this discussion to be directionally correct, I think we should not underestimate the capacity of users and vendors alike for bandwidth greed! While it seems inconceivable that anyone would be sending 4 GB image files as email attachments, experience should tell us that in 10 years, it could be common usage once we all have 10 Gigabit fiber to our doors. Any decisions should be made using this long-term view of our technological world, as you are making a commitment for the future. (Use 4 digits for representing a year? Who would even think of wasting that much storage space?)

Other than this minor point, keep up the good work.

    Gene

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.

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
>