[Openicc] colord 0.1.0 released!

Wed Jan 19 19:06:09 PST 2011

Ann,

With all due respect, how come we spend so much time debating the number of
angels that can fit on a metatag, and then we have a Mac print system which
is for all practical purposes unusable for profiled printing? Something has
gone seriously wrong here.

Edmund

On Thu, Jan 20, 2011 at 2:57 AM, Ann L McCarthy <almccart at lexmark.com>wrote:

>
> 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>
> 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/20110120/339b7a2e/attachment-0001.htm>