Re: [GM-help] Error message: : Old-style JPEG compression support is not configured
Swiss army knife of image processing
Brought to you by:
bfriesen
From: Bob F. <bfr...@si...> - 2011-08-03 14:14:08
|
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/ |