2007.07.03 13:46 "[Tiff] Re: Big TIFF Compression", by Joris Van Damme

Andy,

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

You provide useful information and considerable thought, but I fail to see your point. Are you trying to decide whether or not you need to support reading BigTIFF? If you use LibTiff, you'll be supporting it anyhow, pretty soon now, when you upgrade to LibTiff 4.0. Are you trying to decide whether or not to start writing BigTIFF in your process? I would personally do that if an average file of the application is 1 gigabyte or more, since it's pretty likely some files will need to exceed 4 gigabyte in that situation, but I would personally not do it (yet) if the application is writing files that are on average no more then a couple of dozen megabytes. But this is merely my personal opinion.

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.

Support for flate compression has evolved more then the general opinion about support for flate compression. Most of us keep thinking it's badly supported, but meanwhile most of us support it by now. I do agree JBIG is not widely supported.

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.

You may be right, I'm no medical imaging expert.

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,...?

No matter why they're big, they're big.

Part of why TIFF is useful to many, is because of features like extra channels, multi-page, etc. Those features multiply file size. Anyone arguing that their average image is half a gigabyte, will need BigTIFF if they start writing several average images to a single file, a feature that they've not used before because they couldn't, but might find new applications for in the future.

Anyway, I think this discussion is a bit moat. We came up with BigTIFF, because there had repeatedly been a demand for it, over many years, and was long overdue according to some. And just because it was fun, too. As to where usage of the format will evolve, which chickens that will grow out of the eggs we produced... Some people defenetly really need it. Others, like maybe yourself, will find some new applications that became possible with BigTIFF, like having multiple of your images in the same file and/or having more seps as the printing process evolves or whatever, may turn out useful. Others might see that BigTIFF is around, in the wild, and start writing it just because they can. It may turn out BigTIFF replaces ClassicTIFF in the long run, or it may turn out BigTIFF files remain a small percentage of the 'TIFF files out there'. We may one day decide BigTIFF wasn't even worth the trouble (but that's unlikely), or we may one day stop and wonder with some melancholy how on earth we were able to encode images in less then 4 gigabyte in the old days. Who knows? Who cares? The important thing is that some people needed it, and now they have it. TIFF's been made future-proof. And we had a good time doing it. And that is exactly how and why all major steps like these come about in this business.

There was a time when many of us doubted we'd ever have a real need for more then 64 kilobyte of RAM. There will very likely be a time when few of us remember files and file formats were once limited to 4 gigabyte in size.

Best regards,

Joris Van Damme
info@awaresystems.be
http://www.awaresystems.be/
Download your free TIFF tag viewer for windows here:
http://www.awaresystems.be/imaging/tiff/astifftagviewer.html