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

[Bob F. <bfr...@si...>]

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/