Release Notes

Open Source Used In AsyncOS 8.8 for Cisco Web Security Appliances

In some cases, you may want to read a file without knowing whether it contains

an image or just tables. In that case, pass FALSE and check the return value

from jpeg_read_header(): it will be JPEG_HEADER_OK if an image was found,

JPEG_HEADER_TABLES_ONLY if only tables were found. (A third return value,

JPEG_SUSPENDED, is possible when using a suspending data source manager.)

Note that jpeg_read_header() will not complain if you read an abbreviated

image for which you haven't loaded the missing tables; the missing-table check

occurs later, in jpeg_start_decompress().

It is possible to read a series of images from a single source file by

repeating the jpeg_read_header() ... jpeg_finish_decompress() sequence,

without releasing/recreating the JPEG object or the data source module.

(If you did reinitialize, any partial bufferload left in the data source

buffer at the end of one image would be discarded, causing you to lose the

start of the next image.) When you use this method, stored tables are

automatically carried forward, so some of the images can be abbreviated images

that depend on tables from earlier images.

If you intend to write a series of images into a single destination file,

you might want to make a specialized data destination module that doesn't

flush the output buffer at term_destination() time. This would speed things

up by some trifling amount. Of course, you'd need to remember to flush the

buffer after the last image. You can make the later images be abbreviated

ones by passing FALSE to jpeg_start_compress().

Special markers

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

Some applications may need to insert or extract special data in the JPEG

datastream. The JPEG standard provides marker types "COM" (comment) and

"APP0" through "APP15" (application) to hold application-specific data.

Unfortunately, the use of these markers is not specified by the standard.

COM markers are fairly widely used to hold user-supplied text. The JFIF file

format spec uses APP0 markers with specified initial strings to hold certain

data. Adobe applications use APP14 markers beginning with the string "Adobe"

for miscellaneous data. Other APPn markers are rarely seen, but might

contain almost anything.

If you wish to store user-supplied text, we recommend you use COM markers

and place readable 7-bit ASCII text in them. Newline conventions are not

standardized --- expect to find LF (Unix style), CR/LF (DOS style), or CR

(Mac style). A robust COM reader should be able to cope with random binary

garbage, including nulls, since some applications generate COM markers

containing non-ASCII junk. (But yours should not be one of them.)