[Openicc] CC Profiles In X Specification and dispwin

[Hal V. Engel]

On Tuesday 15 January 2008 09:28:06 edmund ronald wrote:
> I had a hard look at Gutenprint some time ago. I am a color consultant
> with the experience and the equipment needed to create profiles. Let
> me be blunt here, Robert knows my position on this:
>
> 0. The print quality from Gutenprint is roughly equivalent to that
> from the native manufacturer drivers, and thus well worth profiling.
> Minor issues that remain need more users to report so that bugfixes
> would occur.
>
> 1. The parameters required to put Gutenprint into a state where it can
> be decently profiled for a given paper are not easy to fathom. I got
> fed up with the strangely named options and suggested that some decent
> starting points in the form of loadable/savable configuration settings
> be provided. The community responded to this by saying that I could
> just read the code to figure out which settings to use. I did read the
> code, but it wasn't illuminating. Of course I know that all of you
> Linux guys out there will answer that this just demonstrates that I
> have an IQ of 90, my PhD in comp sci notwithstanding.

Of course someone can always dig into the code to figure out what things are 
doing but that should never be necessary at least for end users and for the 
most part for subject matter experts.  The connection that is missing here is 
some way for a subject matter expert like yourself to feedback specific 
enough information to the OSS project so that they can make the changes in 
the UI that are needed.   Since you don't know what some control "X" does it 
is difficult for you to say to Robert that control would be more usable if it 
were labeled a certain way and functioned a certain way.

>
> 2. Configuration management is a nightmare on all print chains and
> particularly so for an open system. Any change somewhere in the
> libraries can impact the usefulness of the profiles.
>
> My take on the state of print color management using open-source
> drivers is that loadable/savable configuration files for print
> settings (ink density, dither method etc) are the first step to
> getting to a system that can be reliably used by third parties. 

The GIMP frontend to the driver is much more configurable than the default 
GutenPrint front end.  For example it has persistant named configurations and 
gives users access to almost everything that a user could configure for these 
drivers.  On the other hand some the controls are not very accessable from an 
end user perspective and some of them do not allow for the kind of fine 
grained adjustments that are really needed (the curves control is an 
example).  Another problem is that it is currently not setup to allow for 
system wide management of the printers configuration (IE. it has separate 
configurations for each application).  If the GIMP GutenPrint frontend were 
redesigned to be a system level utility it would be a good starting place for 
solving this issue.

> And I 
> would recommend a creation of a Virtual RIP that would be centrally
> maintained with "certified" tested versions of the drivers, even if
> such would become updated. Judging from the problems already
> encountered by the Apple Mac community where OS changes impacted color
> management, I don't think that color stability and open-source
> multiple dependencies can be reconciled.
>
> Native driver suppliers have the advantage of non-regression test
> suites, automatic measuring instrumentation, and a strong financial
> incentive preventing them from tinkering with their drivers and
> causing them to deviate from their published profiled state.
>
> Edmund
>
> Robert wrote:
> > That's also what I'd rather be doing.  In this particular case, I'd
> > rather add the necessary features to Gutenprint to allow people who do
> > have the hardware and expertise in this area to create and publish
> > these profiles, and for users to use them easily.
> >
> > --
> > Robert Krawitz                                     <rlk at alum.mit.edu>