[Openicc] Print and Monitor Color Pipeline-stepping back further...
Scott Geffert
scottgeffert at gmail.com
Wed Jan 26 20:21:12 PST 2011
To all:
Stepping back in the workflow to capture/editing. It seems to me that for most users today (digital photographers/image editors) the concept of color management begins based on a completely SUBJECTIVE interpretation of raw data based solely on a calibrated display.
In this scenario users routinely push color-lets say red lipstick or skin tones to very strange places. Yet on the other hand, nearly all color management concepts are related to very specific OBJECTIVE display and printer profiles and very strict "by the numbers" Pass/Fail tolerances.
The almost complete absence of Input profiling today signals to me that printers using color management are doomed to fail due to trying to manage subjective chaos.
In the cultural heritage community it has been well-documented that objective ICC profiled validated captures result in more precision and accuracy than images that have been distorted by subjective editing. ICC has always been the based upon the relationship between INPUT and OUTPUT. How can we manage any output process if input is 100% subjective?
My point is that in the absence of meaningful numeric readouts, and some form of input calibration and verification we are throwing away the most important success factor in the ICC workflow. Basically Garbage in=Garbage out. Users are always free to edit and apply creativity, but right now there are literally no solid foundations in place (other than proprietary manufacturer presets) to base decisions upon. People are literally locked out of ever controlling their capture workflow and are held hostage by proprietary highly incompatible software tools.
The ICC workflow needs to flow from a well-defined source image to ANY media. Most users from consumer iphone users to pro photographers are flipping between still and video, and designers are delivering content to print, on-demand, web, cell phones tablets and TVs. Poorly defined source images translate poorly across any media. I find that almost all ICC discussions are related to CMYK printing yet this is only one medium. There are very few discussions related to capture (the workflow that feeds the workflow). It would be refreshing to see "pipeline" discussions and flowcharts include ALL possible scenarios beginning at capture and including page layout-basically the whole nine yards.
Regarding discussions related to ease of use, ICC is difficult to implement on an enterprise level. Why not allow admin/user level configuration UI so once a color workflow is defined and documented it can be properly managed across an enterprise or desktop admin level. This way the capability is there for very advanced workflow, while users can enjoy the simplicity that many have asked for. Basically show/hide/lockable configuration panes.
Signals that worry me:
•Dropping ICC Controls in the UI
•Dropping Readouts (RGB,HSL,LAB)
•X Rite dropping Input Profiling from the latest profiling tools (X Rite makes a DCSG chart yet now has not tools to use it???)
•Use of standards that are not standards AKA AdobeRGB1998® AdobeRGB is no more standard than BruceRGB, Don RGB, HutchRGB, NikonRGB, Apple RGB,HasselbladRGB, PhaseOneRGB etc. Standards are sRGB,ROMM, and soon to be eciRGBv2. As ICC is an ISO standard protocol I feel that the workflow pipeline should be free from the influence (and branding) of ANY single manufacturer. This is a sign of a truly mature consortium.
I apologize for this lengthy thread, but it appears to me that everyone is working hard to resolve issues here and I feel that If I don't share these thoughts I am part of the problem. I am not against Adobe in any way, in fact they are recently working hard to improve response to customer requests and support for more open standards. If we can all advocate open standards across the entire capture to output chain, users worldwide will benefit and all manufacturers will enjoy increased sales across all markets.
Is this not the goal?
On Jan 26, 2011, at 8:46 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: meta data in test chart (Alastair M. Robinson)
> 2. Edit Spaces Was - Re: Print and monitor Color Pipeline
> (edmund ronald)
> 3. Re: Print and monitor Color Pipeline (Jon Cruz)
> 4. Re: Print and monitor Color Pipeline (Hal V. Engel)
> 5. Re: meta data in test chart (Chris Murphy)
> 6. Re: Edit Spaces Was - Re: Print and monitor Color Pipeline
> (Chris Murphy)
> 7. Re: Print and monitor Color Pipeline (Chris Murphy)
> 8. Re: Print and monitor Color Pipeline (Chris Murphy)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 26 Jan 2011 23:49:35 +0000
> From: "Alastair M. Robinson" <blackfive at fakenhamweb.co.uk>
> Subject: Re: [Openicc] meta data in test chart
> To: Chris Murphy <lists at colorremedies.com>
> Cc: openicc Liste <openicc at lists.freedesktop.org>
> Message-ID: <4D40B30F.70009 at fakenhamweb.co.uk>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hi :)
>
> On 26/01/11 21:05, Chris Murphy wrote:
>
>> I'm referring to the structure of the PDF. PDF, as far as I know, does not have a means of differentiating between your case 2
>> and case 4. Untagged = /deviceRGB and/or /devicecmyk.
>
> Well I have to say I don't know that much about PDF, so please do
> correct any misunderstandings on my part :) But as I understand it
> there are different levels of PDF with increasingly complete support for
> tagging objects with ICC profiles? I see a semantic difference between
> an older PDF with nothing tagged and a newer PDF with objects
> specifically tagged as /device[RGB|CMYK].
>
>> 1. I oppose a user selectable default (assumed) RGB source space for untagged content. I think it's a confusing and useless
>> option. There's statistically zero instance of naturally occurring RGB images that are both untagged but improperly described
>> by sRGB.
>
> So which application would you use, under Linux, today, to print out a
> profiling chart, secure in the knowledge that the image data was
> correctly tagged and would be unmolested by our proposed workflow?
> As for AdobeRGB being superfluous in my proposed option, yes, you're
> probably right there,
>
>> 4. Simple is better. The lesson to learn from Mac OS is that complicated architectures are difficult to create, manage,
>> and get support from other people who need to make various parts like the PPDs and print drivers. If you hang too many
>> complicated dependencies (especially undocumented or poorly
> documented ones) then it's a problem. Avoid this, and avoid the problem.
>
> I'm more worried about inscrutable smarts happening behind the scenes -
> that's what's caused the dissatisfaction on the Mac. Hence my desire
> for an explicit "leave my colours the hell alone" switch, rather than it
> being an automatic user-invisible thing that happens only if an
> application does the Right Thing.
>
>> 5. Applications that strip/ignore embedded ICC profiles and EXIF color space information should be purged from the planet.
>
> Definitely! :)
>
> Sadly, they won't be.
>
>> You don't need GUI choices for this. These apps are not intending to draw in Adobe RGB (1998) so there's no reason to have
>> a GUI option allowing the user to do it.
>
> Fair enough - I only mentioned AdobeRGB as an option since someone else
> had already mentioned it as a possible handoff space - my main intention
> was the sRGB / None distinction. If people think even that's
> superfluous then fair enough, provided we find a robust, scrutable and
> easy-to-trace-and-diagnose-when-things-don't-work-as-planned way of
> passing pretargetted image data to the printer.
>
> All the best
> --
> Alastair M. Robinson
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 27 Jan 2011 00:56:10 +0100
> From: edmund ronald <edmundronald at gmail.com>
> Subject: [Openicc] Edit Spaces Was - Re: Print and monitor Color
> Pipeline
> To: Chris Murphy <lists at colorremedies.com>
> Cc: openicc Liste <openicc at lists.freedesktop.org>
> Message-ID:
> <AANLkTikiTiF-Goy0cQMX=LW2PXSqHmYDofc0CzOV56UE at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> There's not a single time I've had to edit (in RGB) when I haven't
> hated it and found it counterintuitive.
> I used to spend 30 hours for ONE picture in Photoshop, retouching, so
> that made for a lot of time in hell.
>
> What I have heard is that we have to use these kludgy Photoshop slider
> controls and counterintuitive spaces because all the good edit spaces
> and controls got patented by Kodak and others. Any truth to this
> rumor?
>
> Edmund
>
>
>>
>> I think RGB and CMYK are control signals, and should be abstracted away from users. I don't even like photographers dealing with RGB. It's unintuitive, clunky, and in color managed apps there's no correlation between actual RGB values and the ones displayed on screen anyway. So I'd prefer LCH based tools - or better JCH or IPT.
>>
>> And so you can imagine how I feel about CMYK.
>>
>> Chris Murphy
>> _______________________________________________
>> openicc mailing list
>> openicc at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/openicc
>>
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 27 Jan 2011 10:00:49 +1000
> From: Jon Cruz <jon at joncruz.org>
> Subject: Re: [Openicc] Print and monitor Color Pipeline
> To: OpenICC Liste <openicc at lists.freedesktop.org>
> Message-ID: <22FD9DC2-485B-4291-9754-E653328E1018 at joncruz.org>
> Content-Type: text/plain; charset=us-ascii
>
>
> On Jan 27, 2011, at 8:51 AM, Chris Murphy wrote:
>
>> I think RGB and CMYK are control signals, and should be abstracted away from users. I don't even like photographers dealing with RGB. It's unintuitive, clunky, and in color managed apps there's no correlation between actual RGB values and the ones displayed on screen anyway. So I'd prefer LCH based tools - or better JCH or IPT.
>>
>> And so you can imagine how I feel about CMYK.
>
> Although I can agree that far too many people focus on CMYK who should not, there are a lot of cases where more precise control is needed. Screening and droplet control might be a bit beyond what many need, but trapping, knockout, black text, etc. are often best left to the professional graphic designer. It is in trying to make back end systems "too smart" that we often get into trouble.
>
> This also really comes into play when you go to print with spot inks involved. Whether solid spot inks, glossy overlay, etc. those using them often need more control.
>
> And to use the car analogy, although one might not need to know the voltage it takes for cylinders to fire, it *is* quite handy to have a tachometer on their dash. Sure, you could just have a governor on the engine to reduce problems, but seeing the proximity to the redline can be a better and more flexible solution.
>
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 26 Jan 2011 16:47:44 -0800
> From: "Hal V. Engel" <hvengel at gmail.com>
> Subject: Re: [Openicc] Print and monitor Color Pipeline
> To: openicc at lists.freedesktop.org
> Message-ID: <201101261647.44421.hvengel at gmail.com>
> Content-Type: Text/Plain; charset="iso-8859-1"
>
> On Wednesday, January 26, 2011 02:05:56 pm Jan-Peter Homann wrote:
>> Technically different ways for rendering data to the monitor and to the
>> print out does not make sense in my eyes.
>
> There is some technical difference that needs to be kept in mind.
>
> 1. Monitor output is happening in real time and for some applications may be
> happening at high frame rates. In some cases like a photo editor the real
> time requirement has a major impact on usability (IE. you don't want to wait
> too long for a manipulation to the photo to be rendered by the editing
> software). Print output never happens in real time and is never something
> that the user directly interacts with.
>
> 2. The overall software stacks are completely different and there are very few,
> if any, shared components.
>
> 3. For the monitor we have specialized graphics hardware that can be leveraged
> in the rendering process. For example Kai-Uwe has been working on a compiz
> plugin that does CM transforms for monitor display in the GPU for the whole
> desktop (this was a GSoC project two summers ago I believe - I forget the name
> of the student who did the original work). This rendering path (IE. using the
> GPU) is very different from the rendering path that would be used for print
> output.
>
> I could probably come up with some other technical differences but I have an
> appointment and have to run.
>
> Hal
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 26 Jan 2011 18:33:58 -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: <D53C36A5-9B82-458C-A82A-CA19102ADA0C at colorremedies.com>
> Content-Type: text/plain; charset=us-ascii
>
>
>
> On Jan 26, 2011, at 4:49 PM, Alastair M. Robinson wrote:
>>> 1. I oppose a user selectable default (assumed) RGB source space for untagged content. I think it's a confusing and useless
>>> option. There's statistically zero instance of naturally occurring RGB images that are both untagged but improperly described
>>> by sRGB.
>>
>> So which application would you use, under Linux, today, to print out a profiling chart, secure in the knowledge that the image data was correctly tagged and would be unmolested by our proposed workflow?
>
> I don't know, I haven't tried this yet. But at the moment I'm not immediately thinking there's any application that would color manage any image let alone a target for making a profile.
>
> Option A: put in an explicit "All Off" and "ICC Off, Calibration On" option within the print dialog in the same pop-up where a profile would go.
>
> Option B: put this in an advanced panel for an application (or applications) that would be used for printing profile targets.
>
>
>
>> As for AdobeRGB being superfluous in my proposed option, yes, you're probably right there,
>>
>>> 4. Simple is better. The lesson to learn from Mac OS is that complicated architectures are difficult to create, manage,
>>> and get support from other people who need to make various parts like the PPDs and print drivers. If you hang too many
>>> complicated dependencies (especially undocumented or poorly documented ones) then it's a problem. Avoid this, and avoid the problem.
>>
>> I'm more worried about inscrutable smarts happening behind the scenes - that's what's caused the dissatisfaction on the Mac. Hence my desire for an explicit "leave my colours the hell alone" switch, rather than it being an automatic user-invisible thing that happens only if an application does the Right Thing.
>
> OK. I'm not terribly worried because it requires more complexity to implement than I think anyone has time to make happen. It wouldn't accidentally happen.
>
>
>
>>
>>> 5. Applications that strip/ignore embedded ICC profiles and EXIF color space information should be purged from the planet.
>>
>> Definitely! :)
>>
>> Sadly, they won't be.
>
> I understand. And therefore assuming sRGB for their content is fine. Better than how it presently works.
>
>
>
> Chris Murphy
>
> ------------------------------
>
> Message: 6
> Date: Wed, 26 Jan 2011 18:34:38 -0700
> From: Chris Murphy <lists at colorremedies.com>
> Subject: Re: [Openicc] Edit Spaces Was - Re: Print and monitor Color
> Pipeline
> To: openicc Liste <openicc at lists.freedesktop.org>
> Message-ID: <D2E403B5-4839-4670-AD7D-B6BA2F775A73 at colorremedies.com>
> Content-Type: text/plain; charset=us-ascii
>
>
>
> On Jan 26, 2011, at 4:56 PM, edmund ronald wrote:
>
>> There's not a single time I've had to edit (in RGB) when I haven't
>> hated it and found it counterintuitive.
>> I used to spend 30 hours for ONE picture in Photoshop, retouching, so
>> that made for a lot of time in hell.
>>
>> What I have heard is that we have to use these kludgy Photoshop slider
>> controls and counterintuitive spaces because all the good edit spaces
>> and controls got patented by Kodak and others. Any truth to this
>> rumor?
>
> I don't know. Seems b.s. to patent color spaces the CIE defined a long time ago.
>
>
> Chris Murphy
>
> ------------------------------
>
> Message: 7
> Date: Wed, 26 Jan 2011 18:36:08 -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: <62FE18BC-40AF-4382-A1FD-057143C0FBC3 at colorremedies.com>
> Content-Type: text/plain; charset=us-ascii
>
>
>
> On Jan 26, 2011, at 4:23 PM, edmund ronald wrote:
>>
>> 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?
>
> Certainly. Epson has abstracted users away from an enormous number of particulars related to inkjet printing.
>
>
> Chris Murphy
>
> ------------------------------
>
> Message: 8
> Date: Wed, 26 Jan 2011 18:46:04 -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: <CA97CD20-CE68-44A8-81AC-CCBE0BACAD59 at colorremedies.com>
> Content-Type: text/plain; charset=us-ascii
>
> On Jan 26, 2011, at 5:00 PM, Jon Cruz wrote:
>
>>
>> On Jan 27, 2011, at 8:51 AM, Chris Murphy wrote:
>>
>>> I think RGB and CMYK are control signals, and should be abstracted away from users. I don't even like photographers dealing with RGB. It's unintuitive, clunky, and in color managed apps there's no correlation between actual RGB values and the ones displayed on screen anyway. So I'd prefer LCH based tools - or better JCH or IPT.
>>>
>>> And so you can imagine how I feel about CMYK.
>>
>> Although I can agree that far too many people focus on CMYK who should not, there are a lot of cases where more precise control is needed. Screening and droplet control might be a bit beyond what many need, but trapping, knockout, black text, etc. are often best left to the professional graphic designer. It is in trying to make back end systems "too smart" that we often get into trouble.
>
> I understand. Sometimes a pen and paper are easier than firing up a wordprocessor.
>
> But design to print now works on that 80 / 20 rule where it's being designed for 80% of the market. And that 80% do not need to be working with CMYK. They just need to specify "black type" and expect the correct thing to happen on various kinds of output. If you build a PDF that explicitly states black text is 100%K only, you now have a PDF that isn't so transportable to different kinds of printing processes. You haven't actually established the overall intent, which is "the darkest type that doesn't get fuzzy or ill tempered when printed".
>
>
>> This also really comes into play when you go to print with spot inks involved. Whether solid spot inks, glossy overlay, etc. those using them often need more control.
>
> Solid spot is cake. Tinting spot colors, or printing them with other inks and predicting what it will look like is hard. That falls into the 20% part of the market. The vast majority is really predictable CMYK only stuff. Look at what Blurb has done for books.
>
>
>>
>> And to use the car analogy, although one might not need to know the voltage it takes for cylinders to fire, it *is* quite handy to have a tachometer on their dash. Sure, you could just have a governor on the engine to reduce problems, but seeing the proximity to the redline can be a better and more flexible solution.
>
> Ok. But most people, at least 80%, aren't going anywhere near redline. Most people drive automatic transmissions in the U.S. also. If you drive manual transmission, tachometer is nice. Same for flying airplanes, it directly means something about the system. CMYK in most workflows doesn't really mean anything. Especially in portable PDF workflows to unknown destinations, it's really meaningless.
>
> I think most developers, especially for Linux, want to build software most people will use. I think that's more often the 80% of the time rather than the 20% users, who are invariably going to companies like Adobe, Enfocus, Apago, and Global Graphics for a solution.
>
>
>
>
> Chris Murphy
>
> ------------------------------
>
> _______________________________________________
> openicc mailing list
> openicc at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openicc
>
> End of openicc Digest, Vol 58, Issue 50
> ***************************************
>
More information about the openicc
mailing list