Return-Path: <tiff-bounces@lists.maptools.org>
Received: from inas022.isp.belgacom.be (localhost [127.0.0.1])
        by inav015.isp.belgacom.be (8.12.11/8.12.11/Skynet-IN-AV-3.00) with ESMTP id k2R44W2U002858
        for <joris.at.lebbeke@skynet.be>; Mon, 27 Mar 2006 06:04:32 +0200
        (envelope-from <tiff-bounces@lists.maptools.org>)
Received: from inmx003.isp.belgacom.be (inmx003.isp.belgacom.be [195.238.5.11])
        by inas022.isp.belgacom.be (8.12.11/8.12.11/Skynet-IN-AS-2.03) with ESMTP id k2R44PvS010986
        for <joris.at.lebbeke@skynet.be>; Mon, 27 Mar 2006 06:04:26 +0200
        (envelope-from <tiff-bounces@lists.maptools.org>)
Received: from duke.maptools.org (r153.dmsolutions.ca [209.217.116.153] (may be forged))
        by inmx003.isp.belgacom.be (8.12.11/8.12.11/Skynet-IN-2.32) with ESMTP id k2R44NSS012527
        for <joris.at.lebbeke@skynet.be>; Mon, 27 Mar 2006 06:04:23 +0200
        (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 k2R3uMlH004679;
	Sun, 26 Mar 2006 22:56:59 -0500
Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.194])
	by duke.maptools.org (8.12.11/8.12.10) with ESMTP id k2R3uKm0004675
	for <tiff@lists.maptools.org>; Sun, 26 Mar 2006 22:56:20 -0500
Received: by zproxy.gmail.com with SMTP id z31so1270240nzd
	for <tiff@lists.maptools.org>; Sun, 26 Mar 2006 19:56:19 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=Gg4TvLIOQIs94i+tbO1tEDppdk/KfQA9aiCmAbowqnCGtC4O07DIV6BdvqsUen6ZLFPT7cAWesRDvvpsqKs7yGaDC0sCY3aEX/ZG+gqIry6uKY/edUTcv0IltKnnhzgSWqNaz1mTejj/uSQCNgYSmBuQqWrHMtQqYUBhZZIbHGA=
Received: by 10.65.228.1 with SMTP id f1mr2066292qbr;
	Sun, 26 Mar 2006 19:56:18 -0800 (PST)
Received: by 10.65.240.20 with HTTP; Sun, 26 Mar 2006 19:56:18 -0800 (PST)
Message-ID: <5a28e8c20603261956r8c6ee82tadca2a3cf0e2321@mail.gmail.com>
Date: Sun, 26 Mar 2006 22:56:18 -0500
From: "Mikhail Kruk" <meshko@gmail.com>
To: Joris <joris.at.lebbeke@skynet.be>
Subject: Re: [Tiff] 3.8.1 and JPEG problem
In-Reply-To: <001701c65139$489c8200$1a86f651@dfgrrxsknr4e>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
References: <5a28e8c20603200939h1ee3ab84uff5a5cbc3a4e1bc0@mail.gmail.com>
	<5a28e8c20603201004r667ac48n78dba3128e758bf3@mail.gmail.com>
	<20060320190002.GA15279@ak4719.spb.edu>
	<5a28e8c20603201232i47051a5an5d8d2d66a22a57a9@mail.gmail.com>
	<000a01c64fe3$1b6d5b80$7ea4f551@dfgrrxsknr4e>
	<5a28e8c20603251852n616da34ah12ab5e7d82c24fa3@mail.gmail.com>
	<001c01c65084$fddb7140$b088f651@dfgrrxsknr4e>
	<5a28e8c20603261548v72f121e6q3a01fd9a28c6f9d0@mail.gmail.com>
	<001701c65139$489c8200$1a86f651@dfgrrxsknr4e>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by duke.maptools.org id
	k2R3uKm0004675
Cc: tiff@lists.maptools.org
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
X-UIDL: 000000000023ceae.0000145b
X-MSP-STORE: Mon, 27 Mar 2006 06:04:40 +0200
Status:   

> > All right, I got the CVS problem partly figured out.  I don't
> > understand why diff wasn't showing any differences, but a new checkout
> > gave me all your changes.
> > I tested again using tiffcp.  The only TIFF file which is
> > JPEG-compressed I have is in YCBCR color space.  tiffcp didn't process
> > it correctly, I believe there is a bug in it, but when I brute forced
> > it to do
> > TIFFSetField(in, TIFFTAG_JPEGCOLORMODE, JPEGCOLORMODE_RGB);
> > it worked (tiffcp -none jpg.tiff out.tiff produced an unencoded image
> > which looks correctly).
> > Don't have time to compe up with correct tiffcp patch right now).
>
> That sure sounds like there is still trouble in tif_jpeg.c...
>
> Meanwhile, Frank checked current CVS, and found that at least addtiffo
> operates correctly. This addtiffo doesn't use TIFFTAG_JPEGCOLORMODE. My
> own tests without TIFFTAG_JPEGCOLORMODE also indicate all is fine now.
>
> - Are you absolutely sure you're working with current CVS? Did you check
> the changelog file and found those top entries I specified?

Yes, changelog has 4 entries from March 25 under your name.

> - Are you absolutely sure you're refering to JPEG, and not OJPEG?

see below

> I don't have any experience with tiffcp. I don't even have a working
> build of that contrib.

It's under tools, not contrib.  It's a utlitiy to copy TIFF files from
one format to another (compression, compresion options) and to
concatinate and split TIFFs.

>  But if you double-check and confirm you're
> working with JPEG compression in current CVS, I guess I'll have to get
> tiffcp going on my machine and dig into it... Using
> TIFFTAG_JPEGCOLORMODE in tiffcp is no option as far as I'm concerned,
> the bug ought to be fixed instead of burried under bad logic.

No, I think it's the right solution for my decoding problem.  I
probably didn't explain myslef clearly enough.  I was decoding a JPG
images with the specific non-rgb color mode (YCbCr).  tiffcp
apparently reads the YCbCr data from the JPEG and then writes it into
uncompressed file without a conversion, i.e. treating it as RGB.  The
result is messed up as it should be.  Tiffcp should be changed to
detect that source and destination file are in different color spaces
and make the necessary steps to convert between color spaces.

The only remaining problem is encoding JPG.  tiffcp is never creating
old JPG files and I'm not building with old jpeg support, so I'm
positive I'm dealing with the new JPG format.  The command is
tiffcp -c jpeg:r moon.tif jpg.tif
moon.tif is at http://www.scorch2000.com/~meshko/moon.tif
jpg.tif is at http://www.scorch2000.com/~meshko/jpg.tif

Again, the wierd thing is that running
tiffcp -c none jpg.tif out.tif
produces correct file, so somehow the image is correctly stored in
jpg.tif, it's just not viewable in the TIFF viewer which does support
JPG-encoded TIFFs.

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