AWARE [SYSTEMS] Imaging expertise for the Delphi developer
AWare Systems, Imaging expertise for the Delphi developer, Home TIFF and LibTiff Mailing List Archive

LibTiff Mailing List

TIFF and LibTiff Mailing List Archive
July 2007

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



Valid HTML 4.01!



Thread

2007.07.01 03:01 "Big TIFF Sample Files", by <sc42business@mac.com>
2007.07.03 10:44 "Re: Big TIFF Sample Files", by Joris Van Damme
2007.07.03 12:15 "Re: Big TIFF Sample Files", by Joris Van Damme
2007.07.03 15:26 "Re: Big TIFF Sample Files", by Phil Harvey
2007.07.03 15:43 "Re: Big TIFF Sample Files", by Stephen Carlsen
2007.07.03 12:26 "Big TIFF Compression", by Andy Cave
2007.07.03 12:39 "Re: Big TIFF Compression", by Joris Van Damme
2007.07.03 13:02 "Re: Big TIFF Compression", by Andy Cave
2007.07.03 13:55 "Re: Big TIFF Compression", by Frank Warmerdam
2007.07.03 14:07 "Re: Big TIFF Compression", by Andy Cave
2007.07.03 14:37 "Re: Big TIFF Compression", by Joris Van Damme
2007.07.03 13:46 "Re: Big TIFF Compression", by Joris Van Damme
2007.07.03 14:23 "Re: Big TIFF Compression", by Andy Cave
2007.07.03 14:34 "Re: Big TIFF Compression", by Kemp Watson
2007.07.03 15:25 "Re: Big TIFF Compression", by Ed Grissom
2007.07.03 15:27 "Re: Big TIFF Compression", by Ed Grissom
2007.07.03 16:31 "Re: Big TIFF Compression", by Michael Wolf
2007.07.03 16:06 "Re: Big TIFF Compression", by Bob Friesenhahn
2007.07.03 19:28 "Re: Big TIFF Compression", by Chris Cox

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

Andy,

Andy Cave wrote:
> 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