Re: [GM-help] Error message: : Old-style JPEG compression support is not configured

[Mark M <mar...@ya...>]

Bob, thank you very much for your detailed answer!

I am using GM in a php worker script (using the exec function to call the
command line; not the php extension) being controlled by gearman as a task
manager to dispatch asynchronous conversion duties to worker scripts.  I am
converting pdf and tiffs, though I may add support for jpg, gif and png in
the future.

Does GM do anything special with the pdfs before or after passing them to
ghostscript or is it simply a wrapper in the conversion? In other words, do
I get any additional advantage of going through GM to get to ghostscript or
it is simply a convenience so processing can have an common interface?

I am using the array syntax to provide progress feedback, glad to know my
approach is correct.  I am currently processing in batches of five pages at
a time, is that too low?  Could I up it to 20-25 or 50 pages without
affecting system performance?  Is there a sweet spot between memory and cpu
usage and the cost of restarting GM for each batch of pages?

I am going to work on the old style jpeg problem using the clues you
provided, if I find a working solution, I will post it back in this thread
to help others who run across this problem.

Also, I am thinking about using zbar to decode some barcodes, it needs
ImageMagick to interpret raw image data, can I configure GM in a way so when
I build this application, it thinks GM is ImageMagick so I don't have to
install ImageMagick?


-----Original Message-----
From: Bob Friesenhahn [mailto:bfr...@si...] 
Sent: Wednesday, August 03, 2011 7:14 AM
To: Mark Miller
Cc: gra...@li...
Subject: Re: [GM-help] Error message: : Old-style JPEG compression support
is not configured

On Mon, 1 Aug 2011, Mark Miller wrote:

> When I do the following:
> gm convert foo.tif bar.png
> (where foo.tif is a 200dpi color scanned file -- probably a Canon from
what I am reading about them using
> the ?old style?)
> 
> I get the following message:
> 
> gm convert: Old-style JPEG compression support is not configured.
> 
> How do I configure my build to make this work?

Support for Old-style JPEG compression is totally dependent on the 
capabilities of the installed libtiff.  Support for old-style JPEG is 
a configure option for libtiff.  Different versions of libtiff have 
considerably-differing capabilities to read old-style JPEG.  It will 
never be perfect because one reason why old-style JPEG was abandoned 
is because its design was so flimsy that interoperability was not 
assured.  It may be that libtiff 4.0.0beta7 will do better with 
old-style JPEG and I know that there are patches submitted to the 
libtiff bug-tracker (and not yet applied) which may help libtiff read 
some old-style JPEG better.

> When I am running the stable version of GM, I get that message.  When I
run the latest snapshot I get a
> Segmentation fault. 

I am curious if the segmentation fault is in libtiff or GM.  Is it 
possible that your stable version of GM is linked with an older 
version of libtiff?

The version of libtiff (and libjpeg) used should be included in

   'gm convert -list formats'

output.

You also have two major versions of libjpeg installed.  Libtiff also 
links against libjpeg.   It is possible that libtiff and GM are built 
with different versions of libjpeg, resulting in two versions of 
libjpeg in the same application.  You can use 'ldd `which gm`' to see 
what libraries are actually used.

> Separately, If I process a large TIFF (33Megs --977 pages) using the
snapshot version of GM, it takes all
> the CPU and brings everything else to a crawl and it uses a ton of swap
space.

Due to an architectural-shortcoming in GM, it loads all frames before 
it writes any frames.  GM is therefore best used for processing a 
limited number of frames.

It might help to use the array syntax to request only a sub-range of 
the input frames and then process the file incrementally.  For 
example:

   'file.tiff[2-3]'

   'file.tiff[3]'

   gm convert 'file.tiff[3]' frame4.tiff

However, streaming tools like 'tiffcp' will scale much better because 
they only load one frame at once.  With some luck, you can find/build 
a working 'tiffcp' (perhaps based on libtiff 4.0.0beta7 or even 
libtiff CVS) which would allow you to convert your old-JPEG compressed 
TIFF to modern TIFF.

Bob
-- 
Bob Friesenhahn
bfr...@si..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1390 / Virus Database: 1518/3807 - Release Date: 08/03/11