I’ve been hearing recently about 16-bit printing and how, apparently, you can’t do it on Windows (for example on this thread). 16-bit (and more, but we’ll get to that in a moment) print support was added in Windows Vista and Windows Server 2008. At the same time we made that support available down level to Windows XP and Windows Server 2003 (down level is Microsoft-speak for previous versions of the platform).
This means that if you’re using supporting applications and devices on a version of Windows released in the last seven years, you can benefit from what’s generally called ‘16-bit printing’ . As some people like to say, that’s “goodness”.
That’s the high level description of the capabilities, but underneath lies a whole world of complexity. Since you’re here & reading this then it’s likely that you’re interested in that complexity so, with that in mind, now might be a good time to grab a mug of coffee/cup of tea/glass of water before we dive down into some interesting detail…
What is ‘16-bit printing’?
First, let’s define some terminology. I used the term 16-bit above because that’s how people typically talk about this stuff, but from the Windows perspective what we’re really talking about is extended color print support. For color representation in Windows there’s a number of concepts to consider:
- color precision: the precision at which color information is stored. All other things being equal, higher precision means smoother reproduction of colors. Typically color precision is expressed in bits per pixel, or bits per color component, and you’ll also hear it referred to as bit-depth.
- color space: the range of colors that a system can reproduce, bounded by a color gamut that defines the limits of the color space. Larger color gamuts are typically better (more of the visible range of colors can be stored or reproduced) but a larger color space will stretch the precision that you can represent colors over a larger area causing banding artifacts. This means that you’ll often want/need to increase precision as you the color gamut increases.
- dynamic range: the range of original scene luminance that can be recorded, or the range of reproduced scene luminance that can be displayed or printed. All other things being equal, higher dynamic range (a bigger range from black to white) is better.
Prior to the new print path (the XPS Print Path) introduced in Windows Vista, color printing support through the operating system was limited in two ways:
- The precision at which color content could be represented was limited to 8-bits per color channel, for RGB this means 24-bits per pixel (bpp).
- The operating system had no mechanism to enable components to communicate the color space used when defining colors. An implicit assumption in the print path was that all color content was in the sRGB color space. This made support of other color spaces, spaces that might be more appropriate for the device being used to print, very complicated and error prone. In general this limited the color gamut to that bounded by the sRGB primaries [1], or resulted in vendors shipping specialized plug-ins to bypass the print path.
The XPS Print Path extended the support for color content in several significant areas:
- The precision at which color content can be represented was significantly increased. For example image data can be represented in pixel formats with precision as high as 32-bits per color channel (i.e. 96bpp for RGB or 128bpp for RGB with alpha).
- Color content can be represented in integer, fixed and floating point representations.
- Color content can be represented in any color space. The limitation to an implicit-RGB has been removed, the new path supports sRGB, scRGB, and profiled RGB, CMYK, n-color and named color spaces.
- All color content is well known. This means that the color space for all color content is fully described (device independent), either because it is a standard color space like sRGB or scRGB, or because it is profiled. This means there are no assumptions or ambiguities regarding the color spaces used by content.
- The inclusion print ticket information using the Print Schema Specification provides a robust mechanism for communicating color configuration information between components in the print path, including which components are responsible for implementing color management.
Two other key technologies related to high quality color printing were introduced in Windows Vista:
- WCS (Windows Color System): provides a complete color management engine that applications and drivers can use to convert color content between different color spaces
- WIC (Windows Imaging Component): provides an extensible image codec framework that applications and drivers can use to access image content while preserving color information
The combination of these capabilities ensures that the new XPS Print Path in Windows supports completely the requirements for high quality color printing, including color printing commonly referred to as ‘16-bit’.
What other pieces are needed?
In the section above we drilled into the platform capabilities provided by the XPS Print Path. But platforms are platforms and not complete solutions. So the obvious question to ask is what other components are involved in ensuring that when a user hits “CTRL-P”, application high quality color data gets to high quality color marks on media. Unfortunately you don’t automatically benefit just because the print path now supports extended color.
Because I’m a bear of very small brain and find pictures=better, here’s a (very) high level diagram of the major pieces:
- Content: this is provided by the end user, whether it’s a rich document, some complex graphics or Camera RAW image data. Importantly, the content needs to include extended color information, if not then you’re back to garbage in garbage out, as someone once said.
- Applications: they application that you’re using must do the right thing:
- support the extended color information in the content – WIC can help here for images
- color manage as appropriate, both for the content, the display and the device, otherwise print may not be as the user expected – WCS can help here
- make sure that the extended content is not lost when the application prints – use the XPS Print Path
- Print Sub-system: this is the XPS Print Path and is supplied as part of Windows (for Windows Vista or later) or when it is installed (for Windows XP & Server 2003), for example by an XPS printer driver or the .Net Framework.
- Platform Components: WCS, WIC etc. these provide services that can be used by applications and drivers to reduce the amount of work required to support extended color and extended color printing.
- Print Driver: to benefit from the enhanced features in the XPS Print Path the printer driver needs to support XPS.
- Device: finally, all of the above only makes sense when the device generate output that can benefit from the extended content, so look out for those that can :-). However, that said, an important thing to remember is that anything upstream from the device typically can’t make valid assumptions about the device, either because that level of device capabilities is opaque to the system, or because the final destination can change late in the workflow (late-binding printing). Therefore a good design philosophy, and one adopted by the XPS Print Path, is to maintain extended color information for a long as possible. We leave it to the component that really knows to make the decision to downgrade the information
A sample implementation
Looking to try this out? We’ll here’s one setup to experiment with on Windows Vista:
Have fun!
Resources
Some Additional Resources on Microsoft WHDC
Footnotes
[1] Although remember that as gamuts are 3D volumes, 2D representations can give a misleading impression.
