Received: from mailgate001.isp.belgacom.be (mailgate001.isp.belgacom.be [195.238.6.86])
	by maildelivery020.isp.belgacom.be (Postfix) with ESMTP id 652617AC017
	for <joris.at.lebbeke@skynet.be>; Fri, 11 Jan 2008 08:53:38 +0100 (CET)
Received: from r153.dmsolutions.ca (HELO duke.maptools.org) ([209.217.116.153])
  by in.mx.skynet.be with ESMTP; 11 Jan 2008 08:53:37 +0100
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 m0B7cvLb016415;
	Fri, 11 Jan 2008 02:39:40 -0500
Received: from nelson.telenet-ops.be (nelson.telenet-ops.be [195.130.133.66])
	by duke.maptools.org (8.12.11/8.12.10) with ESMTP id m0B7cTiC016402
	for <tiff@lists.maptools.org>; Fri, 11 Jan 2008 02:38:30 -0500
Received: from localhost (localhost.localdomain [127.0.0.1])
	by nelson.telenet-ops.be (Postfix) with SMTP id D9B6C5003B;
	Fri, 11 Jan 2008 08:38:27 +0100 (CET)
Received: from katjad31f0d374 (d54C5897B.access.telenet.be [84.197.137.123])
	by nelson.telenet-ops.be (Postfix) with SMTP id 0550F5000A;
	Fri, 11 Jan 2008 08:38:26 +0100 (CET)
Message-ID: <004701c85424$f45eaba0$7b89c554@katjad31f0d374>
From: "Joris Van Damme \(AWare Systems\)" <joris.at.lebbeke@skynet.be>
To: "Bob Friesenhahn" <bfriesen@simple.dallas.tx.us>,
        "Nikhil Shirahatti" <shirahatti@gmail.com>
References: <fb91ffe0801101103o3addbc5bhd6fb7234fbef1216@mail.gmail.com>
	<Pine.SOC.4.64.0801101531190.2557@freddy.simplesystems.org><fb91ffe0801101340g1ea9c156h11b53e0d1aa7a03e@mail.gmail.com>
	<Pine.SOC.4.64.0801101554340.2557@freddy.simplesystems.org>
Subject: Re: [Tiff] LibTiff..Reading partial strips
Date: Fri, 11 Jan 2008 08:35:08 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
	reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
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.000029dc
X-MSP-STORE: Fri, 11 Jan 2008 08:53:38 +0100
Status:   

Bob,

Bob Friesenhahn wrote:
> > I havent tried it..but the cautionary note that " It is not always
> > possible to do so due to decompression constraints" scares me. I
> > also read on the archive that "that *strip* *chopping* only works
> > for uncompressed  IFDs.". How common(or uncommon) is this? When
> > would one use compressed IFD's? The tiff's we get can be compressed or 
> > uncompressed formats and we
> > have to support them all. :)
>
> It is quite likely that other folks here know a lot more about this
> than I do so hopefully they will chime in.  I don't know what a
> compressed IFD might be since and IFD is just a structure.

It's a misnomer. The intention there was to refer to image compression as 
stated in the IFD. Strip-chopping works only on the majority of stripped 
uncompressed images (i.e. IFDs with Compression tag set to None), it works 
on no compressed images nor tiles images.

> My impression is that libtiff decompresses into a buffer and then uses
> part (or all) of that buffer.

Strip-chopping works differently. It patches up relevant tags (RowsPerStrip, 
StripOffsets and StripByteCounts) so as to make it seem there's a lot of 
small strips rather then a smaller number of huge strips. This can be done 
due to the predictable offset of uncompressed data.

> Some compression algorithms/options
> either require decompressing a huge amount of data (e.g. the whole
> strip), or else using simultaneous streaming decompression at the same
> time that data is consumed by the rest of the library.  If libtiff
> decompresses in blocks and does not stream (as I suspect) then
> sometimes it will need to decompress the entire strip before it can be
> used.  G4 FAX compression with a strip-per-page is likely a good
> example of that.

You suspect correctly. LibTiff works largely on with complete buffers, 
rather then maximum streaming. That makes it unsuitable for large 
strips/tiles on small machines.

A streaming approach is often much more scalable. But it's a completely 
different design, and it needs to be consistent with design of colour 
conversion and other application layers.

As to the original question, it's often hard to do real 'regional decoding'. 
It so happens I'm currently working on that exact concept in my JPEG codec. 
The problem is that many compression schemes, by their very nature, don't 
support ways to locate the data directly from the pixel indexes. It is often 
necessary to scan through the data and do at least the very first steps of 
decoding so as to derive the offsets of the region of interest. In the JPEG 
scheme, this very first step that needs to be done in as far as RST markers 
don't come to the rescue, is Huffman decoding. Whilst it cannot be avoided, 
it's still a lot faster to do Huffman decoding for positioning only (without 
storage of results that is), compared to a full decompression (Huffman, 
dequantization, inverse DCT, desubsampling, and possibly colour conversion). 
But it does require specific support on the part of the decoder.

LibTiff subcodecs just aren't designed to do such 
first-step-decoding-for-positioning-only, so you're out of luck unless 
you're willing to redesign and rewrite them.



Best regards,

Joris Van Damme
info@awaresystems.be
http://www.awaresystems.be/
Download your free TIFF tag viewer for windows here:
http://www.awaresystems.be/imaging/tiff/astifftagviewer.html

_______________________________________________
Tiff mailing list: Tiff@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
