Return-Path: <tiff-bounces@lists.maptools.org>
X-Original-To: info@awaresystems.be
Delivered-To: info@awaresystems.be
Received: from mx-j.b-one.net (mx-j.one.com [91.198.169.57])
	by mail9.b-one.net (Postfix) with ESMTP id D41B4400F7D
	for <info@awaresystems.be>; Thu,  9 Jun 2011 07:56:28 +0200 (CEST)
Received: by mx-j.b-one.net (Postfix, from userid 106)
	id C7CE95636E23; Thu,  9 Jun 2011 07:56:09 +0200 (CEST)
X-Virus-Scanned: by one.com
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.4
Received: from lists.maptools.org (lists.maptools.org [65.39.174.144]) by
 mx-j.b-one.net (Postfix) with ESMTP id 85E085636E09 for
 <info@awaresystems.be>; Thu,  9 Jun 2011 07:56:00 +0200 (CEST)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by
 lists.maptools.org (Postfix) with ESMTP id B8F9986EC7; Thu,  9 Jun 2011
 00:54:45 -0500 (EST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9])
 by lists.maptools.org (Postfix) with ESMTP id 9620486D13 for
 <tiff@lists.maptools.org>; Thu,  9 Jun 2011 00:34:59 -0500 (EST)
Received: from [192.168.0.102] (dslb-084-063-026-053.pools.arcor-ip.net
 [84.63.26.53]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis)
 id 0MTeTI-1Q475m1daK-00RCCg; Thu, 09 Jun 2011 07:34:58 +0200
Message-ID: <4DF05B7F.1050704@ar-kleinert.de>
Date: Thu, 09 Jun 2011 07:34:55 +0200
From: Andreas Kleinert <info@ar-kleinert.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.17)
 Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10
MIME-Version: 1.0
To: tiff@lists.maptools.org
References: <BAY158-W170B0C6DABD87D9EA768E9C1620@phx.gbl>
 <97DFD9D47C1D46FBB23463C62645B252@KAM6400>
In-Reply-To: <97DFD9D47C1D46FBB23463C62645B252@KAM6400>
X-Enigmail-Version: 1.1.1
X-Provags-ID: V02:K0:li7QexsyQs0jY8JJofTZZfavCFYfdWsCLzdhocPdxkO
 D8JVS1tvie6EPS2Nbxz2JqSY8yn3sC/BqhRBchczxHQjn2sra+
 C55lXJmyMeomwbBnkLzea4Eb8dQCUtWPNjfCM+8c9VaJNAzjO7
 SgN9WaddiPzIkMfhNGffkwEv5S97wB4jT/52aEbDFu4IpNVNjU
 xs0y1TRWwcjZ8gmXEHqH573Vfic7rVGsRBVWYXdE1Y=
Subject: Re: [Tiff] Patch for tif_ojpeg version 3.9.5
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="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tiff-bounces@lists.maptools.org
Errors-To: tiff-bounces@lists.maptools.org

Yes, as OJPEG is known to be broken (und thus deprecated) anyway,
it can't hurt to improve libtiff's capability to read out what
is there (and hopefully more easily allow to convert it to something
less broken)...

-------- Original Message  --------
Subject: Re: [Tiff] Patch for tif_ojpeg version 3.9.5
From: Kevin Myers <kmyers1@clearwire.net>
To: tiff@lists.maptools.org
Date: 09.06.2011 03:27

> I for one would certainly be very interested in these changes, if they can 
> be reasonably verified not to cause problems for anyone else.  The author's 
> description of what he has changed and why seems reasonable to me, but I 
> have not considered it in great detail.  However, I do work with some files 
> that currently fail to open properly using libtiff, and it sounds like these 
> changes might fix those problems.
> 
> ----- Original Message ----- 
> From: <rwong_002@hotmail.com>
> To: <tiff@lists.maptools.org>
> Sent: Wednesday, June 08, 2011 17:32
> Subject: [Tiff] Patch for tif_ojpeg version 3.9.5
> 
> 
> 
> Hello,
> 
> I have received some TIFF_OJPEG images that doesn't open in LibTIFF 3.9.5, 
> and I found that after some code changes in LibTIFF it could be opened. We 
> would like to know if anybody is interested in evaluating our changes, to 
> see if they are useful for inclusion into LibTIFF.
> Description of the problems found in my TIFF_OJPEG images:
> 
> 1. JPEGInterchangeFormat doesn't point to the exact start of a JPEG marker. 
> Instead, it points to the character "J" in the "JFIF" which is not a JPEG 
> marker itself, but a magic number inside the APP_0 segment.
> 
> 2. On the other hand, StripOffset points to the correct JPEG marker, SOI 
> (Start of Image, 0xFF 0xD8) as would be expected by LibTIFF.
> 
> 3. I found that LibTIFF leans toward JPEGInterchangeFormat when both tags 
> are present. So, one of my change is to try JPEGInterchangeFormat first (to 
> keep the same behavior as LibTIFF), and if it fails try StripOffset or 
> TileOffset for second chance. To make it faster, I do a quick test of the 
> first byte to see if it is 0xFF.
> 
> This is implemented by splitting the OJPEGReadHeaderInfoSec function into 
> two parts: the first part (keeping the same function name) is responsible 
> for trying both start addresses. The second part, in a new function named 
> OJPEGReadHeaderInfoSecStream, will take a start address and start parsing 
> the JPEG markers.
> 
> 4. The remaining problems with my TIFF_OJPEG images are related to 
> mismatches between what is stored in the TIFF IFD and the actual parameters 
> that are required to decode the JPEG datastream. There is already an "OJPEG 
> parameter correction routine" in LibTIFF, named "OJPEGSubsamplingCorrect". I 
> added more rules to fix the issues in my images. In particular, some images 
> have wrong BitsPerSample (e.g. 4 in a grayscale OJPEG image), wrong 
> SamplesPerPixel (e.g. 1 in a YCbCr OJPEG image or 3 in a grayscale OJPEG 
> image), and Photometric (using a color Photometric in a grayscale OJPEG 
> image or vice versa)
> 
> 5. Because TIFF calculates the memory buffer sizes based on the TIFF IFD 
> values, the "parameter correction" needs to be triggered early enough to 
> prevent the wrong buffer size being used during decoding. For this reason, I 
> modified "tif_dirread.c" so that for TIFF_OJPEG images, it will trigger 
> "tif_ojpeg.c" to run the correction routine, so that the first call to 
> "GetField" will fetch the right values.
> 
> 6. There is one more code change in OJPEGPostDecode, which allows 
> single-strip OJPEG images (with or without YCbCr subsampling) to be decoded 
> by TIFFReadScanline.
> 
> I would like to hear any feedback you have about my code changes. If you 
> want me to try to subdivide the patch into smaller changes, please let me 
> know.
> 
> Thanks,
> rwong_002@hotmail.com
_______________________________________________
Tiff mailing list: Tiff@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
