Return-Path: <awaresystems.be+caf_=filtered=awaresystems.be@gmail.com>
Delivered-To: filtered@awaresystems.be
Received: from mx-r.one.com (mx-r.one.com [91.198.169.249])
	by mail6.local (Postfix) with ESMTP id 2331D80150202
	for <filtered@awaresystems.be>; Tue, 18 Dec 2012 22:50:12 +0100 (CET)
X-Virus-Scanned: by one.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
Received-SPF: pass (mx-r: domain of awaresystems.be+caf_=filtered=awaresystems.be@gmail.com designates 209.85.212.54 as permitted sender)
X-Greylist: whitelisted by SQLgrey-1.8.0-rc2
Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54])
	by mx-r.one.com (Postfix) with ESMTP id AF0535363A3
	for <filtered@awaresystems.be>; Tue, 18 Dec 2012 21:50:11 +0000 (UTC)
Received: by mail-vb0-f54.google.com with SMTP id l1so1529024vba.13
        for <filtered@awaresystems.be>; Tue, 18 Dec 2012 13:50:11 -0800 (PST)
X-Received: by 10.59.6.70 with SMTP id cs6mr5494975ved.60.1355867410955;
        Tue, 18 Dec 2012 13:50:10 -0800 (PST)
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.144.166 with SMTP id sn6csp204162veb;
        Tue, 18 Dec 2012 13:50:10 -0800 (PST)
X-Received: by 10.52.17.208 with SMTP id q16mr4828202vdd.46.1355867408308;
        Tue, 18 Dec 2012 13:50:08 -0800 (PST)
Received-SPF: neutral (google.com: 91.198.169.57 is neither permitted nor denied by best guess record for domain of tiff-bounces@lists.maptools.org) client-ip=91.198.169.57;
Received: by 10.230.89.149 with POP3 id e21mf915898vbm.25;
        Tue, 18 Dec 2012 13:50:07 -0800 (PST)
X-Gmail-Fetch-Info: info@awaresystems.be 1 pop.awaresystems.be 110 info@awaresystems.be
Delivered-To: info@awaresystems.be
Received: from mx-j.one.com (mx-j.one.com [91.198.169.57])
	by mail6.local (Postfix) with ESMTP id C1E5180150202
	for <info@awaresystems.be>; Tue, 18 Dec 2012 22:37:20 +0100 (CET)
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0-rc2
Received: from lists.maptools.org (ks365428.kimsufi.com [94.23.4.142])
	by mx-j.one.com (Postfix) with ESMTP id 8B67F61A599
	for <info@awaresystems.be>; Tue, 18 Dec 2012 21:37:20 +0000 (UTC)
Received: from [10.1.0.241] (localhost.localdomain [127.0.0.1])
	by lists.maptools.org (Postfix) with ESMTP id 8576F35C032;
	Tue, 18 Dec 2012 16:35:58 -0500 (EST)
Received: from bay0-omc1-s7.bay0.hotmail.com (bay0-omc1-s7.bay0.hotmail.com
	[65.54.190.18])
	by lists.maptools.org (Postfix) with ESMTP id A93DE35C032
	for <tiff@lists.maptools.org>; Tue, 18 Dec 2012 16:27:57 -0500 (EST)
Received: from BAY002-W50 ([65.54.190.60]) by bay0-omc1-s7.bay0.hotmail.com
	with Microsoft SMTPSVC(6.0.3790.4675); 
	Tue, 18 Dec 2012 13:27:55 -0800
X-EIP: [AB+JXUy84uwuT0JWY9DPHOjlssKEb2iy]
X-Originating-Email: [rwong_002@hotmail.com]
Message-ID: <BAY002-W50C16F955F5E31E3659271C1310@phx.gbl>
From: Ryan Wong <rwong_002@hotmail.com>
To: Bob Friesenhahn <bfriesen@simple.dallas.tx.us>, Tom Lane
	<tgl@sss.pgh.pa.us>
Date: Tue, 18 Dec 2012 13:27:55 -0800
Importance: Normal
In-Reply-To: <alpine.GSO.2.01.1212181408010.28949@freddy.simplesystems.org>
References: <12006.1355856797@sss.pgh.pa.us>,
	<alpine.GSO.2.01.1212181257220.28949@freddy.simplesystems.org>,
	<12547.1355858560@sss.pgh.pa.us>,
	<alpine.GSO.2.01.1212181408010.28949@freddy.simplesystems.org>
MIME-Version: 1.0
X-OriginalArrivalTime: 18 Dec 2012 21:27:55.0767 (UTC)
	FILETIME=[8B55C870:01CDDD66]
Cc: libtiff mailing list <tiff@lists.maptools.org>
Subject: Re: [Tiff] More problems with libjpeg cross-version differences
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: multipart/mixed; boundary="===============1387212845=="
Mime-version: 1.0
Sender: tiff-bounces@lists.maptools.org
Errors-To: tiff-bounces@lists.maptools.org

