[Openicc] Thoughts IEEE PWG

[Jan-Peter Homann]

Hello to all,
Reading "wd-ippjobprinterext3v10-20110330.pdf"

seems to be quite strange to me.

The ICC profiles used as example, are typical ICC-profile for exchange 
of documents.
A normal workflow would be, that the profile of the document will 
preserved in the print spool file and the printing infrastructure will 
extract this profile and does a color conversion from the document 
colorspace to the printers colorspace.

To is build a second communication level for exchange of colorspace 
informations between user/client and print service does not make any 
sense for me, if it can be embedded automatically into the print spool file.

Also the rendering instructions in "5.2.2 print-rendering-intent" are 
not practical.
If relative colorimteric is used as default for printing, there should 
always be blackpoint compensation be activated. Otherwise, it may will 
happen that details in dark tones are lost during printing.

By the way, reading the PWG documents, it seems unclear for me, which 
spool formats (PDF, TIFF, JPEG, CUPS Raster and which colorspaces are 
supported.

- Is it always the case, that the print spool format must be a raster 
format ?
- Or can the printing infrastructure inform the client, that also PDF 
could be used ?
- If PDF is supported, which flavours / elements of PDF would be supported ?

If there is one mailinglist to discuss color issues in IEEE PWG 
workflow, please let me know which one would be the one.

Best regards
Jan-Peter






Am 09.05.11 13:09, schrieb 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
>


-- 
----------  Please note the new adress --------------

homann colormanagement --------- fon +49 30 611 075 18
Jan-Peter Homann ------------ mobile +49 171 54 70 358
Cotheniusstr. 3 -------- http://www.colormanagement.de
10407 Berlin -------- mailto:homann at colormanagement.de