DctDecodeFilter Class

Definition

The DCTDecode filter: JPEG baseline, extended sequential and progressive image data, Huffman- or arithmetic-coded, 8- or 12-bit, decoded in managed code to 8-bit samples, interleaved, in the §8.9.3 layout. Decode only.

public sealed class DctDecodeFilter : IImageFilter, IStreamFilter

Remarks

ISO 32000-2 §7.4.8 (DCTDecode, Table 13 ColorTransform; progressive JPEG from PDF 1.3); ITU-T T.81 (ISO/IEC 10918-1) Annex B (interchange syntax), Annex C (Huffman tables), Annex D (the QM arithmetic decoder, its own 113-state probability estimation, not the MQ decoder of JBIG2 and JPEG 2000), Annex E (decoder control, restart intervals), Annex F §F.2 (sequential DCT decoding: baseline and extended, 8 and 12 bits, Huffman with up to four tables of each class or arithmetic coding with DAC conditioning), Annex G (progressive DCT decoding: spectral selection and successive approximation, Huffman or arithmetic), Annex A (MCU geometry, IDCT), Annex K.3 (typical tables, used when a scan's table was never defined); Adobe Technical Note #5116 (APP14 marker, colour transforms, replication upsampling). §8.9.5.1 Table 87: the filter always delivers 8 bits per component, whatever the image dictionary says, so 12-bit samples are reduced to 8 bits (reported as DctPrecisionReduced, Information).

Samples equal libjpeg-turbo's with -dct int -nosmooth (the islow IDCT and the integer YCbCr tables are ported from the Independent JPEG Group's software; see THIRD-PARTY-NOTICES.txt): subsampled components are replicated, as Adobe's DCTDecode does, never interpolated. Three components are converted from YCbCr to RGB and four from YCCK to CMYK when the Adobe APP14 segment's transform code says so (Table 13: a present APP14 segment decides and ColorTransform is ignored), else when ColorTransform is 1, else (three components only) unless the components are identified as R, G, B. The codec never inverts samples: an Adobe-inverted CMYK image carries its own Decode array, which the image layer applies (§8.9.5.2). Frames of 1 to 32 components are decoded (T.81 §B.2.2 allows 255; a PDF colour space has at most 32); more than four, which T.81 §B.2.3 codes in several scans, are delivered untransformed, interleaved in frame order.

Never decoded (DctProcessUnsupported, Error, no samples): the lossless and hierarchical processes, which PDF does not use.

Lenient repair, each reported once per image: junk before SOI or between segments is skipped; undefined Huffman tables fall back to Annex K; a frame height of 0 comes from the DNL segment or the image dictionary; restart markers out of sequence are resynchronized; data that ends early leaves the missing blocks mid-grey (DecodedRows on the image path, except that a truncated progressive image keeps every row its first DC scan reached); invalid progressive scans are skipped and out-of-order ones decoded as given; a missing quantization table or an unusable frame decodes nothing. Strict mode throws at the first deviation.

Reduced resolutions (issue #362): asked for a reduction by Reduction (1/2, 1/4 or 1/8, MaxReduction 3), the image path decodes every block with a reduced IDCT ported from libjpeg-turbo's jidctred.c, and gives each subsampled component a larger IDCT instead of upsampling it where the factors allow (jdmaster.c), so the ⌈W / s⌉ x ⌈H / s⌉ samples equal djpeg -scale 1/s -dct int -nosmooth's. At 1/8, a progressive image whose every component reduces to its DC skips the AC scans. Only viewers ask for it; the plain filter path and every other decode are at full resolution.

Stateless and thread-safe; a decode allocates nothing per block or row (the per-image buffers are pooled).

Properties (1)

Methods (3)