Release Notes

Open Source Used In AsyncOS 8.8 for Cisco Web Security Appliances
107
Library compile-time options
----------------------------
A number of compile-time options are available by modifying jmorecfg.h.
The JPEG standard provides for both the baseline 8-bit DCT process and
a 12-bit DCT process. The IJG code supports 12-bit lossy JPEG if you define
BITS_IN_JSAMPLE as 12 rather than 8. Note that this causes JSAMPLE to be
larger than a char, so it affects the surrounding application's image data.
The sample applications cjpeg and djpeg can support 12-bit mode only for PPM
and GIF file formats; you must disable the other file formats to compile a
12-bit cjpeg or djpeg. (install.txt has more information about that.)
At present, a 12-bit library can handle *only* 12-bit images, not both
precisions. (If you need to include both 8- and 12-bit libraries in a single
application, you could probably do it by defining NEED_SHORT_EXTERNAL_NAMES
for just one of the copies. You'd have to access the 8-bit and 12-bit copies
from separate application source files. This is untested ... if you try it,
we'd like to hear whether it works!)
Note that a 12-bit library always compresses in Huffman optimization mode,
in order to generate valid Huffman tables. This is necessary because our
default Huffman tables only cover 8-bit data. If you need to output 12-bit
files in one pass, you'll have to supply suitable default Huffman tables.
You may also want to supply your own DCT quantization tables; the existing
quality-scaling code has been developed for 8-bit use, and probably doesn't
generate especially good tables for 12-bit.
The maximum number of components (color channels) in the image is determined
by MAX_COMPONENTS. The JPEG standard allows up to 255 components, but we
expect that few applications will need more than four or so.
On machines with unusual data type sizes, you may be able to improve
performance or reduce memory space by tweaking the various typedefs in
jmorecfg.h. In particular, on some RISC CPUs, access to arrays of "short"s
is quite slow; consider trading memory for speed by making JCOEF, INT16, and
UINT16 be "int" or "unsigned int". UINT8 is also a candidate to become int.
You probably don't want to make JSAMPLE be int unless you have lots of memory
to burn.
You can reduce the size of the library by compiling out various optional
functions. To do this, undefine xxx_SUPPORTED symbols as necessary.
You can also save a few K by not having text error messages in the library;
the standard error message table occupies about 5Kb. This is particularly
reasonable for embedded applications where there's no good way to display
a message anyway. To do this, remove the creation of the message table