Wiggins d Anconia wrote: > GIF compression or GIF images?
AFAIK, that is a false distinction. Unless some standard release since 89A has changed this, LZW compression is integral to the GIF format. Unlike JPEG / JFIF, which includes parameters for the dgree of compression/lossiness, GIF compression is built into the encoding. algorithm, which inherently compresses as it encodes. The only discretionary factor available is the frequency with which clear codes are placed in the data stream. They can be issued prematurely, or they can be deferred even after the compression string table has reached its maximum size of 4096 strings. I know of no applications that use either option. Almost all GIF image files have clear codes once in 4096 compression codes. > Image::Magick will support any format > that the underlying imagemagick C libs can support, they can support GIF > images, but that depends on having libgif or giflib (or some such > library) installed when imagemagick is built. > > Personally I would suggest scrapping GIFs completely in favor of PNGs. This summer, when the last LZW patents owned by Unisys expire, [the US patent has already expired] GIF should become a much more attractive formatting alternative. It is much more straightforward than JPEG or PNG, and almost universally implemented on Web browsers, unlike PNG. Joseph -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] <http://learn.perl.org/> <http://learn.perl.org/first-response>
