Return-Path: <tiff-bounces@lists.maptools.org>
Received: from inas009.isp.belgacom.be (localhost [127.0.0.1])
        by inav016.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-IN-AV-3.00) with ESMTP id kA8HTMPm015311
        for <joris.at.lebbeke@skynet.be>; Wed, 8 Nov 2006 18:29:23 +0100
        (envelope-from <tiff-bounces@lists.maptools.org>)
Received: from inmx001.isp.belgacom.be (inmx001.isp.belgacom.be [195.238.5.1])
        by inas009.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-IN-AS-2.03) with ESMTP id kA8HSo85020939
        for <joris.at.lebbeke@skynet.be>; Wed, 8 Nov 2006 18:29:17 +0100
        (envelope-from <tiff-bounces@lists.maptools.org>)
Received: from duke.maptools.org (r153.dmsolutions.ca [209.217.116.153] (may be forged))
        by inmx001.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-IN-2.32) with ESMTP id kA8HSL1k005633
        for <joris.at.lebbeke@skynet.be>; Wed, 8 Nov 2006 18:28:22 +0100
        (envelope-from <tiff-bounces@lists.maptools.org>)
Received: from duke.maptools.org (duke.maptools.org [127.0.0.1])
	by duke.maptools.org (8.12.11/8.12.10) with ESMTP id kA8HITLJ011439;
	Wed, 8 Nov 2006 12:18:37 -0500
Received: from outmx026.isp.belgacom.be (outmx026.isp.belgacom.be
	[195.238.4.91])
	by duke.maptools.org (8.12.11/8.12.10) with ESMTP id kA8HIQWZ011436
	for <tiff@lists.maptools.org>; Wed, 8 Nov 2006 12:18:27 -0500
Received: from outmx026.isp.belgacom.be (localhost [127.0.0.1])
	by outmx026.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-OUT-2.22)
	with ESMTP id kA8HIMPB007565
	for <tiff@lists.maptools.org>; Wed, 8 Nov 2006 18:18:22 +0100
	(envelope-from <joris.at.lebbeke@skynet.be>)
Received: from dfgrrxsknr4e (241.182-245-81.adsl-dyn.isp.belgacom.be
	[81.245.182.241])
	by outmx026.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-OUT-2.22)
	with SMTP id kA8HIDQj007435
	for <tiff@lists.maptools.org>; Wed, 8 Nov 2006 18:18:14 +0100
	(envelope-from <joris.at.lebbeke@skynet.be>)
Message-ID: <003c01c70359$e77389f0$f1b6f551@dfgrrxsknr4e>
From: "Joris" <joris.at.lebbeke@skynet.be>
To: "TIFF mailing list" <tiff@lists.maptools.org>
Date: Wed, 8 Nov 2006 18:07:58 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1807
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807
Subject: [Tiff] OJPEG - two troublesome flavours
X-BeenThere: tiff@lists.maptools.org
X-Mailman-Version: 2.1.4
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>
Sender: tiff-bounces@lists.maptools.org
Errors-To: tiff-bounces@lists.maptools.org
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by inav016.isp.belgacom.be id kA8HTMPm015311
X-UIDL: 000000000023ceae.00001d3e
X-MSP-STORE: Wed, 08 Nov 2006 18:29:25 +0100
Status:   

Folks,

This is to inform you that I've received two files that the current
OJPEG decoder in CVS can't handle. Details are below. I mean to fix this
as soon as possible, which is likely by January next year.

If you find any other files that don't seem to work, please don't
hesitate to mail me, unless you know for a fact they correspond to the
descriptions below of the files sent to me already.

* One seems to be written by "Kofax standard Multi-Page TIFF Storage
Filter v3.03.000", judging from the Software tag. Seeing they write
OJPEG, I take it they mean the word "standard" a bit ironically.

LibTiff reports the error "Fractional scanline not read".

Strangely, my own proprietary codec that works much the same as the new
OJPEG decoder in LibTiff, handles this file just fine. This indicates
there is probably some trouble in the surrounding code in LibTiff,
possibly some scanline length calculation, and not in the actual OJPEG
codec.

* The other one seems to be written by "Microsoft Office Document
Scanning 11.0.1897.00" judging from that same Software tag.

The IFD indicates 1 sample per pixel, photometric MinIsBlack. Yet, the
JPEG compressed data contains three channels. LibTiff properly errors
out, saying "JPEG compressed data indicates unexpected number of
samples", which makes sense.

The JPEG compressed data, by itself, is legit. Even though it has three
channels, it doesn't contain any obvious color judging from a visual
inspection.

It is not enterely clear to me what would be the best solution.
Depending on the writer's intention, which is anyone's guess, I may
either want to add a hack to the surrounding library that corrects the
IFD to read 3 samples per pixel, photometric YCbCr, or I may either want
to add a hack inside the OJPEG codec to return the first Y sample of the
JPEG data only. The first option would be correct if the writer's
intention is to actually (not) interchange grayscale data, the second
would be correct if the lack of color in this particular file's JPEG
compressed data is merely co=EFncidence.


Best regards,

Joris Van Damme
info@awaresystems.be
http://www.awaresystems.be/
Download your free TIFF tag viewer for windows here:
http://www.awaresystems.be/imaging/tiff/astifftagviewer.html

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