From: Bob Friesenhahn <bfriesen@si...> - 2008-01-31 17:29:23
I just posted the following note in a bug report as to why the command
gm convert -compress fax input.tiff output.tiff
does not always produce an output file which uses the requested
compression. There is a paradigm shift in 1.2 from the old
ImageMagick way of doing things in order to put more control in the
hands of the user and assure that performance is predictable.
"GraphicsMagick 1.2 does work a bit different than previous versions
of GraphicsMagick. Prior to GraphicsMagick 1.2, if someone requested
FAX compression and the image was not bi-level (pure black and white
pixels) then (depending on the dither setting) an excruciatingly slow
reduction algorithm might be used which takes minutes or even hours
depending on the size of the image and CPU speed. For GraphicsMagick
1.2 I decided that performance when writing files should always be
predictable. It is not acceptable that sometimes a file is saved in
one second while other times it takes half an hour simply because it
contains one color pixel. Based on this, if the requested compression
is not suitable for the image's existing type, then the requested
compression is ignored.
In order to successfully always produce FAX-compressed output you
should use an algorithm to ensure that the image is already suitable
for compression using FAX. This could be done using -threshold,
-ordered-dither, or color reduction to two colors in a gray colorspace
(the previous defauult). This requirement to process the image in
advance may seem a bit annoying but it puts control over the result in
the hands of the user and assures consistent performance."
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Get latest updates about Open Source Projects, Conferences and News.