Return-Path: <awaresystems.be+caf_=filtered=awaresystems.be@gmail.com>
X-Original-To: filtered@awaresystems.be
Delivered-To: filtered@awaresystems.be
Received: from mx-k.one.com (mx-k.one.com [91.198.169.58])
	by mail9.b-one.net (Postfix) with ESMTP id 43211400E3C
	for <filtered@awaresystems.be>; Sat, 28 Apr 2012 18:42:48 +0200 (CEST)
X-Virus-Scanned: by one.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
Received-SPF: pass (mx-k: domain of awaresystems.be+caf_=filtered=awaresystems.be@gmail.com designates 209.85.160.48 as permitted sender)
X-Greylist: whitelisted by SQLgrey-1.8.0-rc2
Received: from mail-pb0-f48.google.com (mail-pb0-f48.google.com [209.85.160.48])
	by mx-k.one.com (Postfix) with ESMTP id B4056903CCA
	for <filtered@awaresystems.be>; Sat, 28 Apr 2012 16:42:47 +0000 (UTC)
Received: by pbbjt11 with SMTP id jt11so2346380pbb.21
        for <filtered@awaresystems.be>; Sat, 28 Apr 2012 09:42:46 -0700 (PDT)
Received: by 10.68.237.8 with SMTP id uy8mr3887907pbc.55.1335631366760;
        Sat, 28 Apr 2012 09:42:46 -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.142.164.16 with SMTP id m16csp26512wfe;
        Sat, 28 Apr 2012 09:42:45 -0700 (PDT)
Received: by 10.68.219.72 with SMTP id pm8mr13738700pbc.116.1335630889145;
        Sat, 28 Apr 2012 09:34:49 -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.57 as permitted sender) client-ip=91.198.169.57;
Received: by 10.130.152.9 with POP3 id z9mf3381279dad.30;
        Sat, 28 Apr 2012 09:34:48 -0700 (PDT)
X-Gmail-Fetch-Info: info@awaresystems.be 1 pop.awaresystems.be 110 info@awaresystems.be
X-Original-To: info@awaresystems.be
Delivered-To: info@awaresystems.be
Received: from mx-j.one.com (mx-j.one.com [91.198.169.57])
	by mail9.b-one.net (Postfix) with ESMTP id A452C400411
	for <info@awaresystems.be>; Sat, 28 Apr 2012 18:32:25 +0200 (CEST)
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
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-j.one.com (Postfix) with ESMTP id 3D38E4759AFA
	for <info@awaresystems.be>; Sat, 28 Apr 2012 16:32:25 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by lists.maptools.org (Postfix) with ESMTP id 1B7971EDB1C;
	Sat, 28 Apr 2012 11:30:37 -0500 (EST)
Received: from blu0-omc3-s3.blu0.hotmail.com (blu0-omc3-s3.blu0.hotmail.com
	[65.55.116.78])
	by lists.maptools.org (Postfix) with ESMTP id C29A81EDB1C
	for <tiff@lists.maptools.org>; Sat, 28 Apr 2012 11:26:36 -0500 (EST)
Received: from BLU165-W44 ([65.55.116.72]) by blu0-omc3-s3.blu0.hotmail.com
	with Microsoft SMTPSVC(6.0.3790.4675); 
	Sat, 28 Apr 2012 09:26:35 -0700
Message-ID: <BLU165-W444C10FBC1A3AC4ED6FA58E12A0@phx.gbl>
X-Originating-IP: [68.52.82.129]
From: Charles Auer <bumble731@msn.com>
To: <info@awaresystems.be>, <tiff@lists.maptools.org>
Date: Sat, 28 Apr 2012 16:26:35 +0000
Importance: Normal
MIME-Version: 1.0
X-OriginalArrivalTime: 28 Apr 2012 16:26:35.0495 (UTC)
	FILETIME=[ADFDB770:01CD255B]
Subject: Re: [Tiff] =?windows-1256?q?YCbCr/JPEG_issue_in_4=2E0=2E1=FE?=
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="===============1742365557=="
Mime-version: 1.0
Sender: tiff-bounces@lists.maptools.org
Errors-To: tiff-bounces@lists.maptools.org

--===============1742365557==
Content-Type: multipart/alternative;
	boundary="_1ee001fd-d5d8-4118-8c31-875f80a63358_"

--_1ee001fd-d5d8-4118-8c31-875f80a63358_
Content-Type: text/plain; charset="windows-1256"
Content-Transfer-Encoding: 8bit








