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 i92FusVV019747
        for <joris.at.lebbeke@skynet.be>; Sat, 2 Oct 2004 17:56:54 +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 i92FucBB004548
        for <joris.at.lebbeke@skynet.be>; Sat, 2 Oct 2004 17:56:40 +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 657B834897E; Sat,  2 Oct 2004 11:56:16 -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 16B2634895B
	for <tiff@remotesensing.org>; Sat,  2 Oct 2004 11:56:13 -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 i92FuBFt049398
	for <tiff@remotesensing.org>; Sat, 2 Oct 2004 19:56:11 +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 PAA09937
	for tiff@remotesensing.org; Sat, 2 Oct 2004 15:56:11 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
	i92FbeHo007070
	for <tiff@remotesensing.org>; Sat, 2 Oct 2004 19:37:40 +0400
Received: (from dron@localhost)
	by ak4719.spb.edu (8.12.11/8.12.11/Debian-5) id i92Fbeuh007067
	for tiff@remotesensing.org; Sat, 2 Oct 2004 19:37:40 +0400
From: Andrey Kiselev <dron@ak4719.spb.edu>
Date: Sat, 2 Oct 2004 19:37:40 +0400
To: tiff@remotesensing.org
Subject: Re: [Tiff] quad-tile
Message-ID: <20041002153740.GA2582@ak4719.spb.edu>
Mail-Followup-To: tiff@remotesensing.org
References: <20041002141605.GC12254@ak4719.spb.edu>
	<001501c4a891$4f7e5460$c008f151@dfgrrxsknr4e>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <001501c4a891$4f7e5460$c008f151@dfgrrxsknr4e>
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: 8f6331bb10bedeec605d702a2be7593a

Hi Joris,

On Sat, Oct 02, 2004 at 05:05:50PM +0200, Joris wrote:
> > The test suite I'm working on right now doesn't use the external image
> > set. All test images are generated by the test cases from the internal
> > data arrays and being compared with that images after reading the files
> > back. Any help will be greatly appreciated.
> 
> I'm not completely sure I understand. Do you mean sortoff closed-circuit
> testing, like this
> - for all encoding schemes/parameters
>     - generating some testimage
>     - encoding it (to a temp file), with some encoding scheme/parameters
>     - decoding it (from a temp file)
>     - comparing it to original testimage
>     - if same, then library ok for this encoding scheme/parameters

Exactly, with except of one thing: my test code is very basic for now
and word "all" is not yet acceptable. :-) But even so small test suite
already helps me to found several bugs/oddities in the library.

> I guess you probably are, 'cause I can see how that can be an
> extremely nice auto test tool in the auto make schemes you're
> concerned with. Am I right?

You are absolutely right, there is a built-in support for such tests in
the autotools environment. We can run the tests after every change in
the library code to ensure that nothing is broken.

> If so, I think we might best be able to help each other by being
> somewhat complementary. The thing I am most concerned with, is that
> very first line in this scheme, the enumeration of all
> issues/schemes/parameters/whatever that set TIFF files apart, and that
> makes that some work with some decoders, and others don't. I'd like to
> enumerate that, think about all issues, document it, link it with the
> tag pages and vice versa, etc.
> 
> When I say 'enumeration', I am, as always, thinking raw data in any
> proprietary scheme, managed by on-the-fly written code, from which my
> code can assemble and maintain the HTML presentation of this data.
> Perhaps we ought to look at ways to integrate our schemes, having the
> data drive your closed-circuit loop. That would yield
> - very extensive closed-circuit libtiff testing
> - testimage suite generation by libtiff
> - the html index pages into this testimage suite, crossreferenced with
> tag pages etc

Mmm... I think I don't understand in details what do you mean. Do you
mean integrating the internal libtiff tests with the external data
sets?

> Two minor complications I foresee:
> - 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?

Yes, that is a problem I don't thinking too much. A lot of code should
be written before this problem becomes valuable and I'm sure some
good idea comes to us at some point.

> - I'm planning also stuff that LibTiff can't handle, most notably
> different bitdepths and different datatypes per channel. This tiny
> problem can perhaps be solved by having the data include a 'skip in
> LibTiff generation/closed-circuit-testing' flag?

Well, that is not a stuff for the test suite, it should go to Bugzilla
;-)

						Andrey

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