• Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint

4.8. Images

PDF's painting operators include general facilities for dealing with sampled images. A sampled image (or just image for short) is a rectangular array of sample values, each representing a color. The image may approximate the appearance of some natural scene obtained through an input scanner or a video camera, or it may be generated synthetically.

Figure 4.25. Typical sampled image

An image is defined by a sequence of samples obtained by scanning the image array in row or column order. Each sample in the array consists of as many color components as are needed for the color space in which they are specified—for example, one component for DeviceGray, three for DeviceRGB, four for DeviceCMYK, or whatever number is required by a particular DeviceN space. Each component is a 1-, 2-, 4-, 8-, or (in PDF 1.5) 16-bit integer, permitting the representation of 2, 4, 16, 256, or (in PDF 1.5) 65536 distinct values for each component. (Other component sizes can be accommodated when a JPXDecode filter is used; see Section 3.3.8, “ JPXDecode Filter.)

PDF provides two means for specifying images:

  • An image XObject (described in Section 4.8.4, “Image Dictionaries”) is a stream object whose dictionary specifies attributes of the image and whose data contains the image samples. Like all external objects, it is painted on the page by invoking the Do operator in a content stream (see Section 4.7, “External Objects”). Image XObjects have other uses as well, such as for alternate images (see “Alternate Images” on page 319), image masks (Section 4.8.5, “Masked Images”), and thumbnail images (Section 8.2.3, “Thumbnail Images”).

  • An inline image is a small image that is completely defined—both attributes and data—directly inline within a content stream. The kinds of images that can be represented in this way are limited; see Section 4.8.6, “Inline Images,” for details.

4.8.1. Image Parameters

The properties of an image—resolution, orientation, scanning order, and so forth—are entirely independent of the characteristics of the raster output device on which the image is to be rendered. A PDF consumer application usually renders images by a sampling technique that attempts to approximate the color values of the source as accurately as possible. The actual accuracy achieved depends on the resolution and other properties of the output device.

To paint an image, four interrelated items must be specified:

  • The format of the image: number of columns (width), number of rows (height), number of color components per sample, and number of bits per color component

  • The sample data constituting the image's visual content

  • The correspondence between coordinates in user space and those in the image's own internal coordinate space, defining the region of user space that will receive the image

  • The mapping from color component values in the image data to component values in the image's color space

All of these items are specified explicitly or implicitly by an image XObject or an inline image.


For convenience, the following sections refer consistently to the object defining an image as an image dictionary. Although this term properly refers only to the dictionary portion of the stream object representing an image XObject, it should be understood to apply equally to the stream's data portion or to the parameters and data of an inline image.

4.8.2. Sample Representation

The source format for an image can be described by four parameters:

  • The width of the image in samples

  • The height of the image in samples

  • The number of color components per sample

  • The number of bits per color component

The image dictionary specifies the width, height, and number of bits per component explicitly. The number of color components can be inferred from the color space specified in the dictionary.


For images using the JPXDecode filter (see, Section 3.3.8, “ JPXDecode Filter”), the number of bits per component is determined from the image data and not specified in the image dictionary. The color space may or may not be specified in the dictionary.

Sample data is represented as a stream of bytes, interpreted as 8-bit unsigned integers in the range 0 to 255. The bytes constitute a continuous bit stream, with the high-order bit of each byte first. This bit stream, in turn, is divided into units of n bits each, where n is the number of bits per component. Each unit encodes a color component value, given with high-order bit first; units of 16 bits are given with the most significant byte first. Byte boundaries are ignored, except that each row of sample data must begin on a byte boundary. If the number of data bits per row is not a multiple of 8, the end of the row is padded with extra bits to fill out the last byte. A PDF consumer application ignores these padding bits.

Each n-bit unit within the bit stream is interpreted as an unsigned integer in the range 0 to 2n - 1, with the high-order bit first. The image dictionary's Decode entry maps this integer to a color component value, equivalent to what could be used with color operators such as sc or g. Color components are interleaved sample by sample; for example, in a three-component RGB image, the red, green, and blue components for one sample are followed by the red, green, and blue components for the next.

Normally, the color samples in an image are interpreted according to the color space specified in the image dictionary (see Section 4.5, “Color Spaces”), without reference to the color parameters in the graphics state. However, if the image dictionary's ImageMask entry is true, the sample data is interpreted as a stencil mask for applying the graphics state's nonstroking color parameters (see “Stencil Masking” on page 322).

