[Openicc] CC Profiles In X Specification and dispwin

[Robert Krawitz]

   From: "Hal V. Engel" <hvengel at astound.net>
   Date: Tue, 15 Jan 2008 15:01:59 -0800

   On Tuesday 15 January 2008 13:36:17 Kai-Uwe Behrmann wrote:
   > Am 15.01.08, 21:31 +0100 schrieb edmund ronald:
   > > Ink limitation, ink curves and linearization need to be exposed to
   > > those doing the profiling since all of the above vary with the medium
   > > being profiled. 

   Most of these are exposed by the GutenPrint API.  Have a look at
   the gimp-print plugin (this is also used by CinePaint which has a
   CM wrapper on top of it as well).  In the UI you can set per
   channel and total ink limits (these have an OK UI) and ink curves
   (very bad UI currently).  There is currently no linearization
   functionality exposed in the UI so I don't know if this is
   supported at the API level.  But if it is not then this feature
   should be fairly far up on the GutenPrint Color Management TODO
   list along with making the ink curves UI more usable.

I need help with exactly what's needed here in terms of both the API
and the UI.  It does no good to say "linearization" -- I need a
specific description of what it does.

As far as the UI goes, I could use some actual coding assistance.  I'm
not very good at user interface design or programming, and if we want
the UI to be any good, somebody else should do it.

But I have some other, more specific questions about the API.  It's
not too hard to figure out what needs to be exposed for single drop
size CMYK printers (such as the Epson 3000), but once we get into
variable drop sizes, multiple shades of ink (CcMmYK, CcMmYKkk, etc.),
and extra colors (think R1800), there are a lot of other things that
can be exposed, such as the ratios between the darknesses of the ink,
drop size ratios, and so forth.  I don't think that the right answer
is "well, we want to color manage down to CMYK, but we trust the
driver will do the right thing with subchannel separation and
auxiliary color generation".  CMYK profiles on an R1800 with no
control over red and blue generation makes very little sense to me,
and likewise I would think that the CM layer would want control over
channel splitting.  Not to mention ink limiting in these environments
-- if there's a lot of ink already, should we bias toward using the
dark shades, for example.

   > > A good target -as always with open source products- 
   > > would be to reproduce a simplified but robust version of the tools
   > > available with a commercial RIP. 

   I agree and Robert has told me that this is what he intends to do.

Well, not precisely -- I want to have a good RIP, but not necessarily
a clone of a commercial product.  I know that we have to walk before
we can run, but I'm not interested in playing catchup forever.

   So I think everyone is on the same page with this.  But of course
   as the saying goes the devil is in the details.  GutenPrint 5.x
   added many of these features at least at the API level so this is
   definitely moving in that direction.  But I think the UI is
   currently lagging behind the driver back end.

Yes it is, and there are a variety of reasons for this:

1) Gutenprint per se doesn't really even have a UI.  The GIMP plugin
is a front end, as is the Cinepaint plugin and PhotoPrint.  Even any
CUPS front end can be considered a UI.  So we have to talk about which
UI, for starters.

2) Like I said above...UI isn't my strength.  I'd rather focus on the
API and the underlying implementation.

3) I have a beef -- a 32 oz prime rib, well done (that's how I like
it), to be precise -- with the whole attitude of most of the FOSS
printing community toward anything related to producing high quality
output and the controls necessary for generating this kind of output.
Altogether too much effort is being spent on printer management, PPD
file management (there's something else that needs to go away),
resource accounting, and all that.  There aren't that many of us who
care about the quality of the resulting print.

   I have never used any of the commercial RIPs so I can't give Robert
   much feedback on what needs to happen to move in that direction.
   If you have I am usre Robert is very open to your input.

I'm open to input, but "a way to save away settings" or the like isn't
very useful.

-- 
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