AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

2004.02.09 17:02 "[Tiff] Photoshop 8.0 and libtiff", by Don Ellis
[...]
2004.02.09 19:42 "RE: [Tiff] Photoshop 8.0 and libtiff", by Don Ellis
2004.02.09 19:51 "RE: [Tiff] Photoshop 8.0 and libtiff", by Bob Friesenhahn
2004.02.09 19:58 "Re: [Tiff] Photoshop 8.0 and libtiff", by Frank Warmerdam
2004.02.09 19:59 "RE: [Tiff] Photoshop 8.0 and libtiff", by Thomas J. Kacvinsky
2004.02.09 20:18 "RE: [Tiff] Photoshop 8.0 and libtiff", by Chris Cox
[...]

2004.02.09 19:59 "RE: [Tiff] Photoshop 8.0 and libtiff", by Thomas J. Kacvinsky

lint with the options necessary to check for migration issues between 32 bit and 64 bit platforms is extremely helpful. The Solaris lint will catch unaligned accesses and so forth, for instance.

Thank you for responding so quickly!

You are going to love this. Currently, I need to be able to handle TIFF images up to 4 GB and in the near future I am sure I will need to work with larger images. My company prints 4 color billboards up to 63 feet by 32 feet, the project I am working is for printing 360 dpi up to that size. I have printed images derived from 2 GB to 4 GB TIFF images before. These images were created in Photoshop 7.0 (with the 2 GB file limit) and then strung together with some propriety software which used one data line per strip. We were hoping that Photoshop 8.0/CS on the G5 would eliminate a step. In the near future I am going to need TIFF files up to 8 GB and maybe larger. So I am going to have to work on a 64 bit version of libtiff.

Any ideas or help would be of immensely appreciated.

Thanks.

Donald Ellis

Is it possible to use 'unsigned int' or 'unsigned long' instead? The 32-bit CPU is not going to be able to address more range than an 'unsigned int' will support. All that a 64-bit signed type buys you is support for negative values. Does use of an unsigned type cause problems for the interface?

Bob

My first thought was, "hey, we already work fine with 4GB files". But upon a bit of review I realize we use unsigned int for toff_t, but a signed int for tsize_t. The comments in tiffio.h mention that tsize_t is int32 and not uint32 because some functions return -1. So, I think that is why uint32 isn't used now.

I do kind of wonder if the code could be changed somehow to use uint32 for tsize_t but recognise 0xffffffff as end-of-file, instead of -1. There couldn't be something 0xffffffff bytes long in a file of 4GB or less anyways since there is always some other overhead.

I am hesitant to change tsize_t to a 64 bit type without careful review.

Andrey, perhaps you could create a bug report on this issue and when you have some time dig into a solution for tiff files with chunks of larger than 2GB?

---------------------------------------+------------------------------------
--

I set the clouds in motion - turn up   | Frank Warmerdam,  warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent