PDF Transparency and Color

Transparency in the PDF imaging model was introduced in version 1.4 of the PDF specification, which was released in 2001. This non-opaque imaging model introduced significant complexity into the PDF specification. One interesting feature of PDF transparency mathematics is that the result of blending can be dependent upon the color space into which the colors are drawn and blended. The PDF graphic state defines a component called a blending mode that affects how colors are blended. Certain blend modes result in colors that are dependent upon the color space in which the blending is performed. For this reason, it is necessary for the group into which colors are being blended to have a defined color space. This ensures consistent rendering across different rendering solutions.

Consider the simple example that assumes an 8-bit mapping between RGB and CMYK given by:

C = 255 – R

M = 255 – G

Y = 255 – B

K = 0

Set the blend mode to the difference type, which for a given backdrop and source color, is defined by:

This operation effectively subtracts the smaller valued color from the larger valued color.

When blending colors, the resultant color is given by the operation:

where

are the alpha transparency values for the source, backdrop, and resultant color. The resultant alpha value is computed using:

where the alpha values are scaled between zero and one.

Consider now a simple case where the alpha value for the source and backdrop are both a value of 1.0. In this case, the resultant alpha value is 1.0, and the resultant color is given completely by the blending operation B.

Continuing with the example, assume blending is occurring in an RGB color space: let the red source color be given by a value of 64 and the red backdrop color by a value of 255. The resultant red component is given by |255 – 64|=191. If instead of blending in RGB, the blending color space is CMYK, the cyan component, which for this case is inversely related to the red component, is of interest for comparison. The cyan source color is 255-64=191; the cyan backdrop color is 255-255=0. The blending operation in CMYK color space is given by |0-191|=191.

Now convert this resultant cyan color to red giving a red value of 255-191=64. Note that a red value of 64 is very different from a red value of 191. Clearly the color space in which the blending occurred had a large impact, as the value is different by 50% of the full color range.

Transparency groups can be nested within one another and can be defined as being isolated or non-isolated. For non-isolated groups, new colors drawn into the current group interact directly with the backdrop colors that are defined by the colors in the parent group. For this interaction to be successful, the non-isolated group color space must be the same as its parent group. For this reason, non-isolated groups cannot specify a color space. They simply inherit the color space of their parent group. Isolated groups on the other hand do not interact directly with the backdrop colors as objects are drawn into the group. The interaction only occurs when the group drawing is completed. After completion, the group is color-converted to the parent color space, if needed, and then blended with the parent group according to the transparency settings. For this reason, isolated groups can specify their own color space. If they do not specify a color space, like the non-isolated group, they inherit the color space of their parent group. This all seems sensible, but there is one situation that is often confusing with the rendering of certain files: the problem involving the parent of all the transparency groups.

In a PDF file, a page is an isolated group if the page contains transparency. There are exceptions to this. For example, if the “page” is being used as a graphics object by an application such as, Illustrator or InDesign, and is interacting with other objects in the artwork. However, to reduce complexity, ignore that case and assume rendering occurs to a blank output medium. This group for the entire page is well referred to as the page group. However, the PDF specification falls short with respect to defining the color space of the page group. The PDF specification states that unless otherwise specified, the page group’s color space is inherited from the native color space of the output device. This statement implies that the transparency blending operations in this parent group and any groups that inherit the color space from the parent will be dependent upon whether rendering is going to an RGB device or a CMYK device (or a gray device). For files using certain blending color modes, such behavior can result in significant color differences depending upon if the target device is RGB or CMYK based as was shown above. This dependency often results in complaints that the printed CMYK output looks nothing like the RGB image observed on a display. It should be noted that the specification does state that it is “preferable” to specify an explicit color space for the page group. Interestingly, in another part of the specification, it is stated that the group color space value “is required in the group attributes dictionary for any transparency group XObject that has no parent group or page from which to inherit.” The page group would be one such group, which would imply the need for it to be specified. Unfortunately, there are many files that we encounter that do not specify the page group color space and have different color renderings depending upon the output device.

In Ghostscript, this issue can be dealt with by specifying an ICC profile to use for the blending color space. The option is specified using -sBlendColorProfile=“icc_profile_file.icc” on the command line (where icc_profile_file.icc is replaced with your ICC profile file). This option forces the page group to use the specified blending color space, avoiding any device color space dependency.