Return-Path: <tiff-bounces@lists.maptools.org>
X-Original-To: info@awaresystems.be
Delivered-To: info@awaresystems.be
Received: from mx-j.b-one.net (mx-j.one.com [91.198.169.57])
	by mail9.b-one.net (Postfix) with ESMTP id B7839400F7E
	for <info@awaresystems.be>; Mon,  6 Jun 2011 17:59:45 +0200 (CEST)
Received: by mx-j.b-one.net (Postfix, from userid 106)
	id A7B412186645; Mon,  6 Jun 2011 17:59:31 +0200 (CEST)
X-Virus-Scanned: by one.com
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.4
Received: from lists.maptools.org (lists.maptools.org [65.39.174.144]) by
 mx-j.b-one.net (Postfix) with ESMTP id 021FD20B0087 for
 <info@awaresystems.be>; Mon,  6 Jun 2011 17:59:30 +0200 (CEST)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by
 lists.maptools.org (Postfix) with ESMTP id F163486F64; Mon,  6 Jun 2011
 10:57:27 -0500 (EST)
Received: from hydra.rus.uni-stuttgart.de (hydra.rus.uni-stuttgart.de
 [129.69.1.55]) by lists.maptools.org (Postfix) with ESMTP id E7E9B86EA2 for
 <tiff@lists.maptools.org>; Sun,  5 Jun 2011 07:38:39 -0500 (EST)
Received: from localhost (localhost [127.0.0.1]) by
 hydra.rus.uni-stuttgart.de (Postfix) with ESMTP id B7CA912B8A2 for
 <tiff@lists.maptools.org>; Sun,  5 Jun 2011 14:38:38 +0200 (CEST)
Received: from hydra.rus.uni-stuttgart.de ([127.0.0.1]) by localhost
 (hydra.rus.uni-stuttgart.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP
 id q+ftPVMcF5BP for <tiff@lists.maptools.org>; Sun,  5 Jun 2011 14:38:38
 +0200 (CEST)
Received: from uni-stuttgart.de (mbox.uni-stuttgart.de [129.69.1.9]) by
 hydra.rus.uni-stuttgart.de (Postfix) with ESMTP id 44BEE12B864 for
 <tiff@lists.maptools.org>; Sun,  5 Jun 2011 14:38:38 +0200 (CEST)
Received: from [141.58.47.62] (account rusricht@rus.uni-stuttgart.de
 [141.58.47.62] verified) by uni-stuttgart.de (CommuniGate Pro SMTP 5.3.7)
 with ESMTPSA id 145931832 for tiff@lists.maptools.org; Sun, 05 Jun 2011
 14:38:37 +0200
Message-ID: <4DEB78CA.9060803@math.tu-berlin.de>
Date: Sun, 05 Jun 2011 14:38:34 +0200
From: Thomas Richter <thor@math.tu-berlin.de>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16)
 Gecko/20110505 Icedove/3.0.11
MIME-Version: 1.0
To: tiff@lists.maptools.org
Subject: [Tiff] Questions on TIFF LZW compression
X-BeenThere: tiff@lists.maptools.org
X-Mailman-Version: 2.1.9
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tiff-bounces@lists.maptools.org
Errors-To: tiff-bounces@lists.maptools.org

Hi folks,

would it be possible that some of the knowledgeable people here help me 
understanding some details of the LZW compression
specified in the TIFF specs? I'm not asking about the compression itself 
which is clear enough, but rather its integration into the
TIFF specifications.

First, how does LZW compression work for images that are not 8 bits/pixel?
As far as I read the specs, the input to the LZW compression is the 
"raw" TIFF stripe buffer, but this leaves a couple of corner
cases open. I see that this type of compression works for any bit depth 
that divides eight, or is a multiple of eight, but what
happens for 10 bits per pixel images? Is LZW really applied to the 
bit-packed(!) input, or is the LZW algorithm applied to 16 bit
data, where 10 bits are packed (left-justified? right-justified?) into a 
16 bit word? In the former case, LZW will very unlikely give
much compression performance, of course.

What happens with 16 bit/pixel data? Is the input to the LZW compression 
big-endian or little-endian? Or does it depend on the
endian-ness of the TIFF file? I suspect the latter, but couldn't find 
any clear indicator of this.

What about the predictor mode (horizontal difference predictor). While 
there is no problem with overflow with 8 or 16 bit per pixel data,
what happens with 10 bit/pixel data, for example? While the specs don't 
spell this out, do I need to take the difference modulo 2^N, where
N is the bit-depths? Or modulo 2^M, where M is the bit-size of a 
"container" word, say 16 bits for 10 bit data? What happens if I encode
10 bit/pixel data with a predictor? Do I apply the predictor on the 
pixel values (sensible) or on the raw 8-bit values resulting from bit-
packing the 10-bit data into 8-bit containers (not very sensible, but 
not ruled out by the specs).

Can the predictor also be specified without LZW compression? It probably 
makes little sense then, but can - for example - the predictor
be combined with the Fax (CCITT, ITU) compression?

And finally, what about the predictor and tiles? Does the predictor 
predict across tile edges? The specs seem to indicate this, but this
would also imply that tiles cannot be decompressed independently. Is 
this really the purpose of prediction or are the specs incomplete
and should I stop prediction at tile boundaries (which makes sense if 
you want to retain the independence of the tiles).

Thanks a lot for your time!

Greetings,
     Thomas

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