Re: [Openicc] colord 0.1.0 released!

[edmund ronald <edmundronald gmail com>]

Hi folks, I'm a color consultant providing some input to Robert  re.
Gutenprint color management.

My feeling is that it is very important not only to be able to turn
all CMS off for a printer, but also to be able to cleanly save and
recall complete print setting configurations - and serialize them. In
other words, if I determine a bunch of settings that I want to use for
printing profiled on BizarreBoardPaper  with an Epson 9880, I want to
be able to cleanly export this, and ship it to someone who needs this
paper/ink/profile knowledge and who may then choose to reprofile or
relinearize on his own machine when he gets it. Profiles are useful
for consumers but pros often do them upstream, however ink settings
are fundamental for consumer and pro alike.

Edmund

On Mon, Jan 17, 2011 at 10:38 AM, Richard Hughes <hughsient gmail com> wrote:
> On 17 January 2011 02:48, Robert Krawitz <rlk alum mit edu> wrote:
>> 1) From the Gutenprint perspective, it's very important to be able to
>>   turn this off selectively (for the purposes of profiling, if
>>   nothing else).  The inability to turn off ColorSync has been a
>>   major thorn in the side of a lot of our Mac users, and is actually
>>   impeding progress in regards creating a color managed workflow with
>>   Gutenprint on that platform.
>
> Yes agreed. gnome-color-manager will have to be able to turn this off
> for profiling too, and I admit there isn't a dedicated method for
> doing this just yet. It's pretty easy to remove all the profiles for a
> device, but then you have to trust the profiler to add them all back
> again after profiling :-)
>
> There'll likely be some sort of inhibit interface for the
> GetProfilesForQualifier method call. Ideas welcome.
>
>> 2) High bit depth capability is essential, at least downstream of
>>   colord.  Both CUPS and Gutenprint can handle 16 bits just fine, but
>>   it's important that the transformation not lose information from
>>   the data provided by the user.
>
> I'm quite keen on having colord stay away from pixel manipulation. I
> think that's much better placed in the driver itself, using something
> like lcms. Colord should concentrate on being a smart storage unit
> that can be queried by CUPS for specific bits of data.
>