2012.02.28 15:59 "[Tiff] BigTiff support (libtiff 4.0.1 vs libtif f4.1)", by Cip Cipper

2012.02.28 19:57 "Re: [Tiff] BigTiff support (libtiff 4.0.1 vs libtif f4.1)", by Joris Van Damme

Ciprian,

It was more than I needed as the output was depending on the size of the file. If it did not exceed 4 GB the result was a standard Tiff (version 42) and if it was larger than 4GB the library managed to save it as a large Tiff (version 43) without any "external" intervention.

This has been considered when LibTiff 4.0 was designed. It was deemed undesirable, as however you decide to implement this, there are very serious drawbacks. In fact, it's just not entirely possible unless you willingly neglect to foresee some types of usage, and don't mind output of files with various 'holes' in it depending on the way you choose to support this, etc.

Aperio apparently decided otherwise, but the crash you observed while dealing with palette images may very well be related. And even if it's not, I still don't recommend it.

Instead, ask yourself why you would need this feature. If it's entirely possible you output files over 4 gigabyte in size, than you need software that handles your output to support BigTIFF. The fact that you still write some files as plain old TIFF, does not change a thing. This logic does not apply, of course, in situations where a user decides on the output file format, at run-time. In that case, you offer various file format choices that all have some limitation. Users not being aware of the limitations and consequences of their choice, apparently does not break the validity of offering the choice in the UI. So you may as well let them choose between TIFF and BigTIFF, too. Any added 'friendliness' like automatic offering of BigTIFF when writing TIFF fails due to size limitations, is an added bonus.

Best regards,

Joris Van Damme
AWare Systems