[Openicc] ALL YOU NEED IS A PROFILE, THE MYTH. (WAS CC Profiles In X Specification and dispwin)

[Robert Krawitz]

   Date: Sat, 19 Jan 2008 15:35:01 +0100
   From: "edmund ronald" <edmundronald at gmail.com>

    Gutenprint is not perfect, however it's pretty good. I've never met a
   perfect piece of software.
    I would say that there is ample proof by now that if any precisely
   defined functionality *needs* to be added to Gutenprint the developers
   are able to do so.

    Of course, the word *needs* refers to user requests. So I would
   analyze the software according to 3 indices:

   1. -  Reliability: Can Gutenprint be deployed *by its users* in a way
   such that it performs predictably on demand ?
   2. -  Accessibility: Can Gutenprint be conveniently deployed  by a
   significant fraction of its intended userbase ?
   3. -  Features: Does Gutenprint embody the features necessary to
   complete the job required by its intended users ?

   I would say that at the moment 1. is still doubt because there is no
   evidence of non-regression across versions, and no way to be sure of
   the state of the system at a given point in time, but if evidence of
   stability were brought then 1 would be easily assured. 2 desperately
   needs to be worked on. 3 is ok, if one accepts that final renderings
   should be created by domain experts who will be linearizing and
   profiling with instrumentation, and thus final rendering quality is
   not the responsibility of the core programmers.

Actually, in the last release I checked in something to allow saving
MD5 checksums from test runs (using the test pattern generator, not
the CUPS driver).  We're not currently using it for anything, but it
could be used to create a test that would verify predictability from
release to release.

I don't want to make something like this a release requirement,
because we might want to make changes not related to output and having
an absolute no changes policy may be too restrictive.  But we might be
able to use this to at least flag changes.

Even in that case, changes wouldn't necessarily mean that a profile or
linearization would be invalidated.  For example, output changes
related to High Accuracy color correction may be of no interest to
people doing custom linearization or profiling, because they shouldn't
be using that mode.  Likewise, changes to default drop sizes at 360
DPI might not be interesting, and if we expose the drop size and light
ink transitions, retuning these constants may also not be important to
these users.  Changes to auxiliary colors (e. g. on the R1800) would
be, but that's something I hope the CM community addresses at some
point.

I disagree with your assessment of (2), at least as stated.  I believe
that it can be conveniently deployed by a significant fraction of its
intended user base.  The part that isn't convenient is the ability to
save tuning settings in a convenient way for users.  So it's certainly
convenient for many of its users, but there's an interesting group of
users for whom it isn't currently convenient.

I very much like the idea of being able to hand off final rendering
quality to others.  I think that many users won't worry about this, so
having good (if not perfect) default tunings is important, but so is a
way of letting people who want to perfect the tunings do so.

Are we in accord here?

   So, I think that work on (2) accessibility will bring in domain-aware
   users who will then indicate if necessary which features are necessary
   and prioritize them for you. Achieving (1) reliability has never been
   a problem in the open-source community although it appears to be
   difficult in Redmond. As for point (3) features, having come so far,
   it seems probable that the developers will be able to continue
   matching the essential needs of print-makers, provided they keep
   focused on core functionality. Writing parameter files for various
   inks and papers is not part of the core job of programmers and should
   be handed off as quickly as possible.

I'm looking to find a way that won't involve rewriting 10,000 lines of
code (roughly the amount of data encoded in C files in the core).
Rewriting this as XML will not reduce the line count, and it would be
a huge job with uncertain return (uncertain in the sense of "will this
really be convenient for people" and "is there an easier way to
achieve what's required").

As far as (3) goes, I think we will need to add drop size and light
ink tone adjustments to the list of exported parameters.  Beyond that,
I guess we'll see.

One idea I had in mind was a way to be able to batch up settings and
apply them to a PPD file.  Before we go there, I'd rather have a
prototype that's more convenient, like PhotoPrint (Alastair, sorry for
volunteering you again :-) ).  While that's not a fully general
solution, it might help us figure out how to move forward.

   > OK, this is actually helpful here -- the key being that you believe
   > the core driver does have the necessary facilities, and we have to
   > figure out how to expose them appropriately.  Thanks.
   >
   > I will see what I can do with this, but I don't think it can be solved
   > overnight.
   >
   >    As you and others have pointed out, profiles and device links can
   >    iron out a lot of issues. It's really getting necessary for users
   >    to be let loose on this thing and deal themselves with inks and
   >    linearisation, rather than spending forever deciding which arcane
   >    feature should be buried in the C code at the next revision.

-- 
Robert Krawitz                                     <rlk at alum.mit.edu>

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf at uunet.uu.net
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton