Return-Path: <tiff-bounces@remotesensing.org>
Received: from inmx009.isp.belgacom.be (inmx009.isp.belgacom.be [195.238.3.146])
        by mailst034.isp.belgacom.be (8.12.11/8.12.11/Skynet-MAILSTORE-2.14) with ESMTP id i8HEfIoa010495
        for <joris.at.lebbeke@skynet.be>; Fri, 17 Sep 2004 16:41:18 +0200
        (envelope-from <tiff-bounces@remotesensing.org>)
Received: from xserve.flids.com (adsl-065-083-169-202.sip.mco.bellsouth.net [65.83.169.202])
        by inmx009.isp.belgacom.be (8.12.11/8.12.11/Skynet-IN-2.32) with ESMTP id i8HEf3GB028212
        for <joris.at.lebbeke@skynet.be>; Fri, 17 Sep 2004 16:41:05 +0200
        (envelope-from <tiff-bounces@remotesensing.org>)
Received: from adsl-065-083-169-202.sip.mco.bellsouth.net (localhost [127.0.0.1])
	by xserve.flids.com (Postfix) with ESMTP
	id 023292F60C1; Fri, 17 Sep 2004 10:40:46 -0400 (EDT)
X-Original-To: tiff@remotesensing.org
Delivered-To: tiff@remotesensing.org
Received: from sabre.velocet.net (sabre.velocet.net [216.138.209.205])
	by xserve.flids.com (Postfix) with ESMTP id E1BF32F60AC
	for <tiff@remotesensing.org>; Fri, 17 Sep 2004 10:40:43 -0400 (EDT)
Received: from pobox.com (H156.C195.tor.velocet.net [216.138.195.156])
	by sabre.velocet.net (Postfix) with ESMTP
	id 81CC3137FD1; Fri, 17 Sep 2004 10:40:36 -0400 (EDT)
Message-ID: <414AF764.7030404@pobox.com>
Date: Fri, 17 Sep 2004 10:40:36 -0400
From: Frank Warmerdam <warmerdam@pobox.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Bob Friesenhahn <bfriesen@simple.dallas.tx.us>
Subject: Re: [Tiff] BigTIFF Tag Value Count issue
References: <001c01c49c21$2bf33730$c325c850@dfgrrxsknr4e><Pine.SOC.4.60.0409161905220.15634@blade.simplesystems.org><001401c49c4d$bff536f0$379688d9@dfgrrxsknr4e><Pine.SOC.4.60.0409162021080.15634@blade.simplesystems.org><p05210618bd7003f36f75@[153.32.48.223]><Pine.SOC.4.60.0409162303330.15634@blade.simplesystems.org>	<p0521061ebd70184c3453@[153.32.48.223]>	<005601c49cab$344b3060$4c24c850@dfgrrxsknr4e>
	<Pine.SOC.4.60.0409170929380.15634@blade.simplesystems.org>
In-Reply-To: <Pine.SOC.4.60.0409170929380.15634@blade.simplesystems.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Tiff mailing list <tiff@remotesensing.org>
X-BeenThere: tiff@remotesensing.org
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: TIFF and libtiff discussion  <tiff.remotesensing.org>
List-Unsubscribe: <http://xserve.flids.com/mailman/listinfo/tiff>,
	<mailto:tiff-request@remotesensing.org?subject=unsubscribe>
List-Archive: <http://xserve.flids.com/pipermail/tiff>
List-Post: <mailto:tiff@remotesensing.org>
List-Help: <mailto:tiff-request@remotesensing.org?subject=help>
List-Subscribe: <http://xserve.flids.com/mailman/listinfo/tiff>,
	<mailto:tiff-request@remotesensing.org?subject=subscribe>
Sender: tiff-bounces@remotesensing.org
Errors-To: tiff-bounces@remotesensing.org
X-UIDL: dd18b528538c5e19f48725b6ce57b58f

Bob Friesenhahn wrote:
> On Fri, 17 Sep 2004, Joris wrote:
> 
>>
>> If I'm not mistaking, on most processors there is a gain from aligning 
>> of data,
>> whilst things still work if data is not aligned. Thus, it pays to build
> 
> 
> With some processors (particularly RISC type processors), attempting to 
> read unaligned data results in a program crash.  Probably Intel x86 is 
> not one of those processors.

TIFFers,

Which is why, in general, the reading code ignores native file alignment,
and just memcpy()'s stuff into the proper variables before accessing it.
I don't think alignment is going to help libtiff itself very much because
libtiff can't depend on it and remain portable.  We could try and have
multiple code paths for some stuff, with higher speed "aligned" cases when
possible but that complicates the code alot and I am not sure there would
be much speed benefit.

I would add that speed in processing the tag directory itself is really
not that big an issue compared to loading referenced tag data, and of
course the actual image data.

That said, other libraries or TIFF writers might be able to benefit
somewhat from proper alignment.

I would also caution that bulking up the directory entry size alot will
add non-trivially to the bulk of very small TIFF images which can already
be dominated by the directory stuff.  Of course, very small images is not
generally handled via TIFF. I would be more concerned about this for formats
like PNG that might be widely used for stuff like icons.

On some of the issues like 32-bit datatypes where concepts about complex
data types being introduced.  I feel like we are stepping towards stuff
that could hugely complicate our effort.  In my mind, BigTIFF is about a
near-minimal extension to TIFF to support very large images.  I have seen
lots of image format specification efforts go off the rails in an effort
to be over general and I hope our minor revision to support big files
won't fall into that sort of second-system effect.

Best regards,
-- 
---------------------------------------+--------------------------------------
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

_______________________________________________
Tiff mailing list
Tiff@remotesensing.org
http://xserve.flids.com/mailman/listinfo/tiff
