[Openicc] Thoughts IEEE PWG

[Paul Tykodi]

Greetings from the PWG,

I have been following the recent color management discussions on this list
and I brought up the topic at the latest PWG Steering Committee meeting held
last Thursday May 5th, 2011. The initial feedback I received was as follows:

PWG has only recently had to consider how to describe ICC Profiles within a
workflow. The document that explicitly mentions them is the current working
draft of the IPP: Job and Printer Extensions - Set 3 specification:
ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippjobprinterext3v10-20110330.pdf

All of the color information contained within the document is probably
somewhat relevant to the discussions currently taking place here on the
OpenICC list, however the particular section to review is titled 5.5.16
printer-icc-profiles (1setOf collection).

Generally PWG best practices advocate keeping the user intent separate from
the actual document or data stream that contains the information to be
processed or rendered. At this time, the place where I believe the PWG
specifications could turn out to be helpful in supporting work on color
management is with our core semantic model, which is maintained by the MFD
Working Group. The Semantic Model describes an abstracted view of the
different functions performed by either a multi-function device or
single-function device using standardized terms. The benefit to the
standardization of the terms is that both the senders and the receivers
within a workflow can declare their intents with a minimum of confusion.

As an open standards body, the PWG welcomes comments and suggestions. Please
feel free to contact us directly or participate in PWG working group mailing
lists should you want to provide input on how best to describe ICC Profile
usage within PWG specifications.

Thanks for your interest in our work.

Best Regards,

/Paul
--
Paul Tykodi
Principal Consultant 
Tykodi Consulting Services LLC

Secretary - IEEE-ISTO Printer Working Group

Co-Chair - IEEE-ISTO PWG IPP Working Group

E-mail:	 ptykodi at tykodi.com  
tel: 	(603) 343-1820
mobile:	(603) 866-0713

>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.
>
>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.
>
>The best way IEEE PWG could do to avoid color management problems, would be
a clear statement, that the client should render all color objects to sRGB,
before sending it to an IEEE PWG conforming printing service.
>
>I think OpenICC is community, where it is mandatory, that OpenICC
conforming workflows should support both a sRGB appoach with simple UI and
complex ICCbased workflow for color enthusiast and color professionals with
an >UI necessary for dealing with complex ICC workflows.
>
>So i don?t see where IEEE PWG could make a positive impact for OpenICC
topics.
>
>best regards
>Jan-Peter
>
>
>Am 09.05.11 06:15, schrieb Chris Murphy:
>>
>>
>> On May 8, 2011, at 4:42 PM, James Cloos wrote:
>>
>>> Is anyone here active in the IEEE?s PWG?
>>>
>>> Among their other working groups, they are currently working on a 
>>> specification for ?cloud printing??.  The two interesting outcomes 
>>> should be a strong takeup by the printer manufacturers of IPP over 
>>> USB and the PWGRaster? format.  That combination should have a 
>>> /significant/ positive impact on our needs.
>>>
>>> It is very unlikely that there will be any significant use of the CPD 
>>> except for legacy apps (which currently use lpr(1) or lp(1)) and as 
>>> an example dialog the authors of frameworks like GTK and qt might use 
>>> when designing their own print dialogs.  Ie, a separate application 
>>> will not fly for most apps authors.
>>>
>>> As such, we should not rely on or wait for the CPD.  Most of the use 
>>> of the initialism CPD instead should specify ?print dialog?.
>>>
>>> (Which is not to suggest that the CPD should be abandoned or 
>>> anything; it should be completed.  But we must be realistic about its 
>>> future.)
>>>
>>> 1] Please excuse the use of the marketing gobbledygook ?cloud?.  Bleh.
>>>
>>> 2] A proper subset of CUPSRaster.
>> I agree with this as well as Richard's concerns about over dependency on
the CPD. We need to be thinking of how to enable ICC in all methods,
including CPD, but not just CPD. I have big concerns with a major backtrack
with >>color management when it comes to cloud and mobile printing right
now. It's fine that for 95% of the market it will (likely) be sRGB based,
but I still think we need to wedge ourselves in assertively to get better
results than this >>for more discerning amateurs and professionals.
>>
>> Chris Murphy