[Openicc] Print and Monitor Color Pipeline-stepping back further...Clarification

Wed Jan 26 21:59:53 PST 2011

Just to be clear, when discussing capture profiling I am speaking of commercial controlled workflow situations. I understand the challenges related to scene and output referred approaches, but feel that there needs to be work to better define input in general. Capture and subsequent raw editing has become a proprietary subjective "black hole" that ripples through the entire production chain. If Adobe, Phase One, Hasselblad, and others can create proprietary "pleasing default renditions".  A more universal open framework especially within raw image processors would be a step int he right direction.

On Jan 26, 2011, at 6:23 PM, openicc-request at lists.freedesktop.org wrote:

> Send openicc mailing list submissions to
> 	openicc at lists.freedesktop.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://lists.freedesktop.org/mailman/listinfo/openicc
> or, via email, send a message with subject or body 'help' to
> 	openicc-request at lists.freedesktop.org
> 
> You can reach the person managing the list at
> 	openicc-owner at lists.freedesktop.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of openicc digest..."
> 
> 
> Today's Topics:
> 
>   1. Re: Print and monitor Color Pipeline (Chris Murphy)
>   2. Re: meta data in test chart (Chris Murphy)
>   3. Re: Print and monitor Color Pipeline (Chris Murphy)
>   4. Re: Print and monitor Color Pipeline (Chris Murphy)
>   5. Re: LINUX Graphic Libraries / PDF render with CMYK	support ?
>      (Jon Cruz)
>   6. Re: Print and monitor Color Pipeline (edmund ronald)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Wed, 26 Jan 2011 16:01:19 -0700
> From: Chris Murphy <lists at colorremedies.com>
> Subject: Re: [Openicc] Print and monitor Color Pipeline
> To: openicc Liste <openicc at lists.freedesktop.org>
> Message-ID: <80137F7D-25AA-422B-AADB-6114BDABFBF3 at colorremedies.com>
> Content-Type: text/plain; charset="us-ascii"
> 
> 
> 
> On Jan 26, 2011, at 3:16 PM, Leonard Rosenthol wrote:
>> 
>> You need to watch this, since this is what Quartz does.  And while perfectly valid, many professional printers will go nuts about having text and vectors with ICC profiles assigned.  (just sat through ANOTHER presentation, just this morning, at the Ghent Workgroup where they ranted about this particular issue).
> 
> Speaking of Pleistocene era. The issue here is implementation. The tagging of objects with metadata is a.) not permission to convert; b.) might imply, but does not require, a particular kind of conversion; c.) wrong.
> 
> Because of weak implementations, there's a desire to basically lie about the color space of certain objects. Rather than treating those objects in a fashion commensurate with the output process, and convert them to be compatible to the mechanics of the printing process, the history is to ban tagging such objects rather than improve implementations. Black only text is a unique thing. Tagging it with an ICC profile isn't the problem, it's how that gets interpreted downstream into an action to preserve the L*a*b* values of that black text, rather than treat it as a unique kind of object:
> 
> a.) On a press, black only text needs to stay 100% K only.
> b.) On a billboard inkjet printer, I likely want the blackest four color (rich) black the printer can produce within its ink limit.
> 
> And I'd want those behaviors to occur from the same PDF by default, because that's the most likely usage scenario. The use case where you might want the two blacks to match is imaginary, but I have no issue with a developer who wants to build a switch in software to allow that interpretation from the same PDF by their customers.
> 
>> 
>> 
>> If the OutputIntent of the print stream PDF is not identical with the ICC-profile of the current printer setting. The PDF-rendering and rasterizing should be done firstly to the document colorspace and than to ICC of the printer driver setting.
>> 
>> 
>> Nope!   You should follow the rules for PDF rasterization and color management as defined in ISO 32000.
> 
> Yeah I agree. But we still have this issue where the OI is only honored if the PDF is one of the PDF/X's, and if it's PDF/X then the PDF version is 1.4 or less, and when the PDF version is 1.4 or less, then no profile can be ICC v4.
> 
> 
> Chris Murphy
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.freedesktop.org/archives/openicc/attachments/20110126/2032bf61/attachment.html>
> 
> ------------------------------
> 
> Message: 2
> Date: Wed, 26 Jan 2011 16:03:59 -0700
> From: Chris Murphy <lists at colorremedies.com>
> Subject: Re: [Openicc] meta data in test chart
> To: openicc Liste <openicc at lists.freedesktop.org>
> Message-ID: <A764B296-4C2E-496F-870B-B8B79CCACDAD at colorremedies.com>
> Content-Type: text/plain; charset=us-ascii
> 
> 
> 
> On Jan 26, 2011, at 3:56 PM, edmund ronald wrote:
> 
>> I was told that the EDID info on Macs is usually batch-measured and reliable.
>> The problem is that most Linux graphics users are not on Apple hardware. LOL.
>> 
>> Edmund
> 
> EDID is in the display itself and AFAIK is relatively standardized now. The information is obtainable via DDCI. So EDID is not unique to Apple produced displays.
> 
> I have an NEC MultiSync PA241W here, which has custom measured primaries at the factory. That information is stored in two locations, one for their proprietary software so it can be calibrated/profiled without a consumer measuring device. But also there is information in EDID and Mac OS grabs it, and builds a profile based on it, just like it does any other display I attach to the computer. Happens instantly upon connection, and all color managed applications that do display compensation (including parts of the system itself) automatically use it. This is perhaps the singular shining example of color management implementation on the planet.
> 
> 
> Chris
> 
> ------------------------------
> 
> Message: 3
> Date: Wed, 26 Jan 2011 16:05:45 -0700
> From: Chris Murphy <lists at colorremedies.com>
> Subject: Re: [Openicc] Print and monitor Color Pipeline
> To: openicc Liste <openicc at lists.freedesktop.org>
> Message-ID: <1CABE739-4924-41D7-8984-8B411F1CA679 at colorremedies.com>
> Content-Type: text/plain; charset="us-ascii"
> 
> 
> 
> 
> On Jan 26, 2011, at 4:01 PM, Chris Murphy wrote:
> 
>> 
>> 
>> On Jan 26, 2011, at 3:16 PM, Leonard Rosenthol wrote:
>>> 
>>> You need to watch this, since this is what Quartz does.  And while perfectly valid, many professional printers will go nuts about having text and vectors with ICC profiles assigned.  (just sat through ANOTHER presentation, just this morning, at the Ghent Workgroup where they ranted about this particular issue).
>> 
>> Speaking of Pleistocene era. The issue here is implementation. The tagging of objects with metadata is a.) not permission to convert; b.) might imply, but does not require, a particular kind of conversion; c.) wrong.
> 
> c.) NOT wrong.
> 
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.freedesktop.org/archives/openicc/attachments/20110126/5185c2e6/attachment-0001.htm>
> 
> ------------------------------
> 
> Message: 4
> Date: Wed, 26 Jan 2011 16:10:28 -0700
> From: Chris Murphy <lists at colorremedies.com>
> Subject: Re: [Openicc] Print and monitor Color Pipeline
> To: openicc Liste <openicc at lists.freedesktop.org>
> Message-ID: <FCF3D41B-EC4B-46B0-8801-831AE1718317 at colorremedies.com>
> Content-Type: text/plain; charset=us-ascii
> 
> 
> 
> On Jan 26, 2011, at 3:59 PM, edmund ronald wrote:
> 
>> And after our minute of truth and rationality, we go back to
>> commercial programming and the way the world really works :)
> 
> 
> Yeah mind you I do work with CMYK a lot, even with finer granularity than this by choosing the specific droplet sizes I want for each colorant, the channel ink limits before they are crossover/blending (light ink to standard ink), and of course screening, total ink limits, etc. But once all of that is optimized and setup, in my view, users shouldn't need to interact on the level of control signals. 
> 
> I don't think they should be required to understand the voltages required to get cylinders in their car to fire either, just to drive their car. But I'm sure some people think this is CRAZY TALK.
> 
> 
> Chris
> 
> ------------------------------
> 
> Message: 5
> Date: Thu, 27 Jan 2011 09:21:58 +1000
> From: Jon Cruz <jon at joncruz.org>
> Subject: Re: [Openicc] LINUX Graphic Libraries / PDF render with CMYK
> 	support ?
> To: homann at colormanagement.de
> Cc: OpenICC Liste <openicc at lists.freedesktop.org>
> Message-ID: <BFAF6977-98D5-4191-9D71-3FF4523242C8 at joncruz.org>
> Content-Type: text/plain; charset=iso-8859-1
> 
> 
> On Jan 27, 2011, at 1:34 AM, Jan-Peter Homann wrote:
> 
>> Hello list,
>> 
>> Is it correct, that LINUX graphic libraries like e.g. CAIRO still don?t support CMYK color definitions ?
>> 
>> Is it correct, that currently the one and only opensource (PDF) rendering engine supporting CMYK is GhostScript ?
> 
> 
> 
> We've been using poppler for PDF input, and need to coordinate with them on refining the API for full professional robustness. That has been moving up for attention now.
> 
> We've also been using Cairo for PDF output. Cairo does not have CMYK, but we seem to be on the cusp of good progress there. I'm at linux.conf.au this week and have spent time hashing out things with the Ciaro guys.
> 
> One bottom line, however, is that we don't want to "support CMYK". What we need to do is support full professional printing needs which go from CMYK through CMYK+Spot, CMYKOG, CMYKOG+Spot, etc. That is, one probably needs to look at more than just four-color.
> 
> ------------------------------
> 
> Message: 6
> Date: Thu, 27 Jan 2011 00:23:36 +0100
> From: edmund ronald <edmundronald at gmail.com>
> Subject: Re: [Openicc] Print and monitor Color Pipeline
> To: Chris Murphy <lists at colorremedies.com>
> Cc: openicc Liste <openicc at lists.freedesktop.org>
> Message-ID:
> 	<AANLkTinqerEvgHGZw09adRaW6Y016pYAPkhE6_evcrLv at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
> 
>> 
>> I don't think they should be required to understand the voltages required to get cylinders in their car to fire either, just to drive their car. But I'm sure some people think this is CRAZY TALK.
>> 
> 
> Yes, technology is ephemeral, historically accidental and absurd.
> I used to be a mathematician. Things had a greater shelf life than 5 minutes.
> 
> I didn't "really" know ink limits or crossover curves existed until I
> started working with the Gutenprint crowd - surely that's an
> indication that the current abstractions from that level are
> moderately successful?
> 
> Edmund
> 
> 
> ------------------------------
> 
> _______________________________________________
> openicc mailing list
> openicc at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openicc
> 
> End of openicc Digest, Vol 58, Issue 49
> ***************************************
> 