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
Thread
2010.01.20 06:04 "Re: BigTiff as new file/mime type", by <gene@pc-backup.com>
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
Richard Nolde <richard.nolde@cybox.com> wrote:
>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
>>
>
>_______________________________________________
>Tiff mailing list: Tiff@lists.maptools.org
>http://lists.maptools.org/mailman/listinfo/tiff
>http://www.remotesensing.org/libtiff/