4.8.3. Image Coordinate System

Each image has its own internal coordinate system, or image space. The image occupies a rectangle in image space w units wide and h units high, where w and h are the width and height of the image in samples. Each sample occupies one square unit. The coordinate origin (0, 0) is at the upper-left corner of the image, with coordinates ranging from 0 to w horizontally and 0 to h vertically.

The image's sample data is ordered by row, with the horizontal coordinate varying most rapidly. This is shown in Figure 4.26, where the numbers inside the squares indicate the order of the samples, counting from 0. The upper-left corner of the first sample is at coordinates (0, 0), the second at (1, 0), and so on through the last sample of the first row, whose upper-left corner is at (w - 1, 0) and whose upper-right corner is at (w, 0). The next samples after that are at coordinates (0, 1), (1, 1), and so on to the final sample of the image, whose upper-left corner is at (w - 1, h - 1) and whose lower-right corner is at (w, h).

Figure 4.26. Source image coordinate system


The image coordinate system and scanning order imposed by PDF do not preclude using different conventions in the actual image. Coordinate transformations can be used to map from other conventions to the PDF convention.

The correspondence between image space and user space is constant: the unit square of user space, bounded by user coordinates (0, 0) and (1, 1), corresponds to the boundary of the image in image space (see Figure 4.27). Following the normal convention for user space, the coordinate (0, 0) is at the lower-left corner of this square, corresponding to coordinates (0, h) in image space. The transformation from image space to user space could be described by the matrix [1/w 0 0 -1/h 0 1].

Figure 4.27. Mapping the source image

An image can be placed on the output page in any position, orientation, and size by using the cm operator to modify the current transformation matrix (CTM) so as to map the unit square of user space to the rectangle or parallelogram in which the image is to be painted. Typically, this is done within a pair of q and q operators to isolate the effect of the transformation, which can include translation, rotation, reflection, and skew (see Section 4.2, “Coordinate Systems”). For example, if the XObject subdictionary of the current resource dictionary defines the name Image1 to denote an image XObject, the code shown in Example 3.27 paints the image in a rectangle whose lower-left corner is at coordinates (100, 200), that is rotated 45 degrees counterclockwise, and that is 150 units wide and 80 units high.

Example 4.27.

q                                        % Save graphics state
  1 0 0 1 100 200 cm                     % Translate
  0.7071 0.7071 -0.7071 0.7071 0 0 cm    % Rotate
  150 0 0 80 0 0 cm                      % Scale
 /Image1 Do                              % Paint image
Q                                        % Restore graphics state

(As discussed in Section 4.2.3, “Transformation Matrices,” these three transformations could be combined into one.) Of course, if the aspect ratio (width to height) of the original image in this example is different from 150:80, the result will be distorted.

4.8.4. Image Dictionaries

An image dictionary—that is, the dictionary portion of a stream representing an image XObject—can contain the entries listed in Table 4.39 in addition to the usual entries common to all streams (see Table 3.4 on page 38). There are many relationships among these entries, and the current color space may limit the choices for some of them. Attempting to use an image dictionary whose entries are inconsistent with each other or with the current color space causes an error.


The entries described here are appropriate for a base image—one that is invoked directly with the Do operator. Some of the entries are not relevant for images used in other ways, such as for alternate images (see “Alternate Images” on page 319), image masks (Section 4.8.5, “Masked Images”), or thumbnail images (Section 8.2.3, “Thumbnail Images”). Except as noted, such irrelevant entries are simply ignored.

Table 4.39. Additional entries specific to an image dictionary
TYPEname(Optional) The type of PDF object that this dictionary describes; if present, must be XObject for an image XObject.
Subtypename(Required) The type of XObject that this dictionary describes; must be Image for an image XObject.
Widthinteger(Required) The width of the image, in samples.
Heightinteger(Required) The height of the image, in samples.
ColorSpacename or array(Required for images, except those that use the JPXDecode filter; not allowed for image masks) The color space in which image samples are specified; it can be any type of color space except Pattern. If the image uses the JPXDecode filter, this entry is optional:
  • If ColorSpace is present, any color space specifications in the JPEG2000 data are ignored.

  • If ColorSpace is absent, the color space specifications in the JPEG2000 data are used. The Decode array is also ignored unless ImageMask is true.

