Return-Path: <tiff-bounces@lists.maptools.org>
Received: from inas022.isp.belgacom.be (localhost [127.0.0.1])
        by inav009.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-IN-AV-3.00) with ESMTP id l0F6EJsk018592
        for <joris.at.lebbeke@skynet.be>; Mon, 15 Jan 2007 07:14:19 +0100
        (envelope-from <tiff-bounces@lists.maptools.org>)
Received: from inmx003.isp.belgacom.be (inmx003.isp.belgacom.be [195.238.5.11])
        by inas022.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-IN-AS-2.03) with ESMTP id l0F6EIR7024340
        for <joris.at.lebbeke@skynet.be>; Mon, 15 Jan 2007 07:14:18 +0100
        (envelope-from <tiff-bounces@lists.maptools.org>)
Received: from duke.maptools.org (r153.dmsolutions.ca [209.217.116.153] (may be forged))
        by inmx003.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-IN-2.32) with ESMTP id l0F6EBbR015705
        for <joris.at.lebbeke@skynet.be>; Mon, 15 Jan 2007 07:14:12 +0100
        (envelope-from <tiff-bounces@lists.maptools.org>)
Received: from duke.maptools.org (duke.maptools.org [127.0.0.1])
	by duke.maptools.org (8.12.11/8.12.10) with ESMTP id l0F60kcl022753;
	Mon, 15 Jan 2007 01:01:51 -0500
Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172])
	by duke.maptools.org (8.12.11/8.12.10) with ESMTP id l0F60g0C022750
	for <tiff@lists.maptools.org>; Mon, 15 Jan 2007 01:00:43 -0500
Received: by ug-out-1314.google.com with SMTP id 80so1657940ugb
	for <tiff@lists.maptools.org>; Sun, 14 Jan 2007 22:00:40 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=Y3Ukuz5rUWUnKaMIlTrx3/rUjnbGmOk8UjT7Mpbbq24OeLDSutML6XW+VVvHY2UYlsfYz1GvvAxCvu7BHtjIrFyl6nvFm9ILwLyxBdiSpOcH579j8XE/TC3M5ImaV/vEn1oBYplSfIkWQVr9OzAfNy2DoVtYwjar2WRGazcA+Xg=
Received: by 10.78.158.11 with SMTP id g11mr2318796hue.1168840838153;
	Sun, 14 Jan 2007 22:00:38 -0800 (PST)
Received: by 10.78.199.1 with HTTP; Sun, 14 Jan 2007 22:00:38 -0800 (PST)
Message-ID: <787b0d920701142200r3330226dj3b37fdbdc75b1bf7@mail.gmail.com>
Date: Mon, 15 Jan 2007 01:00:38 -0500
From: "Albert Cahalan" <acahalan@gmail.com>
To: "Frank Warmerdam" <warmerdam@pobox.com>
Subject: Re: [Tiff] bigtiff
In-Reply-To: <45AAF843.8080207@pobox.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <787b0d920701141709j13dd91b4l7d56e4934fb77a98@mail.gmail.com>
	<45AAF843.8080207@pobox.com>
Cc: tiff@lists.maptools.org
X-BeenThere: tiff@lists.maptools.org
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: TIFF and libtiff discussion <tiff.lists.maptools.org>
List-Unsubscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@lists.maptools.org?subject=unsubscribe>
List-Archive: <http://lists.maptools.org/mailman/private/tiff>
List-Post: <mailto:tiff@lists.maptools.org>
List-Help: <mailto:tiff-request@lists.maptools.org?subject=help>
List-Subscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@lists.maptools.org?subject=subscribe>
Sender: tiff-bounces@lists.maptools.org
Errors-To: tiff-bounces@lists.maptools.org
X-UIDL: 000000000023ceae.00001f56
X-MSP-STORE: Mon, 15 Jan 2007 07:14:25 +0100
Status:   

On 1/14/07, Frank Warmerdam <warmerdam@pobox.com> wrote:
> Albert Cahalan wrote:
> > I've written some tiff read/write code, by hand (w/o libtiff),
> > and I've been looking at bigtiff.
> >
> > The design looks like it got pulled between the conflicting desires
> > of compatibility and sanity, getting rather bent out of shape in the
> > process. It's not too late to reconsider.
>
> Albert,
>
> You proposed a number of adjustments to the BigTIFF specification.
>
> The first was to provide better backward compatibility - however, it
> wasn't exactly clear to me how much backward compatibility it was going
> to give.  Was the intention that TIFF applications could read an image?
> Just some of the image characteristics?

With no modifications, just some image characteristics. This could
be very little (we have a TIFF) or it could include things such as
compression, size, and colorspace. It could also be nothing, if the
magic number changes.

More importantly, it was intended that software modifications be easy.
Keeping the data structures the same size (particularly the IFD entry
structs and the main header) lets TIFF-handling software be upgraded
with very little change. The same data structures may be used.

> For the latest "cruft removal", you proposed relaxing the alignment
> requirement, or possibly enforcing it by actually shifting offsets.
> I would agree that the alignment requirements currently are somewhat
> pointless since I don't believe they are actually adhered to (even by
> libtiff?)

Enforce it or kill it.

Both SSE and AltiVec have instructions that require 16-byte alignment.
Handling unaligned data is slow. If the programmer doesn't handle it,
SSE will fault and AltiVec will round off the addresses.

> The UUID for tags has some advantages I suppose.
>
> But overall, all these fly in the face of what I think is most important
> about BigTIFF.  That is that it is in all respects the same as TIFF
> except for changing some required values to be 64bit to handle large
> data.  It is exactly this similarity to the existing TIFF spec that
> I think is important for easy adoption.

No, bigtiff already broke things severely by changing struct layouts.
If you're going to break things to that extent, you may as well take
the opportunity to clean up some of the ugly things.

> For instance moving to 128 bit uuids for tag identities would complicate
> API interfaces that are currently only accepting ints for tag ids.

An initial implementation could simply require that all but the first
(or last) 16 bits be zero. Call this "base level" support if you wish.
You could even just say the extra 14 bytes are reserved padding
bytes for future expansion. It's very nice to eliminate the problem
of tag collisions, but the 8-byte IFD entry alignment is itself quite
useful for performance.
_______________________________________________
Tiff mailing list: Tiff@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
