[Openicc] colord 0.1.0 released!

[Chris Murphy]

Comment 1:
This is something I've long advocated for both Microsoft and Apple: to the degree that we totally abstract the choosing of the ICC profile itself away from the user, because that really is just another setting, at present. I still find it rather ridiculous that we have to choose "ESP9880_PremiumLuster_2880_PK" and then in another dialog have to choose: a.) the printer model, b.) the media type, c.) the resolution, d.) the inkset, if applicable, all over again.

One idea behind the optional tags in ICC profiles was to allow for such settings to be included in the ICC profile itself, so that upon choosing a profile, driver specific metadata in that profile could be used to autopopulate the driver settings so that the printing conditions for that profile were reproduced. So there's that paradigm.

And another would be for the user to choose driver settings (or a preset containing them), and then for an ICC profile to be chosen automatically based on those settings.

I think depending on ICC profiles containing metadata to do this is completely dead in the water. There is no requirement for the profile builder to populate these tags. There's no support in any package I'm aware of that populates these tags either, you'd have to use something like sampleicc or icctoxml to add the tags. I could be wrong but I think that will go nowhere for the larger ICC market.

So it seems that the ICC profile is just another setting in the driver. But still, in the case of application prematching, if the application could pass to the system that chosen profile, the system could look in its database of presets for that profile and choose a default preset of driver settings that calls for that profile. This avoids end user error and is quite elegant.

Comment 2:
What is "CMS off" isn't always the same for every printer. Many consumer printers are increasingly only accepting/assuming sRGB input, there is no "wider gamut RGB/CMYK" path, let alone DeviceN. So is this CMS off? Well...not really. Can we profile over this behavior? Maybe. I think it's a problem to propose these are all the same thing to users.

Chris Murphy

On Jan 17, 2011, at 6:49 AM, edmund ronald wrote:

> 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 at gmail.com> wrote:
>> On 17 January 2011 02:48, Robert Krawitz <rlk at 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.
>> 
> _______________________________________________
> openicc mailing list
> openicc at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openicc