BitsPerComponentinteger(Required except for image masks and images that use the JPXDecode filter) The number of bits used to represent each color component. Only a single value may be specified; the number of bits is the same for all color components. Valid values are 1, 2, 4, 8, and (in PDF 1.5) 16. If ImageMask is true, this entry is optional, and if specified, its value must be 1.

If the image stream uses a filter, the value of BitsPerComponent must be consistent with the size of the data samples that the filter delivers. In particular, a CCITTFaxDecode or JBIG2Decode filter always delivers 1-bit samples, a RunLengthDecode or DCTDecode filter delivers 8-bit samples, and an LZWDecode or FlateDecode filter delivers samples of a specified size if a predictor function is used.

If the image stream uses the JPXDecode filter, this entry is optional and ignored if present. The bit depth is determined in the process of decoding the JPEG2000 image.
Intentname(Optional; PDF 1.1) The name of a color rendering intent to be used in rendering the image (see “Rendering Intents” on page 231). Default value: the current rendering intent in the graphics state.
ImageMaskboolean(Optional) A flag indicating whether the image is to be treated as an image mask (see Section 4.8.5, “Masked Images”). If this flag is true, the value of BitsPerComponent must be 1 and Mask and ColorSpace should not be specified; unmasked areas are painted using the current nonstroking color. Default value: false.
Maskstream or array(Optional except for image masks; not allowed for image masks; PDF 1.3) An image XObject defining an image mask to be applied to this image (see “Explicit Masking” on page 323), or an array specifying a range of colors to be applied to it as a color key mask (see “Color Key Masking” on page 323). If ImageMask is true, this entry must not be present. (See implementation note 51 in Appendix H.)
Decodearray(Optional) An array of numbers describing how to map image samples into the range of values appropriate for the image's color space (see “Decode Arrays” on page 316). If ImageMask is true, the array must be either [01] or [10]; otherwise, its length must be twice the number of color components required by ColorSpace. If the image uses the JPXDecode filter and ImageMask is false, Decode is ignored. Default value: see “Decode Arrays” on page 316.
Interpolateboolean(Optional) A flag indicating whether image interpolation is to be performed (see “Image Interpolation” on page 318). Default value: false.
Alternatesarray(Optional; PDF 1.3) An array of alternate image dictionaries for this image (see “Alternate Images” on page 319). The order of elements within the array has no significance. This entry may not be present in an image XObject that is itself an alternate image.
SMaskstream(Optional; PDF 1.4) A subsidiary image XObject defining a soft-mask image (see “Soft-Mask Images” on page 522) to be used as a source of mask shape or mask opacity values in the transparent imaging model. The alpha source parameter in the graphics state determines whether the mask values are interpreted as shape or opacity. If present, this entry overrides the current soft mask in the graphics state, as well as the image's Mask entry, if any. (However, the other transparency-related graphics state parameters—blend mode and alpha constant—remain in effect.) If SMask is absent, the image has no associated soft mask (although the current soft mask in the graphics state may still apply).
SMaskInDatainteger(Optional for images that use the JPXDecode filter, meaningless otherwise; PDF 1.5) A code specifying how soft-mask information (see “Soft-Mask Images” on page 522) encoded with image samples should be used:
0If present, encoded soft-mask image information should be ignored.
1The image's data stream includes encoded soft-mask values. An application can create a soft-mask image from the information to be used as a source of mask shape or mask opacity in the transparency imaging model.
2The image's data stream includes color channels that have been preblended with a background; the image data also includes an opacity channel. An application can create a soft-mask image with a Matte entry from the opacity channel information to be used as a source of mask shape or mask opacity in the transparency model.

If this entry has a nonzero value, SMask should not be specified. See also Section 3.3.8, “JPXDecode Filter.”

Default value: 0.
Namename(Required in PDF 1.0; optional otherwise) The name by which this image XObject is referenced in the XObject subdictionary of the current resource dictionary (see Section 3.7.2, “Resource Dictionaries”).


This entry is obsolescent and its use is no longer recommended. (See implementation note 52 in Appendix H.)

