Release Notes

Open Source Used In AsyncOS 8.8 for Cisco Web Security Appliances

This differs from ordinary unbuffered decoding in that there is an additional

level of looping. The application can choose how many output passes to make

and how to display each pass.

The simplest approach to displaying progressive images is to do one display

pass for each scan appearing in the input file. In this case the outer loop

condition is typically

while (! jpeg_input_complete(&cinfo))

and the start-output call should read

jpeg_start_output(&cinfo, cinfo.input_scan_number);

The second parameter to jpeg_start_output() indicates which scan of the input

file is to be displayed; the scans are numbered starting at 1 for this

purpose. (You can use a loop counter starting at 1 if you like, but using

the library's input scan counter is easier.) The library automatically reads

data as necessary to complete each requested scan, and jpeg_finish_output()

advances to the next scan or end-of-image marker (hence input_scan_number

will be incremented by the time control arrives back at jpeg_start_output()).

With this technique, data is read from the input file only as needed, and

input and output processing run in lockstep.

After reading the final scan and reaching the end of the input file, the

buffered image remains available; it can be read additional times by

repeating the jpeg_start_output()/jpeg_read_scanlines()/jpeg_finish_output()

sequence. For example, a useful technique is to use fast one-pass color

quantization for display passes made while the image is arriving, followed by

a final display pass using two-pass quantization for highest quality. This

is done by changing the library parameters before the final output pass.

Changing parameters between passes is discussed in detail below.

In general the last scan of a progressive file cannot be recognized as such

until after it is read, so a post-input display pass is the best approach if

you want special processing in the final pass.

When done with the image, be sure to call jpeg_finish_decompress() to release

the buffered image (or just use jpeg_destroy_decompress()).

If input data arrives faster than it can be displayed, the application can

cause the library to decode input data in advance of what's needed to produce

output. This is done by calling the routine jpeg_consume_input().

The return value is one of the following:

JPEG_REACHED_SOS: reached an SOS marker (the start of a new scan)

JPEG_REACHED_EOI: reached the EOI marker (end of image)

JPEG_ROW_COMPLETED: completed reading one MCU row of compressed data

JPEG_SCAN_COMPLETED: completed reading last MCU row of current scan

JPEG_SUSPENDED: suspended before completing any of the above

(JPEG_SUSPENDED can occur only if a suspending data source is used.) This

routine can be called at any time after initializing the JPEG object. It