Return-Path: owner-tiff@olympiakos.com
Return-Path: <owner-tiff@olympiakos.com>
Received: from localhost (localhost [127.0.0.1])
	by at1895.spb.edu (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f3R9lCrE027948
	for <dron@localhost>; Fri, 27 Apr 2001 13:48:38 +0400
Received: from eudoramail.com [209.185.123.45]
	by localhost with POP3 (fetchmail-5.8.1)
	for dron@localhost (single-drop); Fri, 27 Apr 2001 13:48:38 +0400 (MSD)
Received: from gate7.olympiakos.com ([207.176.88.85]) by shared1-mail.whowhere.com; Thu Apr 26 11:28:22 2001
Received: from localhost (daemon@localhost)
	by gate7.olympiakos.com (8.9.3/8.9.3) with SMTP id OAA24498;
	Thu, 26 Apr 2001 14:11:35 -0400
Received: by gate7.olympiakos.com (bulk_mailer v1.9); Thu, 26 Apr 2001 14:08:31 -0400
Received: (from majordom@localhost)
	by gate7.olympiakos.com (8.9.3/8.9.3) id OAA24262
	for tiff-outgoing; Thu, 26 Apr 2001 14:08:31 -0400
X-Authentication-Warning: gate7.olympiakos.com: majordom set sender to owner-tiff@olympiakos.com using -f
Received: from zedi.ziimaging.com (zedi.ziimaging.com [216.180.42.37])
	by gate7.olympiakos.com (8.9.3/8.9.3) with ESMTP id OAA24259
	for <tiff@olympiakos.com>; Thu, 26 Apr 2001 14:08:29 -0400
Received: by zedi.ziimaging.com with Internet Mail Service (5.5.2653.19)
	id <2MC0PD1J>; Thu, 26 Apr 2001 13:12:29 -0500
Message-ID: <CDCC7C1959EBD411966300105ACAB8672AF780@zedi.ziimaging.com>
From: "Grissom, Ed" <egrissom@ziimaging.com>
To: tiff@olympiakos.com
Subject: RE: 8K chunks for RowsPerStrip?
Date: Thu, 26 Apr 2001 13:12:28 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-tiff@olympiakos.com
Status: RO
Content-Length: 2262
Lines: 53


Don Swatman says:
> Upping the size recommendation would make a lot of sense; in
> these days of 512Mb computers, 8k seems a little bit penny
> pinching. How about 128k?  I don't feel this would give too
> many problems with the current address space limitations. 

I don't think that the virtual memory size staying constant (as mentioned by
Max Martinez) is an issue.  Anytime you get over the physical memory size,
you start having performance problems.  Since the typical amount of physical
memory has been increasing, I agree with Don that a higher recommendation
makes sense. 

We typically recommend 10Meg/strip for our users, and I seen no reason to go
below 1Meg/strip for home-user targeted apps.  1 Meg is only 3% of a low end
32Meg machine.  


> The
> real problem is the limitation of 2G file sizes. With printers
> (including large Format) having heads of 1440 dpi and 2880
> coming up, tiff is going to run out of numbers. It would be
> really good to see chained files to hold the extra data. For
> this reason, we've not adopted tiff as out archival format buy
> had to develop our own.

Our current scanner scans gray and color film at ~3500 DPI.  For a full
10inchx10inch aerial photo negative, this can be close to 3.5 GB
uncompressed for the main image.  The TIFF spec limit is 4GB, not 2GB.  Read
the spec closely (*), offsets are "unsigned".  However LibTIFF, and other
apps may suffer from the "signed" arguments to fseek() which limit a file to
2GB.  On windowsNT/2k, and likely on 64-bit Unixes, the seeking can be done
to higher offsets with more advanced APIs.  


> On another note, what applications output data in the tiled
> format ( and read it). This format makes a lot of sense to me
> as it allows fast easy access to data for doing such otherwise
> memory hungry tasks such as rotation.

Our apps deal exclusively with tiled data. They will not read or write
untiled data. We provide converter utilities to convert to and from tiled
format so that our users can interoperate with other apps that do not do
tiling.   When writing, users can choose between "single strip", "TIFF spec
Recommendation", or "user defined" rows per strip. 


(*) section 2, first paragraph, last sentence. 

--
ed grissom
egrissom@ziimaging.com


