[Openicc] Color Management for Ubuntu

[Ann McCarthy]

Edmund,

In general the sRGB capture to sRGB print image paths across the industry
do work reasonably well because printers that take RGB input are by default
tuned to do a good job with sRGB inputs. This default scenario uses the ICC
v2 approach which assumes the gamut mapping and preference rendering will be
done in the output side transform.

Best regards,
Ann L McCarthy
Imaging Systems R&D
Lexmark International, Inc.



On Tue, May 3, 2011 at 7:17 PM, edmund ronald <edmundronald at gmail.com>wrote:

> Ann,
>
>
> On 5/4/11, Ann McCarthy <almccart at lexmark.com> wrote:
> > It would help quite a bit for the discussion if you could come down off
> of
> > your high horse Edmund.
> > There was no hint of 'we know best' -- only a proposed approach.
> >
> > Your statement that you are "working in devicespace, and do not have a
> > profile in place on the system for the device being tested." is curious.
>
>  I think you understand very well that I may have one or several
> profile(s) available in my filesystem for conversion without one being
> having one placed in the printpath. This is typical of what happens
> when printing intending to print on the same sheet composite files
> assembled using multiple profiles.
>
> >
> > Please explain how you can be "working in device space" in which I gather
> > you are viewing some kind of print representation on a display - yet you
> do
> > not have a profile for the print system which would be necessary for
> > rendering the print space content to a display? Perhaps if you described
> > more of your workflow ...
>
> As above.
>
> >
> > I am not surprised that you have direct experience with vendors who
> > expressly intend to make color management and profile use hard. My
> intention
> > is that color management should be clear and simple, as complicated as
> > necessary and not one stitch more. In order to get there, users such as
> > yourself have to be willing to describe their abstracted workflow
> > requirements, not mired in the muck of workarounds they have previously
> been
> > forced into by current system limitations.
> >
> Seamless workflow certainly interests you,  I believe you fully
> represent it as you founded an ICC WG which would like to achieve
> this.
>
> Maybe you could explain to us on list how come PictBridge works, as it
> seems to produce very good straight-from-camera images?
>
> Edmund
>
> > Best regards,
> > Ann L McCarthy
> > Imaging Systems R&D
> > Lexmark International, Inc.
> >
> >
> >
> > On Tue, May 3, 2011 at 5:17 PM, edmund ronald <edmundronald at gmail.com
> >wrote:
> >
> >> On Tue, May 3, 2011 at 11:00 PM, Ann McCarthy <almccart at lexmark.com>
> >> wrote:
> >> > Thanks for the good example Edmund.
> >> >
> >> > So the scenario you are describing is 'printer profile already applied
> -
> >> > don't do it again'.
> >> > In your experience, have you found sufficient workflow hooks are in
> >> > place
> >> to
> >> > handle avoiding applying the printer profile in the box when printing
> to
> >> a
> >> > printer that has an in-box RIP/CMM?  Or perhaps you have not tried it
> >> with
> >> > that kind of system?
> >> >
> >> > Anyway -- this scenario should be handled under the basic rule of CM
> >> which
> >> > is: "if the source profile of the content matches the profile of the
> >> > destination THEN do not re-apply the destination profile." In my view
> an
> >> > intelligent CMM should always apply that rule. So that is why I did
> not
> >> list
> >> > it as a case of 'turn color management off'.
> >>
> >> Ann,
> >>
> >> Not so. At the time of assembling a composite of profile tests, I am
> >> working in devicespace, and do not have a profile in place on the
> >> system for the device being tested.
> >>
> >> I am saddened by the fact that you are falling in the Apple trap of
> >> "We know best". If I want to bypass the whole profiling mess, I want
> >> to bypass it, and I probably know why, and once I say so I would like
> >> to decisively bypass any second-guessing by the CMS or CMM, however
> >> smart or brilliant the intergalactic CMM spaceship may be feeling on
> >> that particular day :).
> >>
> >> And no, I am not a user of RIPs. But I used to be vendor-qualified by
> >> a RIP manufacturer, and during training it was explained to me that
> >> distributors for large-format production RIPS consider profiling to be
> >> a tool for paper-vendor lockin, and therefore the distributors
> >> explicitly want profiling and profile changing and indeed paper
> >> configuration to be made as difficult as possible for the RIP end-user
> >> (in the contract printing context.)
> >>
> >> Edmund
> >> _______________________________________________
> >> openicc mailing list
> >> openicc at lists.freedesktop.org
> >> http://lists.freedesktop.org/mailman/listinfo/openicc
> >>
> >
> _______________________________________________
> openicc mailing list
> openicc at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openicc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/openicc/attachments/20110504/67477032/attachment.html>