Return-Path: <tiff-bounces@remotesensing.org>
Received: from inmx007.isp.belgacom.be (inmx007.isp.belgacom.be [195.238.3.89])
        by mailst034.isp.belgacom.be (8.12.11/8.12.11/Skynet-MAILSTORE-2.14) with ESMTP id i92GXBDI006278
        for <joris.at.lebbeke@skynet.be>; Sat, 2 Oct 2004 18:33:11 +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 inmx007.isp.belgacom.be (8.12.11/8.12.11/Skynet-IN-2.32) with ESMTP id i92GX2Tw004306
        for <joris.at.lebbeke@skynet.be>; Sat, 2 Oct 2004 18:33:03 +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 319E6348BA5; Sat,  2 Oct 2004 12:32:44 -0400 (EDT)
X-Original-To: tiff@remotesensing.org
Delivered-To: tiff@remotesensing.org
Received: from ahk.pu.ru (ahk.pu.ru [193.124.85.198])
	by xserve.flids.com (Postfix) with ESMTP id CDD1F348B80
	for <tiff@remotesensing.org>; Sat,  2 Oct 2004 12:32:40 -0400 (EDT)
Received: from wg.pu.ru (wg.pu.ru [193.124.85.219])
	by ahk.pu.ru (8.12.11/8.12.9) with ESMTP id i92GWdoL098876
	for <tiff@remotesensing.org>; Sat, 2 Oct 2004 20:32:39 +0400 (MSD)
	(envelope-from dron@ak4719.spb.edu)
Received: (from uucp@localhost)
	by wg.pu.ru (8.9.1a/8.9.1) with UUCP id QAA15526
	for tiff@remotesensing.org; Sat, 2 Oct 2004 16:32:39 GMT
Received: from ak4719.spb.edu (localhost [127.0.0.1])
	by ak4719.spb.edu (8.12.11/8.12.11/Debian-5) with ESMTP id
	i92G75rL010565
	for <tiff@remotesensing.org>; Sat, 2 Oct 2004 20:07:05 +0400
Received: (from dron@localhost)
	by ak4719.spb.edu (8.12.11/8.12.11/Debian-5) id i92G75WX010562
	for tiff@remotesensing.org; Sat, 2 Oct 2004 20:07:05 +0400
From: Andrey Kiselev <dron@ak4719.spb.edu>
Date: Sat, 2 Oct 2004 20:07:05 +0400
To: tiff@remotesensing.org
Subject: Re: [Tiff] quad-tile
Message-ID: <20041002160705.GE2582@ak4719.spb.edu>
Mail-Followup-To: tiff@remotesensing.org
References: <20041002141605.GC12254@ak4719.spb.edu>
	<001501c4a891$4f7e5460$c008f151@dfgrrxsknr4e>
	<Pine.SOC.4.60.0410021028050.2727@blade.simplesystems.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.SOC.4.60.0410021028050.2727@blade.simplesystems.org>
X-GnuPG-Key: http://www.srces.spb.org/dron/export.home.key
X-Face: "t+se9s~+y~[XUH]L|pmeO3Pt/Q@DNv**S, d@_1-C=}/,
	c%<3Qp]eu!ok<"2lYJm$!9qVcg F?7o*L; |$`6|Q|>Rt-cU%2_y@6tQ|`!Li}TsvZvEKx;
	>fuY=fc(=sX^`7Wmw8%SsR`AvM$a; 0U/eN\ P?B\FTyqD, 0np$U2!*'z_4D,
	VPlFf?bN0&zYf"zF0s!7Tl7?$we)xD0@lL>[h|8bhys0i.g|zLnu@C
	Ti@d]i=[!:j1CB\5/TF[m]`lfHfaqSN[0qn@T3zeosV/[LAss{@p_?],x*j8P_9t[}uHD^X-;
	j~\M! gyTly;fj`}&Y~i{<#bN.#QmkE}#T`dxP.I1\.)_MEN{@#W
User-Agent: Mutt/1.5.6+20040722i
X-Virus-Scanned: clamd / ClamAV version 0.75-1, clamav-milter version 0.75c
	on ak4719
X-Virus-Status: Clean
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: b14df7840b207b78445838b9b393f320

On Sat, Oct 02, 2004 at 10:41:39AM -0500, Bob Friesenhahn wrote:
> >- Closed-circuit testing is a tiny bit problematic when lossy storage
> >is involved. I'm not just thinking jpeg, even mere YCbCr subsampled
> >images, whatever compression scheme, are lossy. This tiny problem can
> >perhaps be solved by having the data include tolerance levels for the
> >closed-circuit testing?
> 
> For many of GraphicsMagick's tests we use an image comparison function
> which computes statistical error values.  For algorithms which should
> not produce error, the allowed error is zero, but for algorithms which
> produce error (e.g. JPEG) we manually inspect the result to ensure
> that it seems ok, and then set the maximum allowed error value to
> slighly higher than the actual result.  The error values include the
> maximum pixel error (in case a single pixel is wrong), and the total
> mean error.
> 
> Provided that the libtiff test suite provides an image compare
> function, the allowed degree of error may be included with the test
> specification.

Good idea. I think we can go this way too.

> For operations which must always produce a certain result (the case
> for most libtiff operations), we use a checksum (SHA-128) and compare
> the resulting checksum with a checksum included with the test.  This
> is a very solid way to prepare a test, but is a bit tedious since each
> result must be validated by the person who writes the test.

This approach is used by Frank for the GDAL test suite and it will be
used in libtiff when we will connect the external image sets to the
tests.

						Andrey

-- 
Andrey V. Kiselev
Home phone:  +7 812 5274898  ICQ# 26871517
_______________________________________________
Tiff mailing list
Tiff@remotesensing.org
http://xserve.flids.com/mailman/listinfo/tiff
