Release Notes

Open Source Used In AsyncOS 8.8 for Cisco Web Security Appliances

ensure that the max_memory_to_use setting cannot be exceeded due to addition

of later markers.

The marker list remains stored until you call jpeg_finish_decompress or

jpeg_abort, at which point the memory is freed and the list is set to empty.

(jpeg_destroy also releases the storage, of course.)

Note that the library is internally interested in APP0 and APP14 markers;

if you try to set a small nonzero length limit on these types, the library

will silently force the length up to the minimum it wants. (But you can set

a zero length limit to prevent them from being saved at all.) Also, in a

16-bit environment, the maximum length limit may be constrained to less than

65533 by malloc() limitations. It is therefore best not to assume that the

effective length limit is exactly what you set it to be.

If you want to supply your own marker-reading routine, you do it by calling

jpeg_set_marker_processor(). A marker processor routine must have the

signature

boolean jpeg_marker_parser_method (j_decompress_ptr cinfo)

Although the marker code is not explicitly passed, the routine can find it

in cinfo->unread_marker. At the time of call, the marker proper has been

read from the data source module. The processor routine is responsible for

reading the marker length word and the remaining parameter bytes, if any.

Return TRUE to indicate success. (FALSE should be returned only if you are

using a suspending data source and it tells you to suspend. See the standard

marker processors in jdmarker.c for appropriate coding methods if you need to

use a suspending data source.)

If you override the default APP0 or APP14 processors, it is up to you to

recognize JFIF and Adobe markers if you want colorspace recognition to occur

properly. We recommend copying and extending the default processors if you

want to do that. (A better idea is to save these marker types for later

examination by calling jpeg_save_markers(); that method doesn't interfere

with the library's own processing of these markers.)

jpeg_set_marker_processor() and jpeg_save_markers() are mutually exclusive

--- if you call one it overrides any previous call to the other, for the

particular marker type specified.

A simple example of an external COM processor can be found in djpeg.c.

Also, see jpegtran.c for an example of using jpeg_save_markers.

Raw (downsampled) image data

----------------------------

Some applications need to supply already-downsampled image data to the JPEG