view release on metacpan or  search on metacpan

src/Source/LibJPEG/usage.txt  view on Meta::CPAN

			has very fast floating-point hardware.  Also note that
			results of the floating-point method may vary slightly
			across machines, while the integer methods should give
			the same results everywhere.  The fast integer method
			is much less accurate than the other two.

	-dither fs	Use Floyd-Steinberg dithering in color quantization.
	-dither ordered	Use ordered dithering in color quantization.
	-dither none	Do not use dithering in color quantization.
			By default, Floyd-Steinberg dithering is applied when
			quantizing colors; this is slow but usually produces
			the best results.  Ordered dither is a compromise
			between speed and quality; no dithering is fast but
			usually looks awful.  Note that these switches have
			no effect unless color quantization is being done.
			Ordered dither is only available in -onepass mode.

	-map FILE	Quantize to the colors used in the specified image
			file.  This is useful for producing multiple files
			with identical color maps, or for forcing a predefined
			set of colors to be used.  The FILE must be a GIF
			or PPM file.  This option overrides -colors and
			-onepass.

	-nosmooth	Don't use high-quality upsampling.

	-onepass	Use one-pass instead of two-pass color quantization.
			The one-pass method is faster and needs less memory,
			but it produces a lower-quality image.  -onepass is
			ignored unless you also say -colors N.  Also,
			the one-pass method is always used for gray-scale
			output (the two-pass method is no improvement then).

	-maxmemory N	Set limit for amount of memory to use in processing
			large images.  Value is in thousands of bytes, or
			millions of bytes if "M" is attached to the number.
			For example, -max 4m selects 4000000 bytes.  If more
			space is needed, temporary files will be used.

	-verbose	Enable debug printout.  More -v's give more printout.
	or  -debug	Also, version information is printed at startup.


HINTS FOR CJPEG

Color GIF files are not the ideal input for JPEG; JPEG is really intended for
compressing full-color (24-bit) images.  In particular, don't try to convert
cartoons, line drawings, and other images that have only a few distinct
colors.  GIF works great on these, JPEG does not.  If you want to convert a
GIF to JPEG, you should experiment with cjpeg's -quality and -smooth options
to get a satisfactory conversion.  -smooth 10 or so is often helpful.

Avoid running an image through a series of JPEG compression/decompression
cycles.  Image quality loss will accumulate; after ten or so cycles the image
may be noticeably worse than it was after one cycle.  It's best to use a
lossless format while manipulating an image, then convert to JPEG format when
you are ready to file the image away.

The -optimize option to cjpeg is worth using when you are making a "final"
version for posting or archiving.  It's also a win when you are using low
quality settings to make very small JPEG files; the percentage improvement
is often a lot more than it is on larger files.  (At present, -optimize
mode is always selected when generating progressive JPEG files.)

GIF input files are no longer supported, to avoid the Unisys LZW patent
(now expired).
(Conversion of GIF files to JPEG is usually a bad idea anyway.)


HINTS FOR DJPEG

To get a quick preview of an image, use the -grayscale and/or -scale switches.
"-grayscale -scale 1/8" is the fastest case.

Several options are available that trade off image quality to gain speed.
"-fast" turns on the recommended settings.

"-dct fast" and/or "-nosmooth" gain speed at a small sacrifice in quality.
When producing a color-quantized image, "-onepass -dither ordered" is fast but
much lower quality than the default behavior.  "-dither none" may give
acceptable results in two-pass mode, but is seldom tolerable in one-pass mode.

If you are fortunate enough to have very fast floating point hardware,
"-dct float" may be even faster than "-dct fast".  But on most machines
"-dct float" is slower than "-dct int"; in this case it is not worth using,
because its theoretical accuracy advantage is too small to be significant
in practice.

Two-pass color quantization requires a good deal of memory; on MS-DOS machines
it may run out of memory even with -maxmemory 0.  In that case you can still
decompress, with some loss of image quality, by specifying -onepass for
one-pass quantization.

To avoid the Unisys LZW patent (now expired), djpeg produces uncompressed GIF
files.  These are larger than they should be, but are readable by standard GIF
decoders.


HINTS FOR BOTH PROGRAMS

If more space is needed than will fit in the available main memory (as
determined by -maxmemory), temporary files will be used.  (MS-DOS versions
will try to get extended or expanded memory first.)  The temporary files are
often rather large: in typical cases they occupy three bytes per pixel, for
example 3*800*600 = 1.44Mb for an 800x600 image.  If you don't have enough
free disk space, leave out -progressive and -optimize (for cjpeg) or specify
-onepass (for djpeg).

On MS-DOS, the temporary files are created in the directory named by the TMP
or TEMP environment variable, or in the current directory if neither of those
exist.  Amiga implementations put the temp files in the directory named by
JPEGTMP:, so be sure to assign JPEGTMP: to a disk partition with adequate free
space.

The default memory usage limit (-maxmemory) is set when the software is
compiled.  If you get an "insufficient memory" error, try specifying a smaller
-maxmemory value, even -maxmemory 0 to use the absolute minimum space.  You
may want to recompile with a smaller default value if this happens often.

On machines that have "environment" variables, you can define the environment
variable JPEGMEM to set the default memory limit.  The value is specified as