StructParentinteger(Required if the image is a structural content item; PDF 1.3) The integer key of the image's entry in the structural parent tree (see “Finding Structure Elements from Content Items” on page 797).
IDstring(Optional; PDF 1.3; indirect reference preferred) The digital identifier of the image's parent Web Capture content set (see Section 10.9.5, “Object Attributes Related to Web Capture”).
OPIdictionary(Optional; PDF 1.2) An OPI version dictionary for the image (see Section 10.10.6, “Open Prepress Interface (OPI)”). If ImageMask is true, this entry is ignored.
Metadatastream(Optional; PDF 1.4) A metadata stream containing metadata for the image (see Section 10.2.2, “Metadata Streams”).
OCdictionary(Optional; PDF 1.5) An optional content group or optional content membership dictionary (see Section 4.10, “Optional Content”), specifying the optional content properties for this image XObject. Before the image is processed, its visibility is determined based on this entry. If it is determined to be invisible, the entire image is skipped, as if there were no Do operator to invoke it.

Example 4.28 defines an image 256 samples wide by 256 high, with 8 bits per sample in the DeviceGray color space. It paints the image on a page with its lowerleft corner positioned at coordinates (45, 140) in current user space and scaled to a width and height of 132 user space units.

Example 4.28.

2 0 0 obj                                  % Page object
   << /Type /Page
      /Parent 1 0 R
      /Resources 21 0 R
      /MediaBox [0 0 612 792]
      /Contents 23 0 R
21 0 obj                                   % Resource dictionary for page
   << /ProcSet [/PDF /ImageB]
      /XObject << /Im1 22 0 R >>
22 0 obj                                   % Image XObject
   << /Type /XObject
      /Subtype /Image
      /Width 256
      /Height 256
      /ColorSpace /DeviceGray
      /BitsPerComponent 8
      /Length 83183
      /Filter /ASCII85Decode
   … Image data representing 65,536 samples …

   23 0 obj                                     % Contents of page
       q                                      % Save graphics state
         1320013245140cm                      % Translate to (45,140) and scale by 132
         /Im1Do                               % Paint image
       Q                                      % Restore graphics state


Decode Arrays

An image's data stream is initially decomposed into integers in the domain 0 to 2n - 1, where n is the value of the image dictionary's BitsPerComponent entry. The image's Decode array specifies a linear mapping of each integer component value to a number that would be appropriate as a component value in the image's color space.

Each pair of numbers in a Decode array specifies the lower and upper values to which the domain of sample values in the image is mapped. A Decode array contains one pair of numbers for each component in the color space specified by the image's ColorSpace entry. The mapping for each color component is a linear transformation; that is, it uses the following formula for linear interpolation:

Generally, this formula is used to convert a value x between xmin and xmax to a corresponding value y between ymin and ymax, projecting along the line defined by the points (xmin, ymin) and (xmax, ymax). While this formula applies to values outside the domain xmin to xmax and does not require that xmin < xmax, note that interpolation used for color conversion, such as the Decode array, does require that xmin < xmax and clips x values to this domain so that yymin for all xxmin, and yymax for all xxmax .

For a Decode array of the form [Dmin Dmax], this can be written as


n is the value of BitsPerComponent

x is the input value, in the domain 0 to 2n − 1

Dmin and Dmax are the values specified in the Decode array

y is the output value, to be interpreted in the image's color space

Samples with a value of 0 are mapped to Dmin, those with a value of 2n − 1 are mapped to Dmax, and those with intermediate values are mapped linearly between Dmin and Dmax . Table 4.40 lists the default Decode arrays for use with the various color spaces. For most color spaces, the Decode arrays listed in the table map into the full range of allowed component values. For an Indexed color space, the default Decode array ensures that component values that index a color table are passed through unchanged.

Table 4.40. Default Decode arrays
DeviceGray[0.0 1.0]
DeviceRGB[0.0 1.0 0.0 1.0 0.0 1.0]
DeviceCMYK[0.0 1.0 0.0 1.0 0.0 1.0 0.0 1.0]
CalGray[0.0 1.0]
CalRGB[0.0 1.0 0.0 1.0 0.0 1.0]
Lab[0 100 amin amax bmin bmax] where amin, amax, bmin, and bmax correspond to the values in the Range array of the image's color space
ICCBasedSame as the value of Range in the ICC profile of the image's color space
Indexed[0N], where N = 2n - 1
Pattern(Not permitted with images)
Separation[0.0 1.0]
DeviceN[0.0 1.0 0.0 1.0 … 0.0 1.0] (one pair of elements for each color component)

