Re: [Gimp-print-devel] Halftoning algorithms

[Raph L. <ra...@ac...>]

Karl Heinz Kremer wrote:
> 
> On Mon, Mar 06, 2000 at 06:12:53AM -0800, Raph Levien wrote:
> > This message was sent from Geocrawler.com by "Raph Levien" <ra...@ac...>
> 
> ... wait a minute, I know you! ... or at least I know what you
> did last summer :-)
> 
> You were involved in gcmm, is this correct? I downloaded the last
> snapshot this week to see if I can use it in SANE. The print plugin
> could also benefit from some ICC routines to do the RGB->CMYK
> transformation. I noticed that the project is pretty dormant since
> last year, is anybody using it? Are you planning to work on it any
> time soon?

Yep, that's the same me. I'm not working on the gcmm code any more
because Graeme Gill's libicc is a lot farther along and would appear to
kick ass.

Of course I've thought about using ICC to do the RGB->CMYK. Let me
present a few arguments against that:

1. The patent situation with ICC is murky at best. EFI owns a large
stable of patents on "color management" and is eagerly enforcing them.

2. There are no free tools for creating ICC profiles. Creating good ICC
profiles is hard.

3. ICC is a tad underspecified. It doesn't really address the issue of
gamut compression at all, particularly the black point. Common usage is
for there to be multiple cubes - the "absolute" one gives results with
absolute colorimetry, and if you specify a shade darker than the actual
black point of the output device, it clips. The "perceptual" one maps
[0..1] to the actual gamut of the printer, but the amount and type of
compression of hue and saturation is left unspecified. Grame talks about
this a bit more in his "the trouble with ICC" page.

4. ICC is not very robust. If you carefully create a profile for a
printer, then move that profile to a different unit of the same model,
or change paper, you basically get the positive effects of the new
printer plus the negative effects of the corrections for the old one.
Thus, it's quite easy to misapply ICC and get poor results.

Basically, the way I'd do it (and will do it if I get any bites) is to
do it the way big prepress color scanners did it in the '70s, which is a
big bunch of knobs. You have some global controls for dot gain,
highlight/midtone/shadow +/- for gray balance (so the CMY overprint gets
calibrated to the same hue as K), then highlight/midtone/shadow +/- for
each of RYGCBM colors.

The idea is that any reasonably skilled person could calibrate a printer
pretty well by getting a Kodak Q60 card and fiddling with the knobs
until it looks pretty close. (See
http://www.halftone.co.uk/tech/filmscan/overview.htm for a bit more info
on the Q60).

> But now back to our actual subject:

Indeed.

> >    I've done quite a bit of work over the years on
> > screening algorithms. I'm trying to push some of
> > them for commercial licensing, see
> > http://www.artofcode.com/eventone/ for details.
> 
> This looks very interesting. You are however talking
> about multiple algorithms and you want to push some
> of them... Are there any good ones left that are
> and will stay free? :-)

> >    To this end, I've been building a testbed that
> > includes RGB->CMYK conversion and actual device
> 
> I was looking into doing teh RGB->CMYK conversion based
> on ICC profiles. I just started reading about all things
> related to CMS systems. Can you either provide some
> input or direct me to good literature. I was thinking
> about getting the Giorgianni/Madden book.

I haven't found any really good references. I don't have the G/M book,
but from the Amazon description, it looks like it would be worth
getting.

> >    Not to overstate things, but the quality is
> > incredible. It is dramatically better than the gs
> > and gimp-print drivers, and, while I haven't done
> > serious comparison yet with the bundled windows
> > drivers, my guess is that it's comparable or
> > slightly better.
> 
> I did some one to one comparison of the print plugin and
> the Windows driver on the weekend, and even though the
> quality of Robert's code is quite good, it's still far
> from what I can get under Windows. (Can I admit here
> that I have vmware running just to print stuff?)

Right. Incidentally, I have been running the stc600 in 1440x720 highest
quality.

> >    I want to do the right thing in terms of
> > releasing this code as open source, but I'm moving
> > cautiously on that right now. There are a number
> > of companies who have stated that they're working
> > on improving print quality (the VA - HP alliance
> > and Corel come to mind), and I'd like to see if
> > they can fund the project.
> 
> You hold the patent to the algorighms (at least that's
> what I understand from reading your page), so you
> should be free to license the stuff to open source
> projects free of charge, but still charge for other
> licensees. As Eric already mentioned, there is no
> better resumee for you than to put the code out in
> the open and use a project like Gimp or GhostScript
> as "bill board" for the algorithm.

Right. And I plan to release the code under GPL and the patent under a
license that allows all GPL software to use it freely. The only question
is the timing. If I can get somebody to fund development as GPL
software, it will happen quickly. Otherwise, it will happen more slowly.

> >    In the meantime, I want to keep you guys in the
> > loop. I am happy to give you guys the code to play
> > around with, with the understanding that it is not
> > yet free software, but will be at some date in the
> > not too distant future. I talked to Peter Deutsch
> > a few days ago, so he's up to speed as well.
> 
> I am with Eric here: Don't make it available until
> it's really free. If somebody walks up to you
> tomorrow and offeres you a deal that's just too good
> to resist for the exclusive rights we would have a
> problem.

I think this is a very reasonable approach for you guys, actually.

> >    I've learned a lot by reading the gimp-print
> > code. I think you might enjoy reading through my
> > code. Among other things, I have _much_ simpler
> > code for microweaving. At the moment, the code is
> > specialized for the stc600 and needs to be
> > parameterized a bit, but the entire Epson driver
> > is 236 lines of code.
> 
> The weaving code is IMHO not the problem. It is now stable
> enough to even work on my STC740 :-) So I would not tamper
> with it. If you can offer something in regards to the
> error diffusion algorighm, this would help the quality of
> the plugin more than anything else.

Right. If it ain't broke, don't fix it :)

> I hope we can work something out together. I'm looking
> forward to hearing some great news from you,

Me too.

I'm going to do what I can to get the GPL licensing issue resolved
quickly. I'm eager to get the cool stuff out there in the field!

Raph