SORRY.  I reversed compression = 6 and compression = 7 on the previous post. Joris: Well, back to the bug reading JPEG (compression = 7) compressed images using Libtiff 4.0, the problem is only evident if you read the subsampled YCbCr data directly, doing resampling and color conversion yourself. For example, subsampling = [ 2, 2 ] data should look like this: Y Y Y Y Cb Cr Y Y Y Y Cb Cr Y Y Y Y Cb CrY Y Y Y Cb Cr Y Y Y Y Cb Cr Y Y Y Y Cb Cr
Y Y Y Y Cb Cr Y Y Y Y Cb Cr Y Y Y Y Cb Cr
but instead you get this: Y Y Y Y Cb Cr Y Y Y Y Cb Cr Y Y Y Y Cb Cr 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0Y Y Y Y Cb Cr Y Y Y Y Cb Cr Y Y Y Y Cb Cr 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Y Y Y Y Cb Cr Y Y Y Y Cb Cr Y Y Y Y Cb Cr 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
You can still recover the image by ignoring the zeroes and the error message. As a matter of interest, Joris, OJPEG (compression = 6) data are read correctly.  Rewriting tif_ojpeg.c was a tremendous contribution that you made to Libtiff, by the way. Also, I made a set of YCbCr test images with all possible subsampling values ( [ 1, 1 ], [ 1 , 2 ], [ 1, 4 ], [ 2, 1 ], [ 2, 2 ], [2, 4 ], [ 4, 1 ], [ 4, 2 ], and [ 4, 4 ] ), both uncompressed and LZW compressed, and all of these images are read correctly.  The problem appears isolated to JPEG (compression = 7) compressed images. The easiest work-around right now to handle JPEG compressed images with Libtiff 4.0 is either: 1. Use TIFFReadRGBAImage 2. Use TIFFReadEncodedStrip or TIFFReadEncodedTile with JPEGCOLORMODE = 1 Of course, both of these methods output RGB colors. Charles
 		 	   		  
--_1ee001fd-d5d8-4118-8c31-875f80a63358_
Content-Type: text/html; charset="windows-1256"
Content-Transfer-Encoding: 8bit

<html>
<head>
</head>
<body class='hmmessage'><div dir='ltr'>


<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
<div dir="ltr">


<p style="margin-bottom: 0in;">SORRY.&nbsp; I reversed compression = 6 and compression = 7 on the previous post.</p><p style="margin-bottom: 0in;">&nbsp;</p><p style="margin-bottom: 0in;">Joris:</p><p style="margin-bottom: 0in;"> </p><p style="margin-bottom: 0in;">Well, back to the bug reading JPEG (compression = 7) compressed images using Libtiff 4.0, the problem is only evident if you read the subsampled YCbCr data directly, doing resampling and color conversion yourself.</p><p style="margin-bottom: 0in;">&nbsp;</p><p style="margin-bottom: 0in;">For example, subsampling = [ 2, 2 ] data should look like this:</p><p style="margin-bottom: 0in;">&nbsp;</p><p style="margin-bottom: 0in;">Y Y Y Y Cb Cr Y Y Y Y Cb Cr Y Y Y Y Cb Cr</p>Y Y Y Y Cb Cr Y Y Y Y Cb Cr Y Y Y Y Cb Cr<br>Y Y Y Y Cb Cr Y Y Y Y Cb Cr Y Y Y Y Cb Cr<br><p style="margin-bottom: 0in;">but instead you get this:</p><p style="margin-bottom: 0in;">&nbsp;</p><p style="margin-bottom: 0in;">Y Y Y Y Cb Cr Y Y Y Y Cb Cr Y 
 Y Y Y Cb Cr 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0</p>Y Y Y Y Cb Cr Y Y Y Y Cb Cr Y Y Y Y Cb Cr 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0<br>Y Y Y Y Cb Cr Y Y Y Y Cb Cr Y Y Y Y Cb Cr 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0<br><p style="margin-bottom: 0in;">You can still recover the image by ignoring the zeroes and the error message.</p><p style="margin-bottom: 0in;">&nbsp;</p><p style="margin-bottom: 0in;">As a matter of interest, Joris, OJPEG (compression = 6) data are read correctly.  Rewriting tif_ojpeg.c was a tremendous contribution that you made to Libtiff, by the way.</p><p style="margin-bottom: 0in;"> </p><p style="margin-bottom: 0in;">Also, I made a set of YCbCr test images with all possible subsampling values ( [ 1, 1 ], [ 1 , 2 ], [ 1, 4 ], [ 2, 1 ], [ 2, 2 ], [2, 4 ], [ 4, 1 ], [ 4, 2 ], and [ 4, 4 ] ), both uncompressed and LZW compressed, and all of these images are read correctly.  The problem appears isolated to JPEG (compression = 7) compressed images.</p><p style="margi
 n-bottom: 0in;">&nbsp;</p><p style="margin-bottom: 0in;">The easiest work-around right now to handle JPEG compressed images with Libtiff 4.0 is either:</p><p style="margin-bottom: 0in;">&nbsp;</p><p style="margin-bottom: 0in;">1. Use TIFFReadRGBAImage</p><p style="margin-bottom: 0in;">&nbsp;</p><p style="margin-bottom: 0in;">2. Use TIFFReadEncodedStrip or TIFFReadEncodedTile with JPEGCOLORMODE = 1</p><p style="margin-bottom: 0in;">&nbsp;</p><p style="margin-bottom: 0in;">Of course, both of these methods output RGB colors.</p><p style="margin-bottom: 0in;">&nbsp;</p><p style="margin-bottom: 0in;">Charles</p></div>
 		 	   		  </div></body>
</html>
--_1ee001fd-d5d8-4118-8c31-875f80a63358_--

--===============1742365557==
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/
--===============1742365557==--
