|AWARE [SYSTEMS]||Imaging expertise for the Delphi developer|
|TIFF and LibTiff Mailing List Archive|
LibTiff Mailing List
2011.02.12 21:13 "Re: JPEG issues with tiffcp", by John Brown
Hello Richard, > > 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. Yes, this particular software is an old Canon product. [snip] > > 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 reverted my changes to tif_jpeg.c and tested with tiffcrop. 'tiffcrop a.tif b.tif test.tif" decoded the OJPEG-compressed TIFF and produced result.tif with warnings. Two issues: 1) The file size increased dramatically, but I see that your default JPEG quality is 100(?), so I understand. 19/05/2000 01:48 PM 30,152 a.tif 19/05/2000 01:48 PM 30,152 b.tif 12/02/2011 03:18 PM 390,156 test.tif 2) The colours are wrong as before. I then specified '-c jpeg:a' and '-c jpeg:r'. Neither option worked. With tiffcp, :r produced the correct colours. In any case, I would rather not specify any options. Ideally, I want to copy images as they are without knowing what they are. > 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. I will send sample images to you privately. Thanks. > 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. It is good that it automatically uses the new JPEG instead of OJPEG when it encounters OJPEG. However, since tiffcrop decompresses the input and tiffcp does not (that was something that I wondered), I expect that tiffcrop will be much slower than tiffcp. In fact, the reason that I have not given up on libtiff even though GraphicsMagick produces perfect results is that GraphicsMagick is very slow. tiffcp produces 13 documents containing a total of about 30 images in less than a second, but GraphicsMagick takes four seconds. Still, correct output is more important than speed. > 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. I would rather do these checks *after* failure to concatenate. The reason is that I do not really expect to find many colour images. The clients were originally supplied with a monochrome scanner, and even if they have a fast colour scanner now (to be honest I don't know that), I expect that they would scan only difficult documents in grayscale or colour. It would be inefficient to run tiffinfo on every image when I expect the overwhelming majority to be monochrome G3 or G4. Regards, John Brown.