2007.07.01 03:01 "[Tiff] Big TIFF Sample Files", by

2007.07.03 13:02 "[Tiff] Re: Big TIFF Compression", by Andy Cave

Hi Joris,

It's the "Except for..." that I'm interested in.

In my field (prepress/print), companies tend to use either Huffman, G4 or LZW for RIPped jobs (and JPEG for images). They historically use Huffman over G4 for performance reasons (simpler/faster to code). LZW sometimes for better compression (with stochastic screening) or for 8 bits per pixel.

Flate is rarely used as it's too slow (compared to LZW (and not widely supported)). JBIG is also rarely used as it's too slow (compared to G4 and also not widely supported)). RIPped jobs always have to be lossless.

'large' single separations often run into the 100s of Megs (and are compressed), going from 300M to 600M per separation is not uncommon. You don't often see larger file sizes than that though (although they are easy to create of course).

If one gets reasonable compression (and assuming you can use compression 'cause it's fast enough), I think people rarely run out of space with 2G/4G (in prepress/print, even with very high resolutions). Where in prepress/print I can see BigTIFF becoming useful is storing multiple separations and/or pages in one file. Currently 4+ seps are stored seperately. 4+ * 600M > 2G, so storing them in one file does need something like BigTIFF.

People could easily create TIFF files >2/4G, by increasing the resolution, but apart from security printing, you don't need that high resolution. So in reality, by putting single seps in single files you rarely exceed the 2/4G limit.

One company I know of currently ships systems writing uncompressed TIFFs. This potentially needs BigTIFF for very large sizes and resolutions. But the simple reason they write uncompressed TIFFs is because it's faster to write uncompressed TIFF to a striped SCSI array than it is to compress and write it. But when they have a very large page, they are forced to compress it, as otherwise it would not work.

>From the above you get (hopefully) an appreciation of where BigTIFF will be useful in pre-press - performance (uncompressed files), security printing & multi-channel (or multi-page) single file images. There may be other reasons.

I presume that georeferencing and medical imaging are all 8 bits per pixel, multi-channel for the former (and possibly latter). I am surprised you say they use JPEG, as for medical imaging I presumed that lossless would be important.

I'm interested in hearing real examples as to why BigTIFF is useful for georeferencing and medical imaging. Are the images really that big? After compression or only without? Are they big 'cause they are multi-channel, or multi-page, or uncompressed, or,...?

Sorry if this has been discussed before, but I don't remember it.


----- Original Message -----

From: "Joris" <joris.at.lebbeke@skynet.be>

To: "Andy Cave" <andy.cave@hamillroad.com>; <sc42business@mac.com>; <tiff@lists.maptools.org>

Sent: Tuesday, July 03, 2007 1:39 PM
Subject: Re: Big TIFF Compression

A bit of a hi-jack, but it's a valid question. All these people who want to use BigTIFF, what sort of compression are they planning on using? Any? None? Is their image data 1 bit (Huffman, G3, G4, LZW, JBIG or...) or 8 bit (LZW, Flate or...)?

Just curious.

As far as I know, the answer is 'any and all'. There's no reason I know off why their intention as to compression should be any different from the intention ClassicTIFF users had before. Except for...

Some TIFF users may have a slight preference for no compression, because of interchange reasons or some other private reasons that have to do with their image flow inside their process. It's reasonable to assume these users are the ones that suffer most from ClassicTIFF size limitation, so they might be the first to resort to BigTIFF in bigger numbers, so we might see a higher percentage of BigTIFF files that are not compressed, compared to ClassicTIFF files that are not compressed.

Also, some particular domains of applications of TIFF, like georeferencing and medical imaging software, might be the ones that traditionally write the largest TIFFs, and suffer the ClassicTIFF size limitation more then, say, FAX communication software. So, compression modes like JPEG or so that are often used in these fields, might also be seen in slightly higher percentages in BigTIFF.