Return-Path: <tiff-bounces@lists.maptools.org>
X-Original-To: info@awaresystems.be
Delivered-To: info@awaresystems.be
Received: from mx-r.b-one.net (mx-r.one.com [91.198.169.249])
	by mail9.b-one.net (Postfix) with ESMTP id 611DB400162
	for <info@awaresystems.be>; Sat, 12 Feb 2011 20:32:22 +0100 (CET)
Received: by mx-r.b-one.net (Postfix, from userid 106)
	id 564B21651178; Sat, 12 Feb 2011 20:32:22 +0100 (CET)
X-Virus-Scanned: by one.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level: 
X-Spam-Status: No, score=0 tagged_above=0 required=4 tests=[none]
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.4
Received: from lists.maptools.org (lists.maptools.org [65.39.174.144]) by
 mx-r.b-one.net (Postfix) with ESMTP id ECE4144E for <info@awaresystems.be>;
 Sat, 12 Feb 2011 20:32:20 +0100 (CET)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by
 lists.maptools.org (Postfix) with ESMTP id 3918886A10; Sat, 12 Feb 2011
 14:31:00 -0500 (EST)
Received: from isadora.cybox.com (isadora.cybox.com [206.168.112.10]) by
 lists.maptools.org (Postfix) with ESMTP id 0B32486A14 for
 <tiff@lists.maptools.org>; Sat, 12 Feb 2011 14:03:21 -0500 (EST)
Received: from aeolus.wriverody.net (vc7-1-52.dsl.indra.com [199.45.160.84])
 (authenticated) by isadora.cybox.com (msa 8.13.8/8.13.6) with ESMTP id
 p1CJ3JLo010631 for <tiff@lists.maptools.org>; Sat, 12 Feb 2011 12:03:20 -0700
Message-ID: <4D56D972.2050407@cybox.com>
Date: Sat, 12 Feb 2011 12:03:14 -0700
From: Richard Nolde <richard.nolde@cybox.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15)
 Gecko/20101027 Fedora/3.0.10-1.fc12 Thunderbird/3.0.10
MIME-Version: 1.0
To: tiff@lists.maptools.org
References: <mailman.1.1297530001.25064.tiff@lists.maptools.org>
In-Reply-To: <mailman.1.1297530001.25064.tiff@lists.maptools.org>
Subject: Re: [Tiff] JPEG issues with tiffcp
X-BeenThere: tiff@lists.maptools.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: richard.nolde@cybox.com
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

  Re: Converting single-page TIFFs to multi-page TIFF or PDF

John,
    I'm familiar with the Pixel Translations Product as it is used by a 
number of commercial packages distributed by Epson and Canon. There are 
several flavors of TIFF among the export options, some of which are not 
very portable to other software. Another problem with that software is 
that if you do any edits and then save back to the same file name, the 
old and new images are put in the file, but the IFD chain is updated to 
skip the original image. This bloats the file size if users happen to 
use the same file name repeatedly because they are too lazy to type a 
new file name each time....

   You might try tiffcrop instead of tiffcp. It will read most OJPEG 
files and try to convert them to NEW JPEG compression (or other 
compression types if specified on the command line) on the fly  since 
writing OJPEG is no longer supported. I don't know if it will handle 
your specific files, but it would be worth a try.  If you want to send 
me your test files, I will look at how it handles them in the debugger. 
Tiffcrop will uncompress the input data stream into a buffer in memory 
and then write it out with the requested compression scheme. Unlike 
tiffcp it will try to convert OJPEG to new JPEG automatically if the 
original was OJPEG. However, these error messages you are seeing are 
coming from LibTiff library code, not tiffcp per se so it tiffcrop may 
have the same problems.

  If you have to script a workaround, I'd run tiffinfo and parse out the 
Compression Scheme line. If OJEG appears in that output, you have to 
uncompress the data or change the compression BEFORE you try to 
concatenate that image with the others. Tiffcp tries to copy the input 
image to the output image without altering anything and without 
unpacking the scanlines/strips into a new full-image buffer. If tiffcrop 
cannot convert the OJPEG to new JPEG images on the fly, you may have to 
pre-process the problematic images by removing OJPEG compression, and 
then combine them with others using tiffcp.

Richard Nolde
Tiffcrop author

>  The JPEG in question is displayed as a blob by Windows Image
>  Preview but I can view it with XnView (www.xnview.com).
>
>  $ tiffinfo -c -j  -s test-original.tif
>  TIFFReadDirectory: Warning, test-original.tif: wrong data type 4 for "JpegProc";
>    tag ignored.
>  TIFFReadDirectory: Warning, Photometric tag value assumed incorrect, assuming da
>  ta is YCbCr instead of RGB.
>  OJPEGSubsamplingCorrect: Warning, Subsampling tag is not set, yet subsampling in
>  side JPEG data [1,1] does not match default values [2,2]; assuming subsampling i
>  nside JPEG data is correct.
>  TIFF Directory at offset 0x8 (8)
>     Subfile Type: (0 = 0x0)
>     Image Width: 716 Image Length: 480
>     Resolution: 400, 400 pixels/inch
>     Bits/Sample: 8
>     Compression Scheme: Old-style JPEG
>     Photometric Interpretation: YCbCr
>     YCbCr Subsampling: 1, 1
>     Orientation: row 0 top, col 0 lhs
>     Samples/Pixel: 3
>     Rows/Strip: 480
>     Planar Configuration: single image plane
>     Software: Pixel Translations Inc., PIXTIFF Version 54.1.207
>     JpegInterchangeFormat: 520
>     JpegInterchangeFormatLength: 408
>     JpegQTables: 634 699 699
>     JpegDcTables: 768 848 848
>     JpegAcTables: 793 872 872
>     1 Strips:
>         0: [     928,    29221]
>
>  Regards,
>  Alias John Brown.
>

Nobody has any ideas?

Additional observations:

1) GraphicsMagick does the concatenation without warnings or errors:

'gm convert -adjoin a.tif b.tif result.tif' results in a two-page
colour TIFF that can be viewed in Windows Image Preview. a.tif
and b.tif are copies of the original compressed OJPEG TIFF.

2) If I comment out the section of code in tif_jpeg.c responsible
for the error message
JPEGSetupEncode: RowsPerStrip must be multiple of 8 for JPEG.
test-jpg.tif: Error, can't write strip 0.
then 'tiffcp -c jpeg:r a.tif b.tif result.tif' works. Without
':r', the colours are wrong.

The problem is that I am forced to specify JPEG compression. I
am going to convert thousands of TIFFs. Most of them are going
to be monochrome (the usual CCITT G3 or G4). I suppose that I
can work with this if I do something like:

concatenate TIFFs
if fail because OJPEG not supported then
??? add '-c jpeg:r' to flags and try again
end if

However, I still have to comment out the RowsPerStrip error
in tif_jpeg.c. I have to assume that bad things really will
happen if RowsPerStrip is not a multiple of 8, so I would
rather not do that.

Finally, what would save me a little work is if tiffcp had a
flag that would make it use new JPEG compression whenever it
encounters OJPEG, instead of giving up.

Back to one of my original questions:

If I uncompress the TIFF using tiffcp, I can make a PDF with
JPEG compression from it using tiff2pdf, but tiffcp will
give the 'RowsPerStrip must be multiple of 8' message
(before my modification.) Why should one utility be able to
handle the file but not the other. Is it a bug?

Regards,
Alias John brown.


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