It is possible to specify a mapping that inverts sample color intensities by specifying a Dmin value greater than Dmax . For example, if the image's color space is DeviceGray and the Decode array is [1.0 0.0], an input value of 0 is mapped to 1.0 (white); an input value of 2n - 1 is mapped to 0.0 (black).

The Dmin and Dmax parameters for a color component are not required to fall within the range of values allowed for that component. For instance, if an application uses 6-bit numbers as its native image sample format, it can represent those samples in PDF in 8-bit form, setting the two unused high-order bits of each sample to 0. The image dictionary should then specify a Decode array of [0.00000 4.04762], which maps input values from 0 to 63 into the range 0.0 to 1.0 (4.04762 being approximately equal to 255 ÷ 63). If an output value falls outside the range allowed for a component, it is automatically adjusted to the nearest allowed value.

Image Interpolation

When the resolution of a source image is significantly lower than that of the output device, each source sample covers many device pixels. As a result, images can appear jaggy or blocky. These visual artifacts can be reduced by applying an image interpolation algorithm during rendering. Instead of painting all pixels covered by a source sample with the same color, image interpolation attempts to produce a smooth transition between adjacent sample values. Image interpolation is enabled by setting the Interpolate entry in the image dictionary to true. It is disabled by default because it may increase the time required to render the image.


The interpolation algorithm is implementation-dependent and is not specified by PDF. Image interpolation may not always be performed for some classes of images or on some output devices.

Alternate Images

Alternate images (PDF 1.3) provide a straightforward and backward-compatible way to include multiple versions of an image in a PDF file for different purposes. These variant representations of the image may differ, for example, in resolution or in color space. The primary goal is to reduce the need to maintain separate versions of a PDF document for low-resolution on-screen viewing and high-resolution printing.

In PDF 1.3, a base image (that is, the image XObject referred to in a resource dictionary) can contain an Alternates entry. The value of this entry is an array of alternate image dictionaries specifying variant representations of the base image. Each alternate image dictionary contains an image XObject for one variant and specifies its properties. Table 4.41 shows the contents of an alternate image dictionary.

Table 4.41. Entries in an alternate image dictionary
Imagestream(Required) The image XObject for the alternate image.
DefaultForPrintingboolean(Optional) A flag indicating whether this alternate image is the default version to be used for printing. At most one alternate for a given base image may be so designated. If no alternate has this entry set to true, the base image is used for printing.
OCdictionary(Optional; PDF 1.5) An optional content group (see Section 4.10.1, “Optional Content Groups”) or optional content membership dictionary (see “Optional Content Membership Dictionaries” on page 337”) that facilitates the selection of which alternate image to use.

Example 4.29 shows an image with a single alternate. The base image is a grayscale image, and the alternate is a high-resolution RGB image stored on a Web server.

Example 4.29.

10 0 obj                     % Image XObject
   <<  /Type/XObject
       /Alternates15 0 R
… Image data …

