Return-Path: <awaresystems.be+caf_=filtered=awaresystems.be@gmail.com>
Delivered-To: filtered@awaresystems.be
Received: from mx-i.one.com (mx-i.one.com [91.198.169.56])
	by mail6.b-one.net (Postfix) with ESMTP id 50265801671FE
	for <filtered@awaresystems.be>; Thu, 12 Jul 2012 13:32:09 +0200 (CEST)
X-Virus-Scanned: by one.com
Received-SPF: pass (mx-i: domain of awaresystems.be+caf_=filtered=awaresystems.be@gmail.com designates 209.85.220.176 as permitted sender)
X-Greylist: whitelisted by SQLgrey-1.8.0-rc2
Received: from mail-vc0-f176.google.com (mail-vc0-f176.google.com [209.85.220.176])
	by mx-i.one.com (Postfix) with ESMTP id DD9051055095
	for <filtered@awaresystems.be>; Thu, 12 Jul 2012 11:32:08 +0000 (UTC)
Received: by vcbfl11 with SMTP id fl11so349394vcb.21
        for <filtered@awaresystems.be>; Thu, 12 Jul 2012 04:32:08 -0700 (PDT)
Received: by 10.52.143.73 with SMTP id sc9mr20635301vdb.46.1342092727588;
        Thu, 12 Jul 2012 04:32:07 -0700 (PDT)
X-Forwarded-To: filtered@awaresystems.be
X-Forwarded-For: awaresystems.be@gmail.com filtered@awaresystems.be
Delivered-To: awaresystems.be@gmail.com
Received: by 10.58.208.231 with SMTP id mh7csp83871vec;
        Thu, 12 Jul 2012 04:32:07 -0700 (PDT)
Received: by 10.220.228.193 with SMTP id jf1mr24915673vcb.73.1342092726583;
        Thu, 12 Jul 2012 04:32:06 -0700 (PDT)
Received-SPF: softfail (google.com: best guess record for domain of transitioning tiff-bounces@lists.maptools.org does not designate 91.198.169.56 as permitted sender) client-ip=91.198.169.56;
Received: by 10.230.202.193 with POP3 id ff1mf1040823vbb.23;
        Thu, 12 Jul 2012 04:32:06 -0700 (PDT)
X-Gmail-Fetch-Info: info@awaresystems.be 1 pop.awaresystems.be 110 info@awaresystems.be
Delivered-To: info@awaresystems.be
Received: from mx-i.one.com (mx-i.one.com [91.198.169.56])
	by mail6.b-one.net (Postfix) with ESMTP id 5804D8015020E
	for <info@awaresystems.be>; Thu, 12 Jul 2012 13:28:12 +0200 (CEST)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0-rc2
Received: from lists.maptools.org (lists.maptools.org [65.39.174.144])
	by mx-i.one.com (Postfix) with ESMTP id 0116BBC3CF6
	for <info@awaresystems.be>; Thu, 12 Jul 2012 11:28:11 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by lists.maptools.org (Postfix) with ESMTP id 683ED1EDB2D;
	Thu, 12 Jul 2012 06:26:58 -0500 (EST)
Received: from csmtp3.one.com (csmtp3.one.com [91.198.169.23])
	by lists.maptools.org (Postfix) with ESMTPS id 8E9951EDB2D
	for <tiff@lists.maptools.org>; Thu, 12 Jul 2012 06:17:15 -0500 (EST)
Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com
	[209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits))
	(No client certificate requested)
	by csmtp3.one.com (Postfix) with ESMTPSA id 7F4A724112A4
	for <tiff@lists.maptools.org>; Thu, 12 Jul 2012 11:17:13 +0000 (UTC)
Received: by vcqp1 with SMTP id p1so1882551vcq.3
	for <tiff@lists.maptools.org>; Thu, 12 Jul 2012 04:17:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.153.198 with SMTP id l6mr24810927vcw.2.1342091832282; Thu,
	12 Jul 2012 04:17:12 -0700 (PDT)
Received: by 10.58.208.231 with HTTP; Thu, 12 Jul 2012 04:17:12 -0700 (PDT)
In-Reply-To: <CADH5xWr=DgXrXhF2Fk+yxzckvNu6pzRdAYFuKU8-RrzRLUehaw@mail.gmail.com>
References: <CADH5xWqhDbnx+2ku-dCHm6ZkT_w6p2U4Y2Etph0RtCfNFfpnGg@mail.gmail.com>
	<alpine.GSO.2.01.1207111631180.14450@freddy.simplesystems.org>
	<CAAcuQeZn8LBmX6pTjUAN0082Maf2+mfGi6d6tNc0BU=k8dRv4A@mail.gmail.com>
	<CA+NZCsRyZvU2FoBBSycL6G5MEW-S=WsBKvPFyP1cwPKGxYvsiQ@mail.gmail.com>
	<CADH5xWrmR9wXaH_RPD6DDdR6x6ScXdDgPYVgc7j+cri8_en1XQ@mail.gmail.com>
	<CA+NZCsSMWUEk=pWmcvG+YKFOg4fDqw3B4=F3hTfONi7kH9ONmw@mail.gmail.com>
	<CADH5xWr=DgXrXhF2Fk+yxzckvNu6pzRdAYFuKU8-RrzRLUehaw@mail.gmail.com>
Date: Thu, 12 Jul 2012 13:17:12 +0200
Message-ID: <CA+NZCsSpERa2R9VYAMbLt2OaROxsMhqF3Z+9cjXZqdTxwv0JKA@mail.gmail.com>
From: "Joris Van Damme (AWare Systems)" <info@awaresystems.be>
To: Jorge Martin <jormarfe@gmail.com>, Tiff List <tiff@lists.maptools.org>
Subject: Re: [Tiff] Doubts about Strip and Tile Oriented read/write TIFF
	files
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="windows-1252"
Content-Transfer-Encoding: quoted-printable
Sender: tiff-bounces@lists.maptools.org
Errors-To: tiff-bounces@lists.maptools.org

Jorge,

> Yes, you are right. When you read the las strip, you only have to read 10
> lines, is this correct? And when you are writting this image, what you ha=
ve
> to do when writes the last strip?

I've quickly looked it up, so as to make sure I don't give you wrong
information based on my bad memory...

Quote from the specification, Section 15, Introduction, Padding:

<quote>
Boundary tiles are padded to the tile boundaries. For example, if
TileWidth is 64
and ImageWidth is 129, then the image is 3 tiles wide and 63 pixels of padd=
ing
must be added to fill the rightmost column of tiles. The same holds
for TileLength
and ImageLength. It doesn=92t matter what value is used for padding, becaus=
e good
TIFF readers display only the pixels defined by ImageWidth and ImageLength
and ignore any padded pixels. Some compression schemes work best if the pad=
ding
is accomplished by replicating the last column and last row instead of padd=
ing
with 0=92s.
<end quote>

So I do seem to remember the tiling situation correctly, except that
my preference for repetition of last valid color isn't as uniquely
mine as I remembered it, it is instead actually a recommendation in
the specification.

As is usual in the TIFF specification, due to its emphasis on
artificial 'subgroups' of TIFF rather then a correct emphasis on the
independent different steps and options in the encoding and decoding
process, one finds information in the most unlikely of places.
Information about the strip situation is in Section 3: Bilevel images,
Location of the data, RowsPerStrip:

<quote>
The number of rows in each strip (except possibly the last strip.)

For example, if ImageLength is 24, and RowsPerStrip is 10, then there are 3
strips, with 10 rows in the first strip, 10 rows in the second strip,
and 4 rows in the
third strip. (The data in the last strip is not padded with 6 extra
rows of dummy
data.)
<end quote>

So indeed I remembered correctly, though I probably explained badly.
The point is simply, when using strips rather then tiles, there is no
padding. (LibTiff may or may not require full-strip-sized buffers when
encoding and give you a full-strip-sized buffer when decoding, I don't
know, but in any case the method of padding that is applied to this
irrelevant part of the buffer for the last strip is unlikely to have
any impact in either direction.)


Best regards,

Joris Van Damme
AWare Systems
_______________________________________________
Tiff mailing list: Tiff@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
