[Openicc] colord 0.1.0 released!

[Ann L McCarthy]

Chris,

Regarding "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."
The motivation is there for printer vendors who sell printers with many 
profiles for various different settings and paper types. In this case the 
same supplier is providing the profiles, the RIP, the printer, and one or 
more host drivers.  So to make it easier for their users -- to avoid 
choosing all of those redundant settings and encrypted profile names -- 
the metadataTag can be used.

Marti has promised to put the metadataTag in littleCMS -- not sure if it 
is in there yet though.
SampleICC will have support as well.

It is true it will be helpful if one or more of the general profile 
builder software vendors can add support.  However -- to be fair to those 
vendors -- it seems reasonable for them to wait until a set of actual 
metadata content for printers etc has been defined by communities such as 
this.

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






Chris Murphy <lists at colorremedies.com> 
Sent by: openicc-bounces+almccart=lexmark.com at lists.freedesktop.org
01/19/2011 07:08 PM

To
openicc Liste <openicc at lists.freedesktop.org>
cc

Subject
Re: [Openicc] colord 0.1.0 released!






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

_______________________________________________
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/20110119/1cecd6ee/attachment.htm>