--===============1387212845==
Content-Type: multipart/alternative;
	boundary="_36341293-ba21-4679-8042-a3a0aa833ed0_"

--_36341293-ba21-4679-8042-a3a0aa833ed0_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> Subject: Re: [Tiff] More problems with libjpeg cross-version differences
>=20
> On Tue=2C 18 Dec 2012=2C Tom Lane wrote:
> >
> > Yeah.  I was intending to take the two known values and allow a couple
> > counts slop on either side of that range.  We might have to expand
> > the ranges in future=2C but it would be a pretty painless thing to do
> > compared to trying to identify the exact expected behavior from
> > the library's available version info.
>=20
> The sloppy approach is fine with me.  The main intent is to be a=20
> sanity check rather than to assert absolute conformity.

A typical approach (though not necessary scientific nor psycho-visually val=
id) for comparing the outputs of two image decoders from the same input ima=
ge is histogram of pixel differences.
This is how histogram of pixel differences works:
For each row of pixels    For each pixel in the row        Compare RGB valu=
es from first decoder with the second decoder        Take the absolute valu=
e of difference (scaled between 0 and 255)        Increment the correspondi=
ng bin in a 256-bin histogram
After obtaining the histogram=2C a performance curve can be obtained for ea=
ch RGB difference bound. Namely=2C y =3D f(x) is the fraction of pixels tha=
t have RGB difference exceeding x quantization steps (x =3D from 0 to 255).
The test code can then pick a few test points on the curve and compare agai=
nst hard-coded tolerance thresholds.
This simpler approach would be sufficient if the only source of RGB differe=
nce comes from rounding errors between two independent implementations of d=
ecoders.
rwong_002@hotmail.com 		 	   		  =

--_36341293-ba21-4679-8042-a3a0aa833ed0_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style><!--
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 12pt=3B
font-family:Calibri
}
--></style></head>
<body class=3D'hmmessage'><div dir=3D'ltr'><span style=3D"font-size: 12pt=
=3B">&gt=3B Subject: Re: [Tiff] More problems with libjpeg cross-version di=
fferences</span><br><div>&gt=3B <br>&gt=3B On Tue=2C 18 Dec 2012=2C Tom Lan=
e wrote:<br>&gt=3B &gt=3B<br>&gt=3B &gt=3B Yeah.  I was intending to take t=
he two known values and allow a couple<br>&gt=3B &gt=3B counts slop on eith=
er side of that range.  We might have to expand<br>&gt=3B &gt=3B the ranges=
 in future=2C but it would be a pretty painless thing to do<br>&gt=3B &gt=
=3B compared to trying to identify the exact expected behavior from<br>&gt=
=3B &gt=3B the library's available version info.<br>&gt=3B <br>&gt=3B The s=
loppy approach is fine with me.  The main intent is to be a <br>&gt=3B sani=
ty check rather than to assert absolute conformity.<br><br></div><div><div>=
<span style=3D"font-size: 12pt=3B">A typical approach (though not necessary=
 scientific nor psycho-visually valid)&nbsp=3B</span></div><div><span style=
=3D"font-size: 12pt=3B">for comparing the&nbsp=3B</span><span style=3D"font=
-size: 12pt=3B">outputs of two image decoders from the same input image&nbs=
p=3B</span></div><div><span style=3D"font-size: 12pt=3B">is histogram of pi=
xel differences.</span></div><div><br></div><div>This is how histogram of p=
ixel differences works:</div><div><br></div><div>For each row of pixels</di=
v><div>&nbsp=3B &nbsp=3B For each pixel in the row</div><div>&nbsp=3B &nbsp=
=3B &nbsp=3B &nbsp=3B Compare RGB values from first decoder with the second=
 decoder</div><div>&nbsp=3B &nbsp=3B &nbsp=3B &nbsp=3B Take the absolute va=
lue of difference (scaled between 0 and 255)</div><div>&nbsp=3B &nbsp=3B &n=
bsp=3B &nbsp=3B Increment the corresponding bin in a 256-bin histogram</div=
><div><br></div><div>After obtaining the histogram=2C a performance curve c=
an be obtained for each&nbsp=3B</div><div>RGB difference bound. Namely=2C y=
 =3D f(x) is the fraction of pixels that have RGB&nbsp=3B</div><div>differe=
nce exceeding x quantization steps (x =3D from 0 to 255).</div><div><br></d=
iv><div>The test code can then pick a few test points on the curve and comp=
are against&nbsp=3B</div><div>hard-coded tolerance thresholds.</div><div><b=
r></div><div>This simpler approach would be sufficient if the only source o=
f RGB difference&nbsp=3B</div><div>comes&nbsp=3B<span style=3D"font-size: 1=
2pt=3B">from rounding errors between two independent implementations of dec=
oders.</span></div><div><br></div></div><div>rwong_002@hotmail.com</div> 		=
 	   		  </div></body>
</html>=

--_36341293-ba21-4679-8042-a3a0aa833ed0_--

--===============1387212845==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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