Repository navigation
PDF20 Spec 07 Filters
Part of: PDF20-Spec-07-Syntax
Navigation: PDF20-Spec-07-Objects | PDF20-Spec-Index | PDF20-Spec-07-File-Structure
7.4
%An indirect reference to object 8
%The length of the preceding stream
Filters
7.4.1 General Stream filters are introduced in 7.3.8, "Stream objects". An option when reading stream data is to decode it using a filter to produce the original non-encoded data. Whether to do so and which decoding filter or filters to use are specified in the stream dictionary. EXAMPLE 1
If a stream dictionary specifies the use of an ASCIIHexDecode filter, an application reading the data in that stream will need to transform the ASCII hexadecimal-encoded data in that stream in order to obtain the original binary data.
A PDF writer may encode data in a stream (for example, data for sampled images) to compress it or to convert it to a portable ASCII representation (or both). A PDF reader shall invoke the corresponding decoding filter or filters to convert the information back to its original form. The filter or filters for a stream shall be specified by the Filter entry in the stream’s dictionary (or the FFilter entry if the stream is external). Filters may be cascaded to form a pipeline that passes the stream through two or more decoding transformations in sequence. For example, data encoded using LZW and ASCII base-85 encoding (in that order) shall be decoded using the following entry in the stream dictionary: 34
© ISO 2020 – All rights reserved
ISO 32000-2:2020(E)
EXAMPLE 2: /Filter [/ASCII85Decode /LZWDecode]
Some filters may take parameters to control how they operate. These optional parameters shall be specified by the DecodeParms entry in the stream’s dictionary (or the FDecodeParms entry if the stream is external). PDF files support a standard set of filters that fall into two main categories: •
ASCII filters enable decoding of arbitrary binary data that has been encoded as ASCII text (see 7.2, "Lexical conventions" for an explanation of why this type of encoding might be useful).
•
Decompression filters enable decoding of data that has been compressed. The compressed data shall be in binary format, even if the original data is in ASCII text.
NOTE 1
ASCII filters serve no useful purpose in a PDF file that is encrypted; see 7.6, "Encryption".
NOTE 2
Compression is particularly valuable for large sampled images, since it reduces storage requirements and transmission time. Some types of compression are lossy, meaning that some data are lost during the encoding, resulting in a loss of quality when the data are decompressed. Compression in which no loss of data occurs is called lossless. Though somehow obvious it is worth pointing out that lossy compression can only be applied to sampled image data (and only certain types of lossy compression for certain types of images). Lossless compression on the other hand can be used for any kind of stream.
The standard filters are summarised in "Table 6 — Standard filters", which also indicates whether they accept any optional parameters. The following subclauses describe these filters and their parameters (if any) in greater detail, including specifications of encoding algorithms for some filters. Table 6 — Standard filters FILTER name
Parameters
Description
ASCIIHexDecode
no
Decodes data encoded in an ASCII hexadecimal representation, reproducing the original binary data.
ASCII85Decode
no
Decodes data encoded in an ASCII base-85 representation, reproducing the original binary data.
LZWDecode
yes
Decompresses data encoded using the LZW (Lempel-Ziv-Welch) adaptive compression method, reproducing the original text or binary data.
FlateDecode
yes
(PDF 1.2) Decompresses data encoded using the zlib/deflate compression method, reproducing the original text or binary data.
RunLengthDecode no
Decompresses data encoded using a byte-oriented run-length encoding algorithm, reproducing the original text or binary data (typically monochrome image data, or any data that contains frequent long runs of a single byte value).
CCITTFaxDecode
Decompresses data encoded using the CCITT facsimile standard, reproducing the original data (typically monochrome image data at 1 bit per pixel).
yes
© ISO 2020 – All rights reserved
35
ISO 32000-2:2020(E)
FILTER name
Parameters
Description
JBIG2Decode
yes
(PDF 1.4) Decompresses data encoded using the JBIG2 standard, reproducing the original monochrome (1 bit per pixel) image data (or an approximation of that data).
DCTDecode
yes
Decompresses data encoded using a DCT (discrete cosine transform) technique based on the JPEG standard (ISO/IEC 10918), reproducing image sample data that approximates the original data.
JPXDecode
no
(PDF 1.5) Decompresses data encoded using the wavelet-based JPEG 2000 standard, reproducing the original image data.
Crypt
yes
(PDF 1.5) Decrypts data encrypted by a security handler, reproducing the data as it was before encryption.
EXAMPLE 3
The following example shows a stream, containing the marking instructions for a page, that was compressed using the Flate compression method and then encoded in ASCII base-85 representation. The optional entry, DecodeParms is not used in this example, resulting in each filter using its default parameter values.
1 0 obj <</Length 447 /Filter [/ASCII85Decode /FlateDecode]
stream
GhQ\j_/=ii'LfceJ%/-bPR=PCD-LeMX!Z7pmG.BSJGfG1MH^^(F$rh*;h>h/i!XMIl:?" o%Tk8W%<tN0"eRE==1.4N>=Cc@SiF+*s\3snB>Y$n=^$I[!5nkk"\Wp1;WBoI"]#[bZ=Ou#c
QqtW?@3^VI[CftgH<HWngTU:T12>8lm%+Q=gI^i0+=:@fc@rHeGG!&rPQYfZ>YdpVeM._@ Z]46KR;P?sT-tkqXn4&]=EE2[h<FPBAePZJ9inNNF4R*)W-?\NH1C-GG&?=IC_>b%&++C2jo *B+a7eU&hee<0<F%-Y]De8<t.o"7p,rtNedLjK.J`kSL@c;BDEq+;F1Y?O)>keNVh+-(1S=
CQ?fQ_I]jWNcQe2XR^R#;3:<$\m;6d>@C3egX,+W+VfZ]X43r5*tiejhQe:!'jq$^jfSIj%
13FL
endstream
endobj
EXAMPLE 4
The following shows the same stream without any filters applied to it. (The stream’s contents are explained in 7.8.2, "Content streams" and the operators used there are further described in clause 9, "Text".)
1 0 obj
<</Length 562>>
stream
2 J
BT
/F1 12 Tf
0 Tc
0 Tw
72.5 712 TD
[(Unfiltered streams can be read easily) 65 (,)] TJ
0 -14 TD
[(b) 20 (ut generally tak) 10 (e more space than \311)] TJ
T*
(compressed streams.) Tj
0 -28 TD
[(Se) 25 (v) 15 (eral encoding methods are a) 20 (v) 25 (ailable in PDF) 80 (.)] TJ
0 -14 TD
(Some are used for compression and others simply) Tj
T*
[(to represent binary data in an) 55 (ASCII format.)] TJ
T*
(Some of the compression filters are
suitable) Tj
T*
36
© ISO 2020 – All rights reserved
ISO 32000-2:2020(E)
(for both data and images, while others are
suitable only) Tj
T*
(for continuous-tone images.) Tj
ET
endstream
endobj
7.4.2 ASCIIHexDecode filter The ASCIIHexDecode filter decodes data that has been encoded in ASCII hexadecimal form. ASCII hexadecimal encoding and ASCII base-85 encoding (7.4.3, "ASCII85Decode filter") convert binary data, such as image data or previously compressed data, to 7-bit ASCII characters. NOTE
ASCII base-85 encoding is preferred to ASCII hexadecimal encoding. Base-85 encoding is preferred because it is more compact: it expands the data by a factor of 4:5, compared with 1:2 for ASCII hexadecimal encoding.
The ASCIIHexDecode filter shall produce one byte of binary data for each pair of ASCII hexadecimal digits (0–9 and A–F or a–f). All white-space characters (see 7.2, "Lexical conventions") shall be ignored. A GREATER-THAN SIGN (3Eh) indicates EOD (End Of Data). Any other characters shall cause an error. If the filter encounters the EOD marker after reading an odd number of hexadecimal digits, it shall behave as if a 0 (zero) followed the last digit.
7.4.3 ASCII85Decode filter The ASCII85Decode filter decodes data that has been encoded in ASCII base-85 encoding and produces binary data. The following paragraphs describe the process for encoding binary data in ASCII base-85; the ASCII85Decode filter reverses this process. The ASCII base-85 encoding shall use the ASCII characters ! through u ((21h) - (75h)) and the character z (7Ah), with the 2-character sequence ~> (7Eh)(3Eh) as its EOD marker. The ASCII85Decode filter shall ignore all white-space characters (see 7.2, "Lexical conventions"). Any other characters, and any character sequences that represent impossible combinations in the ASCII base-85 encoding, shall cause an error. Specifically, ASCII base-85 encoding shall produce 5 ASCII characters for every 4 bytes of binary data. Each group of 4 binary input bytes, (b1 b2 b3 b4), shall be converted to a group of 5 output bytes, (𝑐1 𝑐2 𝑐3 𝑐4 𝑐5 ), using the relation (𝑏1 × 2563 ) + (𝑏2 × 2562 ) + (𝑏3 × 2561 ) + 𝑏4 = (𝑐1 × 854 ) + (𝑐2 × 853 ) + (𝑐3 × 852 ) + (𝑐4 × 851 ) + 𝑐5 In other words, 4 bytes of binary data shall be interpreted as a base-256 number and then shall be converted to a base-85 number. The five bytes of the base-85 number shall then be converted to ASCII characters by adding 33 (the ASCII code for the character !) to each. The resulting encoded data shall contain only printable ASCII characters with codes in the range 33 (!) to 117 (u). As a special case, if all five bytes are 0, they shall be represented by the character with code 122 (z) instead of by five exclamation points (! ! ! ! !). If the length of the data to be encoded is not a multiple of 4 bytes, the last, partial group of 4 shall be used to produce a last, partial group of 5 output characters. Given n (1, 2, or 3) bytes of binary data, the © ISO 2020 – All rights reserved
37
ISO 32000-2:2020(E)
encoder shall first append 4 - n zero bytes to make a complete group of 4. It shall encode this group in the usual way, but shall not apply the special z case. Finally, it shall write only the first n + 1 characters of the resulting group of 5. These characters shall be immediately followed by the ~> EOD marker. The following conditions shall never occur in a correctly encoded byte sequence: •
The value represented by a group of 5 characters is greater than 232 - 1.
•
A z character occurs in the middle of a group.
•
A final partial group contains only one character.
7.4.4 LZWDecode and FlateDecode filters 7.4.4.1
General
The LZWDecode and (PDF 1.2) FlateDecode filters have much in common and are discussed together in this subclause. They decode data that has been encoded using the LZW or Flate data compression method, respectively: •
LZW (Lempel-Ziv-Welch) is a variable-length, adaptive compression method that has been adopted as one of the standard compression methods in Adobe TIFF Revision 6.0; Final (TIFF). For details on LZW encoding see 7.4.4.2, "Details of LZW encoding".
•
The Flate method is based on the public-domain zlib/deflate compression method, which is a variable-length Lempel-Ziv adaptive compression method cascaded with adaptive Huffman coding. It is fully defined in Internet RFC 1950, and Internet RFC 1951.
Both of these methods compress either binary data or ASCII text but (like all compression methods) always produce binary data, even if the original data were text. The LZW and Flate compression methods can discover and exploit many patterns in the input data, whether the data are text or images. As described later, both filters support optional transformation by a predictor function, which improves the compression of sampled image data. NOTE 1
Because of its cascaded adaptive Huffman coding, Flate-encoded output is usually much more compact than LZW-encoded output for the same input. Flate and LZW decoding speeds are comparable, but Flate encoding is considerably slower than LZW encoding.
NOTE 2
Usually, both Flate and LZW encodings compress their input substantially. However, in the worst case (in which no pair of adjacent bytes appears twice), Flate encoding expands its input by no more than 11 bytes or a factor of 1.003 (whichever is larger), plus the effects of algorithm tags added by PNG predictors. For LZW encoding, the best case (all zeros) provides a compression approaching 1365:1 for long files, but the worst-case expansion is at least a factor of 1.125, which can increase to nearly 1.5 in some implementations, plus the effects of PNG tags as with Flate encoding.
7.4.4.2
Details of LZW encoding
Data encoded using the LZW compression method shall consist of a sequence of codes that are 9 to 12 bits long. Each code shall represent a single character of input data (0–255), a clear-table marker (256), an EOD marker (257), or a table entry representing a multiple-character sequence that has been encountered previously in the input (258 or greater). Initially, the code length shall be 9 bits and the LZW table shall contain only entries for the 258 fixed codes. As encoding proceeds, entries shall be appended to the table, associating new codes with longer 38
© ISO 2020 – All rights reserved
ISO 32000-2:2020(E)
and longer sequences of input characters. The encoder and the decoder shall maintain identical copies of this table. Whenever both the encoder and the decoder independently (but synchronously) realise that the current code length is no longer sufficient to represent the number of entries in the table, they shall increase the number of bits per code by 1. The first output code that is 10 bits long shall be the one following the creation of table entry 511, and similarly for 11 (1023) and 12 (2047) bits. Codes shall never be longer than 12 bits; therefore, entry 4095 is the last entry of the LZW table. The encoder shall execute the following sequence of steps to generate each output code: a) Accumulate a sequence of one or more input characters matching a sequence already present in the table. b) For maximum compression, the encoder looks for the longest such sequence. c) Emit the code corresponding to that sequence. d) Create a new table entry for the first unused code. Its value is the sequence found in step (a) followed by the next input character. EXAMPLE 1
Suppose the input consists of the following sequence of ASCII character codes:
45 45 45 45 45 65 45 45 45 66
Starting with an empty table, the encoder proceeds as shown in "Table 7 — Typical LZW encoding sequence". Table 7 — Typical LZW encoding sequence Input sequence Output code
Code added to Sequence represented by table new code
–
256 (clear-table)
–
–
45
45
258
45 45
45 45
258
259
45 45 45
45 45
258
260
45 45 65
65
65
261
65 45
45 45 45
259
262
45 45 45 66
66
66
–
–
–
257 (EOD)
–
–
Codes shall be packed into a continuous bit stream, high-order bit first. This stream shall then be divided into bytes, high-order bit first. Thus, codes may straddle byte boundaries arbitrarily. After the EOD marker (code value 257), any leftover bits in the final byte shall be set to 0. In the example above, all the output codes are 9 bits long; they would pack into bytes as follows © ISO 2020 – All rights reserved
39
ISO 32000-2:2020(E)
(represented in hexadecimal): EXAMPLE 2 80 0B 60 50 22 0C 0C 85 01
To adapt to changing input sequences, the encoder may at any point issue a clear-table code, which causes both the encoder and the decoder to restart with initial tables and a 9-bit code length. The encoder shall begin by issuing a clear-table code. It shall issue a clear-table code when the table becomes full; it may do so sooner.
7.4.4.3
LZWDecode and FlateDecode parameters
The LZWDecode and FlateDecode filters shall accept optional parameters to control the decoding process. NOTE
Most of these parameters are related to techniques that reduce the size of compressed sampled images (rectangular arrays of colour values, described in 8.9, "Images"). For example, image data typically changes very little from sample to sample. Therefore, subtracting the values of adjacent samples (a process called differencing), and encoding the differences rather than the raw sample values, can reduce the size of the output data. Furthermore, when the image data contains several colour components (red-green-blue or cyan-magenta-yellow-black) per sample, taking the difference between the values of corresponding components in adjacent samples, rather than between different colour components in the same sample, often reduces the output data size.
"Table 8 — Optional parameters for LZWDecode and FlateDecode filters" shows the parameters that may optionally be specified for LZWDecode and FlateDecode filters. Except where otherwise noted, all values supplied to the decoding filter for any optional parameters shall match those used when the data were encoded. Table 8 — Optional parameters for LZWDecode and FlateDecode filters
40
Key
Type
Value
Predictor
integer
A code that selects the predictor algorithm, if any. If the value of this entry is 1, the filter shall assume that the normal algorithm was used to encode the data, without prediction. If the value is greater than 1, the filter shall assume that the data were differenced before being encoded, and Predictor selects the predictor algorithm. For more information regarding Predictor values greater than 1, see 7.4.4.4, "LZW and Flate predictor functions". Default value: 1.
Colors
integer
(May be used only if Predictor is greater than 1) The number of interleaved colour components per sample. Valid values are 1 to 4 (PDF 1.0) and 1 or greater (PDF 1.3). Default value: 1.
BitsPerComponent
integer
(May be used only if Predictor is greater than 1) The number of bits used to represent each colour component in a sample. Valid values are 1, 2, 4, 8, and (PDF 1.5) 16. Default value: 8.
Columns
integer
(May be used only if Predictor is greater than 1) The number of samples in each row. Default value: 1.
© ISO 2020 – All rights reserved
ISO 32000-2:2020(E)
Key
Type
Value
EarlyChange
integer
(LZWDecode only) An indication of when to increase the code length. If the value of this entry is 0, code length increases shall be postponed as long as possible. If the value is 1, code length increases shall occur one code early. This parameter is included because LZW sample code distributed by some vendors increases the code length one code earlier than necessary. Default value: 1.
7.4.4.4
LZW and Flate predictor functions
LZW and Flate encoding compress more compactly if their input data are highly predictable. One way of increasing the predictability of many continuous-tone sampled images is to replace each sample with the difference between that sample and a predictor function applied to earlier neighbouring samples. If the predictor function works well, the postprediction data clusters toward 0. PDF files support two groups of predictor functions. The first, the TIFF group, shall be the single function that is Predictor 2 as defined in the Adobe TIFF Revision 6.0 specification. NOTE 1
In the Adobe TIFF Revision 6.0 specification, Predictor 2 applies only to LZW compression, but here it applies to Flate compression as well. TIFF Predictor 2 predicts that each colour component of a sample is the same as the corresponding colour component of the sample immediately to its left.
The second supported group of predictor functions, the PNG group, shall be the filters of the World Wide Web Consortium’s Portable Network Graphics recommendation, as defined in ISO/IEC 15948:2004. The term predictors is used here instead of filters to avoid confusion. “Table 9 — PNG predictor algorithms” lists the five basic PNG predictor algorithms (and a sixth that chooses the optimum predictor function separately for each row). Table 9 — PNG predictor algorithms PNG Predictor Algorithms
Description
None
No prediction
Sub
Predicts the same as the sample to the left
Up
Predicts the same as the sample above
Average
Predicts the average of the sample to the left and the sample above
Paeth
A nonlinear function of the sample above, the sample to the left, and the sample to the upper left
The predictor algorithm to be used, if any, shall be indicated by the Predictor filter parameter (see "Table 8 — Optional parameters for LZWDecode and FlateDecode filters"), whose value shall be one of © ISO 2020 – All rights reserved
41
ISO 32000-2:2020(E)
those listed in "Table 10 — Predictor values". For LZWDecode and FlateDecode, a Predictor value greater than or equal to 10 shall indicate that a PNG predictor is in use; the specific predictor function used shall be explicitly encoded in the incoming data. The value of Predictor supplied by the decoding filter need not match the value used when the data were encoded if they are both greater than or equal to 10. Table 10 — Predictor values Value
Meaning
1
No prediction (the default value)
2
TIFF Predictor 2
10
PNG prediction (on encoding, PNG None on all rows)
11
PNG prediction (on encoding, PNG Sub on all rows)
12
PNG prediction (on encoding, PNG Up on all rows)
13
PNG prediction (on encoding, PNG Average on all rows)
14
PNG prediction (on encoding, PNG Paeth on all rows)
15
PNG prediction (on encoding, PNG optimum)
The two groups of predictor functions have some commonalities. Both make the following assumptions: •
Data shall be presented in order, from the top row to the bottom row and, within a row, from left to right.
•
A row shall occupy a whole number of bytes, rounded up if necessary.
•
Samples and their components shall be packed into bytes from high-order to low-order bits.
•
All colour components of samples outside the image (which are necessary for predictions near the boundaries) shall be 0.
The predictor function groups also differ in significant ways: •
The postprediction data for each PNG-predicted row shall begin with an explicit algorithm tag; therefore, different rows can be predicted with different algorithms to improve compression. TIFF Predictor 2 has no such identifier; the same algorithm applies to all rows.
•
The TIFF function group shall predict each colour component from the prior instance of that component, taking into account the number of bits per component and components per sample. In contrast, the PNG function group shall predict each byte of data as a function of the corresponding byte of one or more previous image samples, regardless of whether there are multiple colour components in a byte or whether a single colour component spans multiple bytes.
NOTE 2
This can yield significantly better speed at the cost of somewhat worse compression.
7.4.5 RunLengthDecode filter The RunLengthDecode filter decodes data that has been encoded in a simple byte-oriented format 42
© ISO 2020 – All rights reserved
ISO 32000-2:2020(E)
based on run length. The encoded data shall be a sequence of runs, where each run shall consist of a length byte followed by 1 to 128 bytes of data. If the length byte is in the range 0 to 127, the following length + 1 (1 to 128) bytes shall be copied literally during decompression. If length is in the range 129 to 255, the following single byte shall be copied 257 - length (2 to 128) times during decompression. A length value of 128 shall denote EOD. NOTE
The compression achieved by run-length encoding depends on the input data. In the best case (all zeros), a compression of approximately 64:1 is achieved for long files. The worst case (the hexadecimal sequence 00 alternating with FF) results in an expansion of 127:128.
7.4.6 CCITTFaxDecode filter The CCITTFaxDecode filter decodes image data that has been encoded using either Group 3 or Group 4 CCITT facsimile (fax) encoding in accordance with ITU Recommendation T.4: Standardization of Group 3 facsimile terminals for document transmission and ITU Recommendation T.6: Facsimile coding schemes and coding control functions for Group 4 facsimile apparatus, International Telecommunication Union (ITU). NOTE 1
CCITT encoding is designed to achieve efficient compression of monochrome (1 bit per pixel) image data at relatively low resolutions, and so is useful only for bitmap image data, not for colour images, grayscale images, or general data.
NOTE 2
The CCITT encoding standard is defined by the International Telecommunications Union (ITU), formerly known as the Comité Consultatif International Téléphonique et Télégraphique (International Coordinating Committee for Telephony and Telegraphy). The encoding algorithm is not described in detail in this document but can be found in ITU Recommendations T.4 and T.6. For historical reasons, these documents are referred to as the CCITT standard.
CCITT encoding is bit-oriented, not byte-oriented. Therefore, in principle, encoded or decoded data need not end at a byte boundary. This problem shall be dealt with in the following ways: •
Unencoded data shall be treated as complete scan lines, with unused bits inserted at the end of each scan line to fill out the last byte. This approach is compatible with the PDF syntactic convention for sampled image data.
•
Encoded data shall ordinarily be treated as a continuous, unbroken bit stream. The EncodedByteAlign parameter (described in "Table 11 – Optional parameters for the CCITTFaxDecode filter") may be used to cause each encoded scan line to be filled to a byte boundary.
NOTE 3
•
Although this is not prescribed by the CCITT standard and fax machines never do this, some software packages find it convenient to encode data this way.
When a filter reaches EOD, it shall always skip to the next byte boundary following the encoded data.
The filter shall not perform any error correction or resynchronization, except as noted for the DamagedRowsBeforeError parameter in "Table 11 – Optional parameters for the CCITTFaxDecode filter". "Table 11 – Optional parameters for the CCITTFaxDecode filter" lists the optional parameters that may be used to control the decoding. Except where noted otherwise, all values supplied to the decoding filter by any of these parameters shall match those used when the data were encoded.
© ISO 2020 – All rights reserved
43
ISO 32000-2:2020(E)
Table 11 – Optional parameters for the CCITTFaxDecode filter Key
Type
Value
K
integer
A code identifying the encoding scheme used: <0 Pure two-dimensional encoding (Group 4) =0 Pure one-dimensional encoding (Group 3, 1-D)
0 Mixed one- and two-dimensional encoding (Group 3, 2-D), in which a line encoded one-dimensionally may be followed by at most K-1 lines encoded two-dimensionally The filter shall distinguish among negative, zero, and positive values of K to determine how to interpret the encoded data; however, it shall not distinguish between different positive K values. Default value: 0.
EndOfLine
boolean A flag indicating whether end-of-line bit patterns shall be present in the encoding. The CCITTFaxDecode filter shall always accept endof-line bit patterns. If EndOfLine is true end-of-line bit patterns shall be present. Default value: false.
EncodedByteAlign
boolean A flag indicating whether the filter shall expect extra 0 bits before each encoded line so that the line begins on a byte boundary. If true, the filter shall skip over encoded bits to begin decoding each line at a byte boundary. If false, the filter shall not expect extra bits in the encoded representation. Default value: false.
Columns
integer
The width of the image in pixels. If the value is not a multiple of 8, the filter shall adjust the width of the unencoded image to the next multiple of 8 so that each line starts on a byte boundary. Default value: 1728.
Rows
integer
The height of the image in scan lines. If the value is 0 or absent, the image’s height is not predetermined, and the encoded data shall be terminated by an end-of-block bit pattern or by the end of the filter’s data. Default value: 0.
EndOfBlock
boolean A flag indicating whether the filter shall expect the encoded data to be terminated by an end-of-block pattern, overriding the Rows parameter. If false, the filter shall stop when it has decoded the number of lines indicated by Rows or when its data has been exhausted, whichever occurs first. The end-of-block pattern shall be the CCITT end-of-facsimile-block (EOFB) or return-to-control (RTC) appropriate for the K parameter. Default value: true.
BlackIs1
boolean A flag indicating whether bits with a value of 1 shall be interpreted as black pixels and 0 bits as white pixels, the reverse of the normal PDF syntactic convention for image data. Default value: false.
DamagedRowsBeforeError integer
44
The number of damaged rows of data that shall be tolerated before an error occurs. This entry shall apply only if EndOfLine is true and K is non-negative. Tolerating a damaged row shall mean locating its end in the encoded data by searching for an EndOfLine pattern and then substituting decoded data from the previous row if the previous row was not damaged, or a white scan line if the previous row was also damaged. Default value: 0.
© ISO 2020 – All rights reserved
ISO 32000-2:2020(E)
NOTE 4
The compression achieved using CCITT encoding depends on the data, as well as on the value of various optional parameters. For Group 3 one-dimensional encoding, in the best case (all zeros), each scan line compresses to 4 bytes, and the compression factor depends on the length of a scan line. If the scan line is 300 bytes long, a compression ratio of approximately 75:1 is achieved. The worst case, an image of alternating ones and zeros, produces an expansion of 2:9.
7.4.7 JBIG2Decode filter The JBIG2Decode filter (PDF 1.4) decodes bitonal (1 bit per pixel) image data that has been encoded according to the JBIG2 standard as defined by ISO 14492:2019 excluding colour palette coding. While the JBIG2 compression method may also be used for encoding colour palette images into a JBIG2 bit stream, use of JBIG2 for PDF image XObjects shall be limited to using only bitonal (1 bit per pixel) in a JBIG2 coded bit stream. Specifically segments of type "colour palette" (type 54) shall not be present, and any segment and file header colour extension flag (COLEXTFLAG) shall be 0. NOTE 1
The JBIG2 standard defines a coding method for bi-level images (e.g., black and white pages). These are images consisting of a single rectangular bit plane, with each pixel taking on one of just two colours. It has been drafted by the Joint Bi-level Image Experts Group (JBIG), a committee established in 1988 that reports both to ISO/IEC JTC 1/SC29/WG1 and to ITU-T.
JBIG2, which supports both lossy and lossless compression, is useful for bitonal image data. JBIG2 explicitly defines the requirements of a compliant bitstream, and thus defines decoder behaviour. JBIG2 does not explicitly define a standard encoder, but instead is flexible enough to allow various approaches to encoder design. In general, JBIG2 provides considerably better compression of bitonal images than the CCITT standard (discussed in 7.4.6, "CCITTFaxDecode filter"). The compression it achieves depends strongly on the nature of the image. Images of pages containing text in any language compress particularly well. Where JBIG2 is used for lossy compression based on symbol dictionaries, care should be taken to avoid mismatches leading to character substitution (see 0.2.1 "Symbol coding" in ISO/IEC 14492:2019 for more details). While best compression is achieved for images of text, the JBIG2 standard also includes algorithms for representing regions of an image that contain dithered halftone images (for example, photographs) or line art. While the JBIG2 compression method may also be used for encoding multiple images into a single JBIG2 bit stream, use of JBIG2 for PDF image XObjects shall be limited to using only page 1 in a JBIG2 coded bit stream. This does not preclude the shared use of global segments across several JBIG2 encoded PDF image XObjects. NOTE 2
Typically, these images are scanned pages of a multiple-page document. Since a single table of symbol bitmaps can be used to match symbols across multiple pages, this type of encoding can result in higher compression ratios than if each of the pages had been individually encoded using JBIG2.
In general, an image can be specified in PDF files as either an image XObject or an inline image (as described in 8.9, "Images"); however, the JBIG2Decode filter shall not be used with inline images. Both single-page and multiple-page JBIG2 bit streams can be represented in PDF files by encoding each JBIG2 page as one PDF image XObject, as follows: •
The filter shall use the embedded file organisation of JBIG2 as defined in ISO/IEC 14492:2019, Annex D.3, "Embedded organization".
© ISO 2020 – All rights reserved
45
ISO 32000-2:2020(E)
•
The optional 2-byte combination (marker) defined in ISO/IEC 14492:2019, D.3, "Embedded organization" shall not be present.
•
JBIG2 bit streams shall be represented in sequential organisation as defined in ISO/IEC 14492:2019, D.1, "Sequential organisation".
•
The JBIG2 file header, end-of-page segments, and end-of-file segment shall not be present.
NOTE 3
It is recommended that segments appear in increasing order.
•
The image XObject to which the JBIG2Decode filter is applied shall contain all segments that are associated with the JBIG2 page represented by that image; that is, all segments whose segment page association field contains the page number of the JBIG2 page represented by the image. In the image XObject, however, the segment’s page number shall always be 1; that is, when each such segment is written to the XObject, the value of its segment page association field shall be set to 1.
•
If the bit stream contains global segments (segments whose segment page association field contains 0), these segments shall be placed in a separate PDF stream, and the filter parameter listed in "Table 12 — Optional parameter for the JBIG2Decode filter" shall refer to that stream. The stream may be shared by multiple image XObjects whose JBIG2 encoded streams use the same global segments. Table 12 — Optional parameter for the JBIG2Decode filter Key
Type
Value
JBIG2Globals
stream
A stream containing the JBIG2 global (page 0) segments. Global segments shall be placed in this stream even if only a single JBIG2 image XObject refers to it.
The following shows an image that was compressed according to the JBIG2 standard and then encoded in ASCII hexadecimal representation. Since the JBIG2 bit stream contains global segments, these segments are placed in a separate PDF stream, as indicated by the JBIG2Globals filter parameter. 5 0 obj <</Type /XObject /Subtype /Image /Width 52 /Height 66 /ColorSpace /DeviceGray /BitsPerComponent 1 /Length 224 /Filter [/ASCIIHexDecode /JBIG2Decode] /DecodeParms [null <</JBIG2Globals 6 0 R>>]
stream 000000013000010000001300000034000000420000000000 00000040000000000002062000010000001e000000340000 004200000000000000000200100000000231db51ce51ffac> endstream endobj 6 0 obj <</Length 126 /Filter /ASCIIHexDecode
stream 0000000000010000000032000003fffdff02fefefe000000 01000000012ae225aea9a5a538b4d9999c5c8e56ef0f872 7f2b53d4e37ef795cc5506dffac>
46
© ISO 2020 – All rights reserved
ISO 32000-2:2020(E)
endstream endobj
The original JBIG2 bit stream from which the image XObject for this example was constructed is as follows: 97 4A 42 32 0D 0A 1A 0A 01 00 00 00 01 00 00 00 00 00 01 00 00 00 00 32 00 00 03 FF FD FF 02 FE FE FE 00 00 00 01 00 00 00 01 2A E2 25 AE A9 A5 A5 38 B4 D9 99 9C 5C 8E 56 EF 0F 87 27 F2 B5 3D 4E 37 EF 79 5C C5 50 6D FF AC 00 00 00 01 30 00 01 00 00 00 13 00 00 00 34 00 00 00 42 00 00 00 00 00 00 00 00 40 00 00 00 00 00 02 06 20 00 01 00 00 00 1E 00 00 00 34 00 00 00 42 00 00 00 00 00 00 00 00 02 00 10 00 00 00 02 31 DB 51 CE 51 FF AC 00 00 00 03 31 00 01 00 00 00 00 00 00 00 04 33 01 00 00 00 00
This bit stream is made up of the following parts (in the order listed): a) The JBIG2 file header 97 4A 42 32 0D 0A 1A 0A 01 00 00 00 01
Since the JBIG2 file header is not allowed in a JBIG2 encoded image XObject in PDF files, this header is not placed in the JBIG2 stream object and is discarded. b) The first JBIG2 segment (segment 0) is a symbol dictionary segment 00 00 00 00 00 01 00 00 00 00 32 00 00 03 FF FD FF 02 FE FE FE 00 00 00 01 00 00 00 01 2A E2 25 AE A9 A5 A5 38 B4 D9 99 9C 5C 8E 56 EF 0F 87 27 F2 B5 3D 4E 37 EF 79 5C C5 50 6D FF AC
This is a global segment (segment page association = 0) and thus is placed in the JBIG2Globals stream. c) The next segments are the page information segment 00 00 00 01 30 00 01 00 00 00 13 00 00 00 34 00 00 00 42 00 00 00 00 00 00 00 00 40 00 00
and the immediate text region segment 00 00 00 02 06 20 00 01 00 00 00 1E 00 00 00 34 00 00 00 42 00 00 00 00 00 00 00 00 02 00 10 00 00 00 02 31 DB 51 CE 51 FF AC
These two segments constitute the contents of the JBIG2 page and are placed in the image XObject representing this image. d) The last segments are the end-of-page segment 00 00 00 03 31 00 01 00 00 00 00
and the end-of-file segment 00 00 00 04 33 01 00 00 00 00
Since these segments are not allowed in a JBIG2 encoded image XObject in PDF files, they are discarded. The resulting PDF image XObject, then, contains the page information segment and the immediate text region segment and refers to a JBIG2Globals stream that contains the symbol dictionary segment.
© ISO 2020 – All rights reserved
47
ISO 32000-2:2020(E)
7.4.8 DCTDecode filter The DCTDecode filter decodes grayscale or colour image data that has been encoded in the JPEG baseline format in accordance with ISO/IEC 10918 (all parts). Refer also to Adobe Technical Note #5116, Supporting the DCT Filters in PostScript Level 2, for additional information about the use of JPEG "markers". NOTE 1
JPEG stands for the Joint Photographic Experts Group, a group within the International Organization for Standardization that developed the format; DCT stands for discrete cosine transform, the primary technique used in the encoding.
JPEG encoding is a lossy compression method, designed specifically for compression of sampled continuous-tone images and not for general data compression. Data to be encoded using JPEG shall consist of a stream of image samples, each consisting of one, three, or four colour components. The colour component values for a particular sample shall appear consecutively. Each component value shall occupy a byte. During encoding, several parameters shall control the algorithm and the information loss. The values of these parameters, which include the dimensions of the image and the number of components per sample, are entirely under the control of the encoder and shall be stored in the encoded data. DCTDecode may obtain the parameter values it requires directly from the encoded data. However, in one instance, the parameter need not be present in the encoded data but shall be specified in the filter parameter dictionary; see "Table 13 – Optional parameter for the DCTDecode filter". The details of the encoding algorithm are not presented here but are in the ISO JPEG standard. Briefly, the JPEG algorithm breaks an image up into blocks that are 8 samples wide by 8 samples high. Each colour component in an image is treated separately. A two-dimensional DCT is performed on each block. This operation produces 64 coefficients, which are then quantised. Each coefficient can be quantised with a different step size. It is this quantization that results in the loss of information in the JPEG algorithm. The quantised coefficients are then compressed.
48
© ISO 2020 – All rights reserved
ISO 32000-2:2020(E)
Table 13 – Optional parameter for the DCTDecode filter Key
Type
ColorTransform integer
Value (Optional) A code specifying the transformation that shall be performed on the sample values: 0 No transformation. 1 If the image has three colour components, RGB values shall be transformed to YCbCr before encoding and from YCbCr to RGB after decoding. If the image has four components, CMYK values shall be transformed to YCbCrK before encoding and from YCbCrK to CMYK after decoding. This option shall be ignored if the image has one or two colour components. If the encoding algorithm has inserted the Adobe-defined marker code in the encoded data indicating the ColorTransform value, then the colours shall be transformed, or not, after the DCT decoding has been performed according to the value provided in the encoded data and the value of this dictionary entry shall be ignored. If the Adobe-defined marker code in the encoded data indicating the ColorTransform value is not present then the value specified in this dictionary entry will be used. If the Adobe-defined marker code (APP14) in the encoded data indicating the ColorTransform value is not present and this dictionary entry is not present in the filter dictionary then the default value of ColorTransform shall be 1 if the image has three components and 0 otherwise. Parameters that control the decoding process as well as other metadata are embedded within the encoded data stream using a notation referred to as "markers". When Adobe Systems Incorporated defined the use of JPEG images within PostScript language data streams, Adobe defined a particular set of rules pertaining to which markers are to be recognised, which are to be ignored and which are considered errors. A specific Adobe-defined marker (X’FFEE, sometimes called ‘APPE’ or ‘APP14’) was also introduced. The exact rules for producing and consuming DCT encoded data within PostScript language are provided in Adobe Technical Note #5116 and PDF DCT encoding shall exactly follow all those rules established by Adobe for the PostScript language.
NOTE 2
The encoding algorithm can reduce the information loss by making the step size in the quantization smaller at the expense of reducing the amount of compression achieved by the algorithm. The compression achieved by the JPEG algorithm depends on the image being compressed and the amount of loss that is acceptable. In general, a compression of 15:1 can be achieved without perceptible loss of information, and 30:1 compression causes little impairment of the image.
NOTE 3
Better compression is often available for colour spaces that treat luminance and chrominance separately than for those that do not. The RGB-to-YCbCr conversion provided by the filters is one attempt to separate luminance and chrominance; it conforms to CCIR recommendation 601-1. Other colour spaces, such as the CIE 1976 Lab* space, can also achieve this objective. The chrominance components can then be compressed more than the luminance by using coarser sampling or quantization, with no degradation in quality.
In addition to the baseline JPEG format, beginning with PDF 1.3, the DCTDecode filter shall support the progressive JPEG extension. This extension does not add any entries to the DCTDecode parameter © ISO 2020 – All rights reserved
49
ISO 32000-2:2020(E)
dictionary; the distinction between baseline and progressive JPEG shall be represented in the encoded data. NOTE 4
There is no benefit to using progressive JPEG for stream data that is embedded in a PDF file. Decoding progressive JPEG is slower and consumes more memory than baseline JPEG. The purpose of this feature is to enable a stream to refer to an external file whose data happens to be already encoded in progressive JPEG.
7.4.9 JPXDecode filter The JPXDecode filter (PDF 1.5) decodes data that has been encoded using the JPEG 2000 compression method, an International Standard for the compression and packaging of image data. See ISO/IEC 15444-1, Information technology — JPEG 2000 image coding system: Core coding system and ISO/IEC 15444-2, Information Technology — JPEG 2000 image coding system: Extensions, available from http://www.jpeg.org/jpeg2000/. NOTE 1
JPEG 2000 defines a wavelet-based method for image compression that gives somewhat better size reduction than other methods such as regular JPEG or CCITT. Also, the filter can reproduce samples that are losslessly compressed.
This filter shall only be applied to image XObjects, and not to inline images (see 8.9, "Images"). It is suitable both for images that have a single colour component and for those that have multiple colour components. The colour components in an image may have different numbers of bits per sample, however bits per sample shall be between 1 to 38 inclusive. NOTE 2
From a single JPEG 2000 data stream, multiple versions of an image can be decoded. These different versions form progressions along four degrees of freedom: sampling resolution, colour depth, band, and location. For example, with a resolution progression, a thumbnail version of the image can be decoded from the data, followed by a sequence of other versions of the image, each with approximately four times as many samples (twice the width times twice the height) as the previous one. The last version is the full-resolution image.
NOTE 3
Viewing and printing applications can gain performance benefits by using the resolution progression. If the full-resolution image is densely sampled, an application can select and decode only the data making up a lower-resolution version, thereby spending less time decoding. Fewer bytes need be processed, a particular benefit when viewing files over the Web. The tiling structure of the image can also provide benefits if only certain areas of an image need to be displayed or printed.
NOTE 4
Information on these progressions is encoded in the data; no decode parameters are needed to describe them. The decoder deals with any progressions it encounters to deliver the correct image data. Progressions that are of no interest can simply have performance consequences.
The JPEG 2000 specifications define two widely used formats, JP2 and JPX, for packaging the compressed image data. JP2 is a subset of JPX. These packagings contain all the information needed to properly interpret the image data, including the colour space, bits per component, and image dimensions. In other words, they are complete descriptions of images (as opposed to image data that require outside parameters for correct interpretation). The JPXDecode filter shall expect to read a full JPX file structure – either internal to the PDF file or as an external file. NOTE 5
To promote interoperability, the specifications define a subset of JPX called JPX baseline (of which JP2 is also a subset). The complete details of the baseline set of JPX features are contained in ISO/IEC 15444-2.
Data used in PDF image XObjects shall be limited to the JPX baseline set of features, except for enumerated colour space 19 (CIEJab). In addition, enumerated colour space 12 (CMYK), which is part 50
© ISO 2020 – All rights reserved
ISO 32000-2:2020(E)
of JPX but not JPX baseline, shall be supported in a PDF file. JPX file structures used in PDF files shall conform to the JPEG 2000 specification. A JPX file describes a collection of channels that are present in the image data. A channel may have one of three types: •
An ordinary channel contains values that, when decoded, shall become samples for a specified colour component.
•
An opacity channel provides samples that shall be interpreted as raw opacity information.
•
A premultiplied opacity channel shall provide samples that have been multiplied into the colour samples of those channels with which it is associated.
JPX opacity and premultiplied opacity channels are associated with specific colour channels. There shall not be more than one opacity channel (of either type) associated with a given colour channel. EXAMPLE
It is possible for one opacity channel to apply to the red samples and another to apply to the green and blue colour channels of an RGB image.
NOTE 6
The method by which the opacity information is to be used is explicitly not specified, although one available method shows a normal blending mode.
NOTE 7
As specified below, if JPX opacity is used in PDF files, then the JPX data are only allowed to have one opacity channel, and this single channel is required to be associated with all colour channels.
In addition to using opacity channels for describing transparency, JPX files also have the ability to specify chroma-key transparency. A single colour may be specified by giving an array of values, one value for each colour channel. Any image location that matches this colour shall be considered to be completely transparent. For JPX files used in PDF files, the chroma-key transparency shall be ignored. NOTE 8
For images in PDF files a similar mechanism exists, which allows to specify a range of colours to be considered transparent; see 8.9.6.4, "Colour key masking".
Images in JPX files may have one of the following colour spaces: •
A predefined colour space, chosen from a list of enumerated colour spaces. (Two of these are actually families of spaces and parameters are included.)
•
A restricted ICC profile. These are the only sorts of ICC profiles that are allowed in JP2 files.
•
An input ICC profile of any sort defined by ICC.1.
•
A vendor-defined colour space.
More than one colour space may be specified for an image, with each space being tagged with a precedence and an approximation value that indicates how well it represents the preferred colour space. In addition, the image’s colour space may serve as the foundation for a palette of colours that are selected using samples coming from the image’s data channels: the equivalent of an Indexed colour space in PDF syntax. There are other features in the JPX format beyond describing a simple image; they are not supported in PDF files. These include provisions for describing layering and giving instructions on composition and specifying simple animation. Relevant metadata should be replicated in the image dictionary’s Metadata stream in XMP format (see 14.3.2, "Metadata streams"). When using the JPXDecode filter with image XObjects, the following changes to and constraints on some entries in the image dictionary shall apply (see 8.9.5, "Image dictionaries" for details on these © ISO 2020 – All rights reserved
51
ISO 32000-2:2020(E)
entries): •
Width and Height shall match the corresponding width and height values in the JPEG 2000 data.
•
ColorSpace shall be optional since JPEG 2000 data contain colour space specifications. If present, it shall determine how the image samples are interpreted, and the colour space specifications in the JPEG 2000 data shall be ignored. The number of ordinary colour channels in the JPEG 2000 data shall match the number of components in the colour space; a PDF writer shall ensure that the samples are consistent with the colour space used.
•
Any colour space other than Pattern may be specified. If an Indexed colour space is used, it shall be subject to the PDF syntactic limit of 256 colours. If the colour space does not match one of JPX’s enumerated colour spaces (for example, if it has two colour components or more than four), it should be specified as a vendor colour space in the JPX data.
•
If ColorSpace is not present in the image dictionary, the colour space information in the JPEG 2000 data shall be used. A JPEG 2000 image within a PDF file shall have one of: the baseline JPX colour spaces excluding enumerated colour space 19 (CIEJab); or enumerated colour space 12 (CMYK); or at least one ICC profile that is valid within PDF files. PDF processors shall support the JPX baseline set of enumerated colour spaces; they shall also be responsible for dealing with the interaction between the colour spaces and the bit depth of samples.
NOTE 9
The above bullet point was clarified in this document (2020).
•
If multiple colour space specifications are given in the JPEG 2000 data, a PDF processor should attempt to use the one with the highest precedence and best approximation value. If the colour space is given by an unsupported ICC profile, the next lower colour space, in terms of precedence and approximation value, shall be used. If no supported colour space is found, the colour space used shall be DeviceGray, DeviceRGB, or DeviceCMYK, depending on the whether the number of ordinary channels in the JPEG 2000 data is 1, 3, or 4.
•
SMaskInData specifies whether soft-mask information packaged with the image samples shall be used (see 11.6.5.2, "Soft-mask images"); if it is, the SMask entry shall not be present. If SMaskInData is non-zero, there shall be only one opacity channel in the JPEG 2000 data and it shall apply to all colour channels.
•
If ColorSpace is absent, then the Decode array shall be ignored unless ImageMask is true.
•
If ImageMask is true, the JPEG 2000 data shall provide a single colour channel with 1-bit samples.
7.4.10
Crypt filter
The Crypt filter (PDF 1.5) allows the document-level security handler (see 7.6, "Encryption") to determine which algorithms should be used to decrypt the input data. The Name parameter in the decode parameters dictionary for this filter (see "Table 14 — Optional parameters for Crypt filters") shall specify which of the named crypt filters in the document (see 7.6.6, "Crypt filters") shall be used. The Crypt filter shall be the first filter in the Filter array entry. Table 14 — Optional parameters for Crypt filters
52
Key
Type
Value
Type
name
(Optional) If present, shall be CryptFilterDecodeParms for a Crypt filter decode parameter dictionary.
© ISO 2020 – All rights reserved
ISO 32000-2:2020(E)
Key
Type
Value
Name
name
(Optional) The name of the crypt filter that shall be used to decrypt this stream. The name shall correspond to an entry in the CF entry of the encryption dictionary (see "Table 20 — Entries common to all encryption dictionaries") or one of the standard crypt filters (see "Table 26 — Standard crypt filter names"). Default value: Identity.
In addition, the decode parameters dictionary may include entries that are private to the security handler. Security handlers may use information from both the crypt filter decode parameters dictionary and the crypt filter dictionaries (see "Table 25 — Entries common to all crypt filter dictionaries") when decrypting data or providing a key to decrypt data. NOTE
When adding private data to the decode parameters dictionary, security handlers are required to name these entries as defined by Annex E, "Extending PDF".
If a stream specifies a crypt filter, then the security handler does not apply "Algorithm 1: Encryption of data using the RC4 or AES algorithms" in 7.6.3, "General encryption algorithm" to the key prior to decrypting the stream. Instead, the security handler shall decrypt the stream using the key as is. 7.4, "Filters" explains how a stream specifies filters.
Navigation: PDF20-Spec-07-Objects | PDF20-Spec-Index | PDF20-Spec-07-File-Structure