[Openicc] Thoughts IEEE PWG

[Michael Sweet]

[Apologies that I'm not replying to the original thread; I only just re-subscribed to the openicc list...]

Jan-Peter Homann wrote:
> Hello list, James and Chris
> Thanks for linking to the IEEE PWG.
> I took a first overlook about the published papers and standard 
> concerning color management, documents file formats and media definitions.
> 
> My first impression, is that the current IEEE PWG focus is on sRGB based 
> only workflows.
> discussed documents formats are e.g. XHTML Print, CUPSRaster and PDF 
> containing only raster files.

That impression, fortunately, is false.

For IPP Everywhere (which is one project of the Printer Working Group), we have a specific goal to define a baseline IPP implementation that supports "driverless" printing from any platform. In support of that goal we have a minimal raster format (PWG Raster, a subset of CUPS Raster), JPEG (since most cameras produce it), and full PDF (which is the only standard format likely to provide full engine speed on high-end laser printers).

PWG Raster includes standard color spaces - sRGB, sGray (a grayscale version of sRGB), and AdobeRGB - as well as device color spaces such as DeviceRGB, DeviceK, DeviceCMYK, and the full set of DeviceN spaces (1 to 15 components). Printers advertise the color spaces and bit depths they support via IPP attributes.

JPEG includes support for standard color spaces (sRGB and AdobeRGB) as well as embedded ICC profiles. I suspect we we require support for sRGB and AdobeRGB and recommend support for embedded ICC profiles.

PDF includes support for standard and arbitrary color spaces, and a printer that supports PDF must also support PDF color spaces and embedded profiles.

It would be accurate to say that we want to support a common standard color space for basic printing, but we also want to support a fully-color-managed workflow including color proofing. Right now the answer for a standard color space is sRGB, although for photo printing we are seeing a lot more AdobeRGB as well these days.

For client-side color management, all of the formats under consideration support pass-through of device color, and the "printer-icc-profiles" attribute in the JPS3 specification supports color proofing and client use of vendor (device) color profiles.

Rendering intent, regardless of profile or format, is handled using the "print-rendering-intent" set of attributes. Right now this is a simple list of values (keywords), but we definitely want to capture any relevant information needed for a color-managed workflow.

> I have seriuosly doubts, that printing infrastructure conforming to IEEE 
> PWG will be able  to proper colormanage blog entries  containing images 
> with different embedded ICC profiles, or to reprint a PDF/X file, which 
> was created first time for offset printing.

A printer that supports PDF will also support embedded profiles, and will do the necessary transforms to the device color space for any standard vendor profiles on the device.

However, if the purpose is to use a custom device profile to print a PDF file, it will (currently) be necessary for the client to do the color transforms and provide a PDF (or raster) document for printing in the correct device color space.

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/openicc/attachments/20110509/2599b9d3/attachment-0001.htm>