15 0obj                      % Alternate images array
  [ <</Image16 0 R

16 0 obj                      % Alternate image
   << /Type/XObject
      /Length0                % This is an external stream
          /F(http ://www.myserver.mycorp.com/images/exttest.jpg)


In PDF 1.5, optional content (see Section 4.10) can be used to facilitate selection between alternate images. If an image XObject contains both an Alternates entry and an OC entry, the choice of which image to use is determined as follows:

If the image's OC entry specifies that the base image is visible, that image is displayed.

Otherwise, the list of alternates specified by the Alternates entry is examined, and the first alternate containing an OC entry specifying that its content should be visible is shown. (Alternate images that have no OC entry are not shown.)

4.8.5. Masked Images

Ordinarily, in the opaque imaging model, images mark all areas they occupy on the page as if with opaque paint. All portions of the image, whether black, white, gray, or color, completely obscure any marks that may previously have existed in the same place on the page. In the graphic arts industry and page layout applications, however, it is common to crop or mask out the background of an image and then place the masked image on a different background so that the existing background shows through the masked areas. A number of PDF features are available for achieving such masking effects (see implementation note 53 in Appendix H):

  • The ImageMask entry in the image dictionary, available in all versions of PDF, specifies that the image data is to be used as a stencil mask for painting in the current color.

  • The Mask entry in the image dictionary (PDF 1.3) may specify a separate image XObject to be used as an explicit mask specifying which areas of the image to paint and which to mask out.

  • Alternatively, the Mask entry (PDF 1.3) may specify a range of colors to be masked out wherever they occur within the image. This technique is known as color key masking.


Although the Mask entry is a PDF 1.3 feature, its effects are commonly simulated in earlier versions of PDF by defining a clipping path enclosing only those of an image's samples that are to be painted. However, implementation limits can cause errors if the clipping path is very complex (or if there is more than one clipping path). An alternative way to achieve the effect of an explicit mask in PDF 1.2 is to define the image being clipped as a pattern, make it the current color, and then paint the explicit mask as an image whose ImageMask entry is true. In any case, the PDF 1.3 features allow masked images to be placed on the page regardless of the complexity of the clipping path.

In the transparent imaging model, a fourth type of masking effect, soft masking, is available through the SMask entry (PDF 1.4) or the SMaskInData entry (PDF 1.5) in the image dictionary; see Section 7.5.4, “Specifying Soft Masks,” for further discussion.

Stencil Masking

An image mask (an image XObject whose ImageMask entry is true) is a monochrome image in which each sample is specified by a single bit. However, instead of being painted in opaque black and white, the image mask is treated as a stencil mask that is partly opaque and partly transparent. Sample values in the image do not represent black and white pixels; rather, they designate places on the page that should either be marked with the current color or masked out (not marked at all). Areas that are masked out retain their former contents. The effect is like applying paint in the current color through a cut-out stencil, which lets the paint reach the page in some places and masks it out in others.

An image mask differs from an ordinary image in the following significant ways:

  • The image dictionary does not contain a ColorSpace entry because sample values represent masking properties (1 bit per sample) rather than colors.

  • The value of the BitsPerComponent entry must be 1.

  • The Decode entry determines how the source samples are to be interpreted. If the Decode array is [0 1] (the default for an image mask), a sample value of 0 marks the page with the current color, and a 1 leaves the previous contents unchanged. If the Decode array is [1 0], these meanings are reversed.

One of the most important uses of stencil masking is for painting character glyphs represented as bitmaps. Using such a glyph as a stencil mask transfers only its “black” bits to the page, leaving the “white” bits (which are really just background) unchanged. For reasons discussed in Section 5.5.4, “Type 3 Fonts,” an image mask, rather than an image, should almost always be used to paint glyph bitmaps.


If image interpolation (see “Image Interpolation” on page 318) is requested during stencil masking, the effect is to smooth the edges of the mask, not to interpolate the painted color values. This effect can minimize the jaggy appearance of a low-resolution stencil mask.

Explicit Masking

In PDF 1.3, the Mask entry in an image dictionary may be an image mask, as described above under “Stencil Masking,” which serves as an explicit mask for the primary (base) image. The base image and the image mask need not have the same resolution (Width and Height values), but since all images are defined on the unit square in user space, their boundaries on the page will coincide; that is, they will overlay each other. The image mask indicates which places on the page are to be painted and which are to be masked out (left unchanged). Unmasked areas are painted with the corresponding portions of the base image; masked areas are not.

Color Key Masking

In PDF 1.3, the Mask entry in an image dictionary may alternatively be an array specifying a range of colors to be masked out. Samples in the image that fall within this range are not painted, allowing the existing background to show through. The effect is similar to that of the video technique known as chroma-key.

For color key masking, the value of the Mask entry is an array of 2 × n integers, [min1 max1minn maxn], where n is the number of color components in the image's color space. Each integer must be in the range 0 to 2BitsPerComponent - 1, representing color values before decoding with the Decode array. An image sample is masked (not painted) if all of its color components before decoding, c1cn, fall within the specified ranges (that is, if minicimaxi for all 1 ≤ in).


When color key masking is specified, the use of a DCTDecode filter for the stream is not recommended. DCTDecode is a lossy filter, meaning that the output is only an approximation of the original input data. Therefore, the use of this filter can lead to slight changes in the color values of image samples, possibly causing samples that were intended to be masked to be unexpectedly painted instead, in colors slightly different from the mask color.

4.8.6. Inline Images

As an alternative to the image XObjects described in Section 4.8.4, “Image Dictionaries,” a sampled image may be specified in the form of an inline image. This type of image is defined directly within the content stream in which it will be painted rather than as a separate object. Because the inline format gives the application less flexibility in managing the image data, it should be used only for small images (4 KB or less).

An inline image object is delimited in the content stream by the operators BI (begin image), ID (image data), and EI (end image). These operators are summarized in Table 4.42. BI and ID bracket a series of key-value pairs specifying the characteristics of the image, such as its dimensions and color space; the image data follows between the ID and EI operators. The format is thus analogous to that of a stream object such as an image XObject:


… Key-value pairs …


… Image data …


Table 4.42. Inline image operators
BIBegin an inline image object.
IDBegin the image data for an inline image object.
EIEnd an inline image object.

Inline image objects may not be nested; that is, two BI operators may not appear without an intervening EI to close the first object. Similarly, an ID operator may appear only between a BI and its balancing EI. Unless the image uses ASCIIHexDecode or ASCII85Decode as one of its filters, the ID operator should be followed by a single white-space character, and the next character is interpreted as the first byte of image data.

The key-value pairs appearing between the BI and ID operators are analogous to those in the dictionary portion of an image XObject (though the syntax is different). Table 4.43 shows the entries that are valid for an inline image, all of which have the same meanings as in a stream dictionary (Table 3.4 on page 38) or an image dictionary (Table 4.39). Entries other than those listed are ignored; in particular, the TYPE, Subtype, and Length entries normally found in a stream or image dictionary are unnecessary. For convenience, the abbreviations shown in the table may be used in place of the fully spelled-out keys. Table 4.39 shows additional abbreviations that can be used for the names of color spaces and filters. Note, however, that these abbreviations are valid only in inline images; they may not be used in image XObjects. Also note that JBIG2Decode and JPXDecode are not listed in Table 4.44 because those filters can be applied only to image XObjects.

Table 4.43. Entries in an inline image object
Intent (PDF 1.1)No abbreviation
InterpolateI (uppercase I)

Table 4.44. Additional abbreviations in an inline image object
IndexedI (uppercase I)
FlateDecode (PDF 1.2)Fl (uppercase F, lowercase L)

The color space specified by the ColorSpace (or CS) entry may be any of the standard device color spaces (DeviceGray, DeviceRGB, or DeviceCMYK). It may not be a CIE-based color space or a special color space, with the exception of a limited form of Indexed color space whose base color space is a device space and whose color table is specified by a string (see “Indexed Color Spaces” on page 233). Beginning with PDF 1.2, the value of the ColorSpace entry may also be the name of a color space in the ColorSpace subdictionary of the current resource dictionary (see Section 3.7.2, “Resource Dictionaries”). In this case, the name may designate any color space that can be used with an image XObject.


The names DeviceGray, DeviceRGB, and DeviceCMYK (as well as their abbreviations G, RGB, and CMYK) always identify the corresponding color spaces directly; they never refer to resources in the ColorSpace subdictionary.

The image data in an inline image may be encoded by using any of the standard PDF filters. The bytes between the ID and EI operators are treated much the same as a stream object's data (see Section 3.2.7, “Stream Objects”), even though they do not follow the standard stream syntax. (This is an exception to the usual rule that the data in a content stream is interpreted according to the standard PDF syntax for objects.)

Example 4.30 shows an inline image 17 samples wide by 17 high with 8 bits per component in the DeviceRGB color space. The image has been encoded using LZW and ASCII base-85 encoding. The cm operator is used to scale it to a width and height of 17 units in user space and position it at coordinates (298, 388). The q and q operators encapsulate the cm operation to limit its effect to resizing the image.

Example 4.30.

q                                         % Save graphics state
17 0 0 17 298 388 cm                      % Scale and translate coordinate space
BI                                        % Begin inline image object
   /W 17                                  % Width in samples
   /H 17                                  % Height in samples
   /CS /RGB                               % Color space
   /BPC 8                                 % Bits per component
   /F [/A85/LZW]                          % Filters
ID                                        % Begin image data
... Omitted data ...
EI                                       % End inline image object
Q                                        % Restore graphics state


  • Creative Edge
  • Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint