Release Notes

Open Source Used In AsyncOS 8.8 for Cisco Web Security Appliances
100
The scanlines count passed to and returned from jpeg_write_raw_data is
measured in terms of the component with the largest v_samp_factor.
jpeg_write_raw_data() processes one MCU row per call, which is to say
v_samp_factor*DCTSIZE sample rows of each component. The passed num_lines
value must be at least max_v_samp_factor*DCTSIZE, and the return value will
be exactly that amount (or possibly some multiple of that amount, in future
library versions). This is true even on the last call at the bottom of the
image; don't forget to pad your data as necessary.
The required dimensions of the supplied data can be computed for each
component as
cinfo->comp_info[i].width_in_blocks*DCTSIZE samples per row
cinfo->comp_info[i].height_in_blocks*DCTSIZE rows in image
after jpeg_start_compress() has initialized those fields. If the valid data
is smaller than this, it must be padded appropriately. For some sampling
factors and image sizes, additional dummy DCT blocks are inserted to make
the image a multiple of the MCU dimensions. The library creates such dummy
blocks itself; it does not read them from your supplied data. Therefore you
need never pad by more than DCTSIZE samples. An example may help here.
Assume 2h2v downsampling of YCbCr data, that is
cinfo->comp_info[0].h_samp_factor = 2for Y
cinfo->comp_info[0].v_samp_factor = 2
cinfo->comp_info[1].h_samp_factor = 1for Cb
cinfo->comp_info[1].v_samp_factor = 1
cinfo->comp_info[2].h_samp_factor = 1for Cr
cinfo->comp_info[2].v_samp_factor = 1
and suppose that the nominal image dimensions (cinfo->image_width and
cinfo->image_height) are 101x101 pixels. Then jpeg_start_compress() will
compute downsampled_width = 101 and width_in_blocks = 13 for Y,
downsampled_width = 51 and width_in_blocks = 7 for Cb and Cr (and the same
for the height fields). You must pad the Y data to at least 13*8 = 104
columns and rows, the Cb/Cr data to at least 7*8 = 56 columns and rows. The
MCU height is max_v_samp_factor = 2 DCT rows so you must pass at least 16
scanlines on each call to jpeg_write_raw_data(), which is to say 16 actual
sample rows of Y and 8 each of Cb and Cr. A total of 7 MCU rows are needed,
so you must pass a total of 7*16 = 112 "scanlines". The last DCT block row
of Y data is dummy, so it doesn't matter what you pass for it in the data
arrays, but the scanlines count must total up to 112 so that all of the Cb
and Cr data gets passed.
Output suspension is supported with raw-data compression: if the data
destination module suspends, jpeg_write_raw_data() will return 0.
In this case the same data rows must be passed again on the next call.
Decompression with raw data output implies bypassing all postprocessing.
You must deal with the color space and sampling factors present in the