- 2007.07.11 09:53 "Re: [Tiff] BigTIFF, let the race begin!", by Frederic Delhoume
- 2007.07.11 12:58 "Re: [Tiff] BigTIFF, let the race begin!", by Edward Lam
- 2007.07.11 16:13 "[Tiff] RE: Tiff Digest, Vol 38, Issue 22", by Kemp Watson
- 2007.08.17 14:51 "[Tiff] tiff problems win to mac", by Balint Radics
2007.07.11 16:54 "Re: [Tiff] BigTIFF, let the race begin!", by Kemp Watson
Actually, on www.bigtiff.org, Aperio had a 1,095,630 x 939,495 pixel image. Written with their version of BigTIFF, but presumably the file met the spec.
Seems to be missing now, but I saw it, I did...
Kemp
Message-ID: <Pine.SOC.4.60.0707110853240.922@blade.simplesystems.org>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
While GraphicsMagick can handle huge files (except for under Windows),
FYI, if your code is 64-bit pointer safe, then linking your application with the -LARGEADDRESSAWARE linker option on Windows will allow your 32-bit application a full 4 GB virtual address space when running under 64-bit Windows. I know it doesn't help much but it's a very easy thing to do for users of 64-bit Windows.
Right. The problem with GraphicsMagick on 32-bit Windows is that it accesses input and output files using the stdio interfaces which are normally only 32 bit on Windows. Does stdio support large files on 64-bit Windows? Regardless, the proper solution is to get away from using stdio on Windows.
The new BigTIFF size to exceed is 111GB. I created a 200000x200000 stripped RGB BigTIFF under Apple OS X (G5) and verified reading back a portion.
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.476 / Virus Database: 269.10.2/894 - Release Date: 10-Jul-2007 5:44 PM