[Openicc] Assigning icc profiles to driver settings

[edmund ronald]

What a delightful idea! The profile can be selected if it is fuzzily
relevant to inking and media settings, inking can be selected if it is
fuzzily relevant to media settings, etc etc.
I'm all for it providing you write the fuzzy matching code :)

Edmund

On Wed, Jan 19, 2011 at 12:45 AM, Ann L McCarthy <almccart at lexmark.com>wrote:

>
> Yes, you would not want to indicate a single specific set of driver setting
> values when the profile could be used for several settings values.
> However, it also could be possible to define the metadata to handle 'this
> profile is used for X range of values of paramter Y, and so on.
> That way the output profile is not modified -- rather it can be selected
> for a particular set of driver setting values by comparing the single
> current value to the range of values the profile covers for each setting.
>
> Best regards,
> Ann McCarthy
> Imaging Systems R&D
> Lexmark International, Inc.
>
>
>
>
>
>  *Graeme Gill <graeme at argyllcms.com>*
> Sent by: openicc-bounces+almccart=lexmark.com at lists.freedesktop.org
>
> 01/18/2011 06:16 PM
>   To
> OpenICC Liste <openicc at lists.freedesktop.org>
>  cc
>   Subject
> Re: [Openicc] Assigning icc profiles to driver settings
>
>
>
>
> Leonard Rosenthol wrote:
> > On Tue, Jan 18, 2011 at 11:26 AM, Jan-Peter Homann<
> > homann at colormanagement.de>  wrote:
> >
> >> 1) PPD colour keywords:
> >> The PPD for a given printer must be able, to describe all color relevant
> >> driver settings with all parameters (incl. low level driver settings if
> >> necessary)
> >> an ICC profile will be assigned to a proper parametrized PPD and the PPD
> >> will completely set up the color options in the printer driver.
> >>
> >>
> > I (and other folks at Adobe) support thsi model.  In fact, we've been
> trying
> > to convince various printer vendors to do this for their PPDs for YEARS.
>
> This is only a good approach for PS based front ends to the printer, where
> a PPD parser is readily available. It is less desirable for other, simpler
> front ends (ie. a direct raster print pipe).
>
> >   However, all of the major vendors are unwilling to do so for various
> > business and/or technical reasons.  So any provided PPDs would need to be
> > MODIFIED versions of the originals...
> >
> >> 2) Driver settings implemented as metadata-information into the
> ICC-profile
> >> Like with the PPD-workflow, all color relebant printer driver settings
> are
> >> stored as metadata into the ICC-profile.
> >
> > Modification of ICC profiles is a BAD IDEA!
> >
> > As noted elsewhere in the thread, it breaks the ID and prevent the use of
> > the profiles in other workflows where comparison of profiles is
> important.
>
> Another disadvantage of this approach is that it makes it hard to
> re-use profiles for similar but slightly different printer set-ups.
>
> One of the practical issues is that there is a combinatorial
> explosion of printer settings, so it's impossible to profile
> all possible combinations. One of the advantages of separating
> calibration from profiling is that it's possible to
> mix and match for good (but not perfect) color. This involves
> using profiles for set-ups other than the one they were created for.
>
> For instance, changing the screen pattern or DPI often changes
> the response transfer curve, but it's feasible to calibrate
> for many of these combinations, and then mix it with
> a profile that has been made for that paper & ink combination,
> yielding quite reasonable results.
>
> Graeme Gill.
>
>
> _______________________________________________
> 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/70aef346/attachment.htm>