[Openicc] Color Management for Ubuntu

[edmund ronald]

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
>>
>