Received: by smtp02.oce.nl (4.1/SMI-4.1)
	id AA22027; Mon, 14 Jun 99 17:56:50 +0200
Received: from gate7.olympiakos.com ([207.113.13.68])
	by oce.nl (8.9.0/8.9.0) with ESMTP id RAA15494;
	Mon, 14 Jun 1999 17:54:30 +0200 (MET DST)
Received: from localhost (bin@localhost)
	by gate7.olympiakos.com (8.8.7/8.8.7) with SMTP id LAA04496;
	Mon, 14 Jun 1999 11:53:30 -0400
Received: by gate7.olympiakos.com (bulk_mailer v1.9); Mon, 14 Jun 1999 11:53:22 -0400
Received: (from majordom@localhost)
	by gate7.olympiakos.com (8.8.7/8.8.7) id LAA04481
	for tiff-outgoing; Mon, 14 Jun 1999 11:53:22 -0400
X-Authentication-Warning: gate7.olympiakos.com: majordom set sender to owner-tiff@olympiakos.com using -f
Received: from holly.cam.harlequin.co.uk (holly.cam.harlequin.co.uk [193.128.4.58])
	by gate7.olympiakos.com (8.8.7/8.8.7) with ESMTP id LAA04477
	for <tiff@olympiakos.com>; Mon, 14 Jun 1999 11:53:18 -0400
Received: from gpo.cam.harlequin.co.uk (gpo.cam.harlequin.co.uk [192.88.238.241])
          by holly.cam.harlequin.co.uk (8.8.4/8.8.4) with ESMTP
	  id QAA16782 for <tiff@olympiakos.com>; Mon, 14 Jun 1999 16:53:16 +0100 (BST)
Received: from squonker (dynamic-13.cam.harlequin.co.uk [192.88.238.249])
          by gpo.cam.harlequin.co.uk (8.8.4/8.8.4) with SMTP
	  id QAA05284 for <tiff@olympiakos.com>; Mon, 14 Jun 1999 16:52:44 +0100 (BST)
Message-Id: <3.0.5.32.19990614165112.00a7ebe0@mailhost.cam.harlequin.co.uk>
X-Sender: martinb@mailhost.cam.harlequin.co.uk
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Mon, 14 Jun 1999 16:51:12 +0100
To: TIFF Mailing List <tiff@olympiakos.com>
From: Martin Bailey <martinb@harlequin.co.uk>
Subject: Re: Large File Support 
In-Reply-To: <14065.929372337@sss.pgh.pa.us>
References: <Your message of Mon, 14 Jun 1999 12:16:22 +0100              <3.0.5.32.19990614121622.00a75a50@mailhost.cam.harlequin.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-tiff@olympiakos.com

At 10:58 14/06/99 -0400, Tom Lane wrote:
>Martin Bailey <martinb@harlequin.co.uk> writes:
>> I've been pondering the idea of large file support, and especially the
>> ideal of minimising the impact that any changes would have on existing
>> readers etc. I see backward compatibility as extremely important to ensure
>> that any changes would be acceptable both to application creators and to
>> the user community.
>
>I agree with that goal, but I think that Frank Warmerdam's idea (allow
>multiple separate TIFF files to be logically "tiled" together to form a
>huge image) is a more practical approach, for the reasons already
>mentioned by him and John Aldridge.

Hmmm, I think we're seeing different requirements for different
applications here.

My interest is in that I'm one of the task force working on TIFF/IT-P2,
very firmly in the realm of graphic arts rather than image manipulation.
One of the things that we want do do for P2 is to find a way of encoding
FP, LW, CT, HC etc within a single file rather than multiple separate files
to reduce the potential for missing files during transmission. That's a
relatively obvious development from the existing TIFF/IT standard, until
you start to think about the total file size.

I am reasonably sure that the approach I suggested would work fine for
TIFF/IT, and the minimal intervention means that it is also something that
we can include easily in the spec.

On the other hand, it has been suggested that tags and mechanisms that we
add in TIFF/IT could be taken as ideas for inclusion in a future version of
TIFF, and I would be reluctant to recommend something that would work for
TIFF/IT and not for other, more general uses of TIFF. I would be even more
reluctant to recommend such an approach for TIFF/IT if I expected that a
future version of TIFF would add the same capability in a different,
incompatible, way.

So here I am in a cleft stick.

It does occur to me, however, that your tiling approach is something that
might logically fall out of the work we're doing for TIFF/IT. In P2 (and
'full' TIFF/IT in the P2 timeframe) it will be possible to reference many
CT (or whatever) files within a single FP file, thus the FP could well be
equivalent to your control file (embedding all components within a single
file is only one option, it will still be valid to use multiple, separate,
files). Obviously that means that the CT specification in TIFF/IT must
allow for the colorspaces and compression schemes etc. that are needed for
more general work. TIFF/IT-P2 is likely to allow for JPEG and Flate
compression of CT data, but not LZW. In P2 it's likely to be limited to
CMYK data (optionally plus spot colours). For mono data you could use MP
rather than CT. It's possible to use RGB or UVL data if you use the full
TIFF/IT spec rather than limiting to only P2.

Does all that make sense?



Regards

Martin Bailey

----------------------------------------------------------
 Digital Print & Publishing                 Harlequin Ltd
 martinb@harlequin.com           http://www.harlequin.com
----------------------------------------------------------
 I try to ensure that my views expressed here accord with
 my employers, but I am not a spokesman for Harlequin and
        the buck stops with me for what I say here
----------------------------------------------------------

