gimp-print-devel

[Gimp-print-devel] Another dither hack

[Robert L K. <rl...@al...>]

I've tried something else with the dither, to scale down randomness as
ink level increases.  Give it a try and let me know what you think.

-- 
Robert Krawitz <rl...@al...>      http://www.tiac.net/users/rlk/

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lp...@uu...
Project lead for The Gimp Print --  http://gimp-print.sourceforge.net

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

[Gimp-print-devel] Halftoning algorithms

[Robert L K. <rl...@al...>]

I'm not sure if Thomas Tonino is on the list...I'm reading his message
on geocrawler and I have comments on it.  If he's not, could someone
forward him the message?  His email address doesn't appear in the
archived message.

It's an interesting approach.  We're already suppressing color dots if
any black dots are printed, and taking overall density into account
when deciding whether to print light or dark inks (in darker areas we
use less of the dark ink rather than more of the light ink).  The
grayscale transitions still have some problems, though.  Actually, for
grayscale we get something like 8 times as many dots, since C+M+Y is
less than K.

I once experimented with only allowing one dot to be printed if the
density at that point was less than one.  It didn't help too much.

Any approach of this kind has to be very careful to avoid instability,
as I learned to my sorrow a couple of releases ago.  It wasn't showing
up in any of my tests, but someone ran across a bug in one of the
indexed modes where density wasn't being done, and the result was that
there were a lot of full-strength pixels.  The problem was that not
enough ink was getting printed to discharge all of the error, and the
built-up error got printed out in white areas very strangely.  I wound
up having to cap the accumulated error to avoid this.  Even that's not
perfect, which is why the line art mode uses much less color ink to
print black (it's grainier but sharper -- that's not a contradiction,
just ask any photographer who shoots Tri-X).

BTW, something else that I've done, which seems to have done a lot to
eliminate the diagonals so common with error diffusion, is to
distribute the error over a variable number of pixels.  Specifically,
the lighter the tone, the broader the region over which the error is
distributed.  This seems counterintuitive, but consider that the
inter-dot spacing is greater in pale areas, and we don't want the
adjacent dots to wind up too close to the largest accumulated error
(which will be just before a dot is printed in the current row).  In
darker areas, though, the dots are spaced closely together, so there's
no need to worry about that, and we'd lose sharpness by spreading the
error out too much.  This is the other trick of line art vs. smooth
tone vs. photograph mode that I play.  Line art mode uses no spread at
all on the assumption that sharpness is important and everything's
going to be dark enough so that the squiggles won't show up.  Smooth
tone uses more spread, which reduces sharpness a little but results in
smoother texture in pale areas.  For photographs, ultimate sharpness
of edges is normally less important, but good texture is more
important.

I've been experimenting with a few other dither variations.  What
we're doing right now is technically incorrect for anything but
monochrome and four color.  It works very well for six color single
dot size (although the two-pass modes are somewhat ugly), but it's all
wrong (in principle, maybe not in practice) for variable dot size.  It
also changes the dark/light mix at different density levels.  However,
the technically correct variants I came up with (one a relatively
minor change and one not so minor) look pretty ugly.  Go figure.

The other oddity is that for light midtones the line art mode is
smoother than photographic mode.  That's because the line art mode is
less random.  The problem with it is that it simply doesn't deposit
any ink at all in very light areas, so it's not very good for real
continuous tones.  So I tried experimenting with changing the
randomness based on the 

-- 
Robert Krawitz <rl...@al...>      http://www.tiac.net/users/rlk/

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lp...@uu...
Project lead for The Gimp Print --  http://gimp-print.sourceforge.net

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

[Gimp-print-devel] Epson

[Robert L K. <rl...@al...>]

Karl, thanks for taking the lead with this.  I'm happy with you as
contact; you've built this one up, and given your SANE stuff they'd
probably be happy dealing with you.  I'm curious what the ISV support
form is...

Pity about the remote mode and all, but we can always do things one
step at a time.

BTW, this isn't a reply because my ISP's mail forwarder seems to be
horribly backed up, so the two messages from today haven't hit my
mailbox yet (they probably will overnight).  This seems to be an
ongoing problem.

-- 
Robert Krawitz <rl...@al...>      http://www.tiac.net/users/rlk/

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lp...@uu...
Project lead for The Gimp Print --  http://gimp-print.sourceforge.net

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

[Gimp-print-devel] 3.1.2

[Robert L K. <rl...@al...>]

I don't expect to have any chance to do a release this weekend, since
we're going to a wedding in New York.  However, I'd like to do it as
soon as we get a chance, particularly if the new GUI stuff is in a
usable form.

-- 
Robert Krawitz <rl...@al...>      http://www.tiac.net/users/rlk/

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lp...@uu...
Project lead for The Gimp Print --  http://gimp-print.sourceforge.net

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

[Gimp-print-devel] Halftoning algorithms

[Thomas T. <tt...@bi...>]

I have recently been thinking about how Ghostscript dither quality could
be improved. I came up with two major ideas.

My most recent idea was to use Floyd-Steinberg on the brightness of the
image. Instead of deciding per color when to print, decide on the basis
of total accumulated error. When that exceeds threshold, print the color
with the darkest error and distribute errors accordingly. In light tints
colors will not overlap any more, hopefully leading to smoother and
brighter results.

Example pseudocode:

For x,y in image:
  While (Cyan[x,y]+Magenta[x,y]+Yellow[x,y]+Black[x,y]) > Threshold
    Find the largest of Cyan[x,y] Magenta[x,y] Yellow[x,y] Black[x,y]
    Print a dot in this color 
    ThisColor[x,y] -= dotsize  # so we can exit the while loop
                               # the value is the error; it is
distributed over the neighboring pizels
    ThisColor[x+1,y] += ThisColor[x,y] * 7/16
    ThisColor[x-1,y-1] += ThisColor[x,y] * 3/16
    ThisColor[x,y-1] += Thiscolor[x,y] * 5/16
    ThisColor[x+1,y-1] += Thiscolor[x,y] * 1/16

I think this will give 3 times as many effective pixels for greyscale
images. Color is printed a bit less accurately, but the human eye
notices color variations less than variations in brightness. Manual
execution with a spreadsheet showed color dots not being printed on top
of each other, unless the total ink amount was so high that overlap was
needed. With per-color Floyd-Steinberg, the occasional 2 or 3 color
pixel shows up, and the interference patterns between the different ink
colors can show up as coarseness.

An older idea was to take dot overlap into account. If two dots are
printed adjacent to each other, they overlap. As a result the two dots
are not as dark as when they would have been printed a bit apart from
each other. I do not know if this is something that must be taken into
account: overlapping will only happen near full density and I doubt if
this modification does anything except change the tone curve somewhat.

Thomas Tonino

[Gimp-print-devel] Fwd: RE: Printer info for Linux

[Karl H. K. <kh...@kh...>]

I just received the attached message from EPSON's Developer
Relations department. Unfortunately the remote mode is not
considered part of ESC/P2, so we still don't know about how
to get the inklevels from the printer - at least not through
official documentation.

The engineer I'm in contact with asked me to remove his email
address, which I've done. He prefers to receive all inquries
through me. Looks like I've a new hat now. :-)=20

The ISV he's refering to is in our case (because we don't
have any employees, existing products, official plans to
support future products, ..) just a name, email address
and snail mail address. If nobody objects, I will act as
contact for this project as well (I was already in touch=20
with EPSON wearing my SANE EPSON backend maintainer hat).

Karl Heinz

----- Forwarded message from Po Yang -----

From: "Po Yang"=20
To: <kh...@kh...>
Subject: RE: Printer info for Linux
Date: Tue, 14 Mar 2000 13:56:03 -0800
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)

Hello Karl,

We had an internal meeting.  It was decided that we can open up all the
ESC/P2 commands to third party developers even without NDA.  However,
particular solutions, such as microweaving and halftoning, will not be
provided.  Given my profound respect for the talent that abounds within the
Linux community, I am sure that the solutions engineered by these freelance
developers will rival (if not surpass) the print quality on EPSON's Windows
drivers.

Actually, we would really appreciate it if you could fill out one of our ISV
Support Program Application.  It's just for our internal record keeping
purpose.  Thanks.

If you have any questions, please let me know.
Po.

----- End forwarded message -----

--=20
Karl Heinz Kremer                                      kh...@kh...
                                                http://www.khk.net

[Gimp-print-devel] New stuff

[Robert L K. <rl...@al...>]

I'm about to commit a new mode called "monochrome".  This mode prints
pure black and white with no dithering.  It's intended for text or
pre-screened or pre-dithered input.

I also cleaned up the gs driver a bit.

[Gimp-print-devel] Dithering changes

[Robert L K. <rl...@al...>]

I've made some fairly significant changes in the dither code.  I've
added new modes for line art, solid color, and continuous tone
(basically, these flip various settings in the dither code).  I've
modified the dither code itself to do a better job of diffusing error,
and 1440x720 highest quality and 1440x720 two pass look significantly
better.

What line art does differently from continuous tone (photo) is:

1) Spreads error less widely.

2) Reduces the black threshold.

3) Reduces the randomization.

Solid tone is somewhere between these two modes.

-- 
Robert Krawitz <rl...@al...>      http://www.tiac.net/users/rlk/

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lp...@uu...
Project lead for The Gimp Print --  http://gimp-print.sourceforge.net

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

Re: [Gimp-print-devel] status

[Michael N. <mit...@cs...>]

On Thu, 9 Mar 2000, S. Miller wrote:

> I've made some progress in getting the gui part separated from print.c,
> and a separate popup for the color adjustment sliders.  I've also been
> working on renaming everything according to an agreement with Mitch, so
> we don't have symbol collisions with his gimp gui.  I hope to have
> something to commit by the end of the weekend.

Hi all,

unfortunately, I didn't get around hacking any more print ui stuff
before I left Berlin (writing this mail from far away...)

I'll start merging my gimp-specific ui stuff when I'm back from
GUADEC, which should be in about 10 days.

bye,
--Mitch

Re: [Gimp-print-devel] status

[S. M. <sm...@rn...>]

Robert L Krawitz wrote:
> 
> How are people doing?
> 
> Somebody sent me some output from a 750 and it, uh, has problems (it
> needs some heavy duty tuning -- it's way too pale, particularly in
> variable dot mode).  What's output like from a 740 (or 900 if it
> works, if anyone has one)?
> 
> How's everything else coming along?
> 
> --
> Robert Krawitz <rl...@al...>      http://www.tiac.net/users/rlk/
> 
Since I can't seem to get anything through to Robert, I'll post this to
the list:

I've made some progress in getting the gui part separated from print.c,
and a separate popup for the color adjustment sliders.  I've also been
working on renaming everything according to an agreement with Mitch, so
we don't have symbol collisions with his gimp gui.  I hope to have
something to commit by the end of the weekend.

Steve

-----------------------------------------
Just because I have a short attention span
doesn't mean I
------------------------------------------

[Gimp-print-devel] dither stuff

[Robert L K. <rl...@al...>]

I wrote up some documentation on what the dither knobs do.  See
README.dither.  I also did some performance tweaks on the dither
routines.  They don't do very much on the color routines, but they
help by 10-15% on dither-black(), which should be fast since it's used
for printing text and such (it's still not fast enough; it takes about
25-30 seconds on my machine to render a letter-size page, although I
think a fair bit of that time is spent inside the Gimp since I only
get about 15 seconds from my profile).

-- 
Robert Krawitz <rl...@al...>      http://www.tiac.net/users/rlk/

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lp...@uu...
Project lead for The Gimp Print --  http://gimp-print.sourceforge.net

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

Re: [Gimp-print-devel] status

[Karl H. K. <kh...@kh...>]

The 740 is still printing, I'm still waiting for the changes you
made over the last few days to break something :-)

If you send me your mailing address (I guess in a private email)
then I can mail you a printout from the current version. I'm trying
to tweak the controls so that I get the colors at least into the
right ballpark. I see too much black in the output. In areas where
I would not expect to see any black pixels they appear all over the
place.=20

Karl Heinz


On Tue, Mar 07, 2000 at 09:04:36PM -0500, Robert L Krawitz wrote:
> How are people doing?
>=20
> Somebody sent me some output from a 750 and it, uh, has problems (it
> needs some heavy duty tuning -- it's way too pale, particularly in
> variable dot mode).  What's output like from a 740 (or 900 if it
> works, if anyone has one)?
>=20
> How's everything else coming along?
>=20
> --=20
> Robert Krawitz <rl...@al...>      http://www.tiac.net/users/rlk/
>=20
> Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
> Member of the League for Programming Freedom -- mail lp...@uu...
> Project lead for The Gimp Print --  http://gimp-print.sourceforge.net
>=20
> "Linux doesn't dictate how I work, I dictate how Linux works."
> --Eric Crampton
>=20
> _______________________________________________
> Gimp-print-devel mailing list
> Gim...@li...
> http://lists.sourceforge.net/mailman/listinfo/gimp-print-devel

--=20
Karl Heinz Kremer                                      kh...@kh...
                                                http://www.khk.net

[Gimp-print-devel] status

[Robert L K. <rl...@al...>]

How are people doing?

Somebody sent me some output from a 750 and it, uh, has problems (it
needs some heavy duty tuning -- it's way too pale, particularly in
variable dot mode).  What's output like from a 740 (or 900 if it
works, if anyone has one)?

How's everything else coming along?

-- 
Robert Krawitz <rl...@al...>      http://www.tiac.net/users/rlk/

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lp...@uu...
Project lead for The Gimp Print --  http://gimp-print.sourceforge.net

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

Re: [Gimp-print-devel] HPdj694c Photoink...

[Robert L K. <rl...@al...>]

   Date: Tue, 7 Mar 2000 19:07:44 +0100
   From: Andreas Eckleder <A.E...@bi...>

   What about supporting HP's photoink set of the 600 series.
   It works pretty much the same as with that epson printer
   already supported by gimp-print,
   namely by providing two additional colors.
   I'd love to help with development as good as I can,but I've never done
   dithering etc. before.
   Unfortunately,HP does no longer explain their computer->printer protocol
   (PCL) in their manuals as they did with the 500 series.

The dithering routines are already in there; it's just a matter of
arranging the HP code to use them.

-- 
Robert Krawitz <rl...@al...>      http://www.tiac.net/users/rlk/

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lp...@uu...
Project lead for The Gimp Print --  http://gimp-print.sourceforge.net

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

[Gimp-print-devel] HPdj694c Photoink...

[Andreas E. <A.E...@bi...>]

Hi there !

What about supporting HP's photoink set of the 600 series.
It works pretty much the same as with that epson printer
already supported by gimp-print,
namely by providing two additional colors.
I'd love to help with development as good as I can,but I've never done
dithering etc. before.
Unfortunately,HP does no longer explain their computer->printer protocol
(PCL) in their manuals as they did with the 500 series.

Andy

Re: [Gimp-print-devel] Halftoning algorithms

[Karl H. K. <kh...@kh...>]

Raph Levien <ra...@ac...> said: 
[ ... ]
> 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.

I've looked at this as well, and at a bunch of other projects all
trying to do the same stuff. Talk about reinventing the color wheel
again and again and again ... Maybe it's about time to get all the
people working on CM stuff together at one virtual table.

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

That's probably the biggest issue. I am no IP lawyer (and I have
not even seen one on TV :-) so this is probably also the biggest
obsticle.

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

Actually there are. See the end of this message.

[ ... ]
> 
> 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.

I know. And that's why I propose a closed loop approach.

You mention the Kodak Q60 target, which is a bit expensive for
just home users. You can get an affortable IT8 targets from 
Wolf Faust: http://www.targets.coloraid.de/ 

Also, there is a free (as in beer) profile editor available at
http://www.abaforum.es/martim/bird/index.htm - unfortunately
it's just for Windows, and so far I was not able to start it under
Wine.

I exchanged some emails with Wolf Faust. He wrote a complete
color management system for the Amiga. This is also free as in beer.
He is working on making it platform independant, but does not have a
lot of time to work on it. So for the same reasons as you, he's 
looking for somebody who could support the development of this free
system. I don't know yet if he's aware of the patent issues.

Another free (now as in speech) ICC based system is at
http://www.abaforum.es/martim/lcms.htm (LGPL). Again, this is just
Windows software and at this time it can only run on x86 processors
because of assembler routines to implement some fixed point math
routines.

What I envision is a closed loop system that does not require a lot 
of tweaking and no expensive tools: You put a standard IT8/7 target 
on your scanner and produce a color correction for you scanner (that's
probably a RGB->sRGB correction just so that the image looks nice on
the screen). Then you print this image without any color correction
(all sliders on default position) using the ink you have installed,
with the paper you usually use, ... This will of course not look
anything like the original. So you put this printout on your scanner
and scan it using the already established scanner correction. Then
some magic occurs and generates the color correction for your 
printer. You do the same once more with the printer correction in
place, do some fine tuning and from there on they lived happily ever
after...

I think all the levers and knobs make the software too complicated 
to the casual user who nevertheless wants some quality output. We
should however leave all these controls in the software so that the
expert user still can have full control over every aspect of the
printout.

How does this sound?

Karl Heinz

Re: [Gimp-print-devel] Halftoning algorithms

[Karl H. K. <kh...@kh...>]

Raph Levien <ra...@ac...> said: 
[ ... ]
> 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.

I've looked at this as well, and at a bunch of other projects all
trying to do the same stuff. Talk about reinventing the color wheel
again and again and again ... Maybe it's about time to get all the
people working on CM stuff together at one virtual table.

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

That's probably the biggest issue. I am no IP lawyer (and I have
not even seen one on TV :-) so this is probably also the biggest
obsticle.

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

Actually there are. See the end of this message.

[ ... ]
> 
> 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.

I know. And that's why I propose a closed loop approach.

You mention the Kodak Q60 target, which is a bit expensive for
just home users. You can get an affortable IT8 targets from 
Wolf Faust: http://www.targets.coloraid.de/ 

Also, there is a free (as in beer) profile editor available at
http://www.abaforum.es/martim/bird/index.htm - unfortunately
it's just for Windows, and so far I was not able to start it under
Wine.

I exchanged some emails with Wolf Faust. He wrote a complete
color management system for the Amiga. This is also free as in beer.
He is working on making it platform independant, but does not have a
lot of time to work on it. So for the same reasons as you, he's 
looking for somebody who could support the development of this free
system. I don't know yet if he's aware of the patent issues.

Another free (now as in speech) ICC based system is at
http://www.abaforum.es/martim/lcms.htm (LGPL). Again, this is just
Windows software and at this time it can only run on x86 processors
because of assembler routines to implement some fixed point math
routines.

What I envision is a closed loop system that does not require a lot 
of tweaking and no expensive tools: You put a standard IT8/7 target 
on your scanner and produce a color correction for you scanner (that's
probably a RGB->sRGB correction just so that the image looks nice on
the screen). Then you print this image without any color correction
(all sliders on default position) using the ink you have installed,
with the paper you usually use, ... This will of course not look
anything like the original. So you put this printout on your scanner
and scan it using the already established scanner correction. Then
some magic occurs and generates the color correction for your 
printer. You do the same once more with the printer correction in
place, do some fine tuning and from there on they lived happily ever
after...

I think all the levers and knobs make the software too complicated 
to the casual user who nevertheless wants some quality output. We
should however leave all these controls in the software so that the
expert user still can have full control over every aspect of the
printout.

How does this sound?

Karl Heinz

Re: [Gimp-print-devel] Halftoning algorithms

[Robert L K. <rl...@al...>]

   Date: Mon, 06 Mar 2000 18:43:47 -0800
   From: Raph Levien <ra...@ac...>

   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.

That's more or less what's going on with us -- there are a whole bunch
of knobs (at least internal to the dither engine -- none of them are
brought out to the end user, although there is an API).  The
particular controls that are in there are different, but this kind of
"cut & try" seems like the right thing.  There are so many different
kinds of paper, so many different kinds of ink, so many different
cloggednesses of print heads, that trying to get too scientific is
going to be difficult.

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

That's what you get from someone who buys a Photo EX from a friend and
then realizes that he has to somehow get it working under Linux, and
then finds some code floating around and h4X0rz away on it :-) :-) :-)
I've never even seen a 600.  However, the EX has a sufficiently
compatible printhead that I can use the 600 driver, and it certainly
does leave something to be desired.  The EX output is, I daresay,
somewhat better.  Big surprise.

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

The flip side is that people like VA and Red Hat want to actually see
something before they're going to fund it.  Feeding code into the Gimp
plugin that's significantly better than anything else out there, and
having it just plug into Ghostscript, and working towards a real free
print system (Ghostscript isn't enough -- it's a decent back end, but
there needs to be a front end and middleware) is something that might
catch people's attention.

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

Yeah, except when I get some damn fool idea to clean it up and usually
break something in the process. Nobody's complained since my last
round of commits, so it's possible that I got most of the stuff right,
except for the handful of obscure bugs I found and fixed tonight.
Although it's at the point where I'm dead scared to actually touch
anything in the weave calculation per se :-(  There is a unit test for
it, though.

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

I'd definitely like to help you out somehow, as long as the end result
is that we have something we can put in our GPL'ed stuff.

-- 
Robert Krawitz <rl...@al...>      http://www.tiac.net/users/rlk/

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lp...@uu...
Project lead for The Gimp Print --  http://gimp-print.sourceforge.net

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

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

Re: [Gimp-print-devel] Halftoning algorithms

[Karl H. K. <kh...@kh...>]

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

=2E.. 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=20
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?

But now back to our actual subject:

>    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=20
and will stay free? :-)

>=20
>    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=20
input or direct me to good literature. I was thinking
about getting the Giorgianni/Madden book.=20

>    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=20
from what I can get under Windows. (Can I admit here=20
that I have vmware running just to print stuff?)

>    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=20
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.

>=20
>    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=20
tomorrow and offeres you a deal that's just too good
to resist for the exclusive rights we would have a=20
problem.=20

>=20
>    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=20
error diffusion algorighm, this would help the quality of=20
the plugin more than anything else.=20

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

Karl Heinz

--=20
Karl Heinz Kremer                                      kh...@kh...
                                                http://www.khk.net

[Gimp-print-devel] Makefile.standalone

[Dave H. <da...@mi...>]

Makefile.standalone is now working again, it understands about
"printdef".

Dave

-- 
Dave Hill, Kempston, Bedford UK		da...@mi...
Sicth munce ago, I cutn't evun spel enjuneer, and now I are one!

Re: [Gimp-print-devel] Halftoning algorithms

[Robert L K. <rl...@al...>]

   Date: Mon, 6 Mar 2000 06:12:53 -0800
   From: "Raph Levien" <arc...@db...>

      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.

Interesting.

      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.

Did you try 1440x720 highest quality?  That gives markedly better
results than any of the other choices.  It's still a randomized error
diffusion, though, so it still creates wormy artifacts.  However, I'm
quite certain that it's not the last word in dithering algorithms :-)

      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.

For us to be able to use it it will have to be GPL.  I notice that you
have a patent on some of this stuff, so that would have to be worked
out.  However, this would certainly be very interesting to look at.

      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.

Well, this code is trying to support all of the different Epson
printers, so there's a good bit more complexity involved, particularly
with the quirky command sets different output modes we support...

-- 
Robert Krawitz <rl...@al...>      http://www.tiac.net/users/rlk/

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lp...@uu...
Project lead for The Gimp Print --  http://gimp-print.sourceforge.net

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

Re: [Gimp-print-devel] Halftoning algorithms

[<sh...@al...>]

> Hi gimp print people,

Hi.

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

As a copyright holder, you can license your code under many as many
different licenses as you like.  Commercial, closed source licensing
is not precluded by releasing code under an Open Source license.

>    To this end, I've been building a testbed that
> includes RGB->CMYK conversion and actual device
> driving. Thus, this work duplicates driver work in
> both GhostScript and gimp-print. So far, I have
> drivers for Epson Stylus Color Pro and Stylus
> Color 600.

Why should a dithering algorithm be device specific?

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

If you'd like to discuss legal implications, we can certainly do that.
I'm not a lawyer, but, I've seen one on TV.

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

Probably the best way to impress VA/Corel is to release the code.  The
code becomes your resume.

>    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

Thanks.  I can't speak for the group, but, I'd rather not see the code
until it's free.  If, for any reason, the code never becomes free, there's
always the possibility that we could be influenced by ideas in the code.
It's probably better for us not to see it at all.

Eric

[Gimp-print-devel] Halftoning algorithms

[Raph L. <arc...@db...>]

This message was sent from Geocrawler.com by "Raph Levien" <ra...@ac...>
Be sure to reply to that address.

Hi gimp print people,

   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.

   To this end, I've been building a testbed that
includes RGB->CMYK conversion and actual device
driving. Thus, this work duplicates driver work in
both GhostScript and gimp-print. So far, I have
drivers for Epson Stylus Color Pro and Stylus
Color 600. The code pushes both of these printers
to the limit, achieving full 1440 x 720 resolution
in the latter case.

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

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

Raph


Geocrawler.com - The Knowledge Archive

[Gimp-print-devel] MAJOR CHANGE in printer definitions

[Robert L K. <rl...@al...>]

I've moved all of the printer definitions out of print-util.c to a
(pseudo) XML file called printers.xml.  I've written a quick and dirty
parser using flex and bison to do the deed.  In principle, it's now
possible to set any of the printer variables (not just density and
gamma) this way, although this isn't implemented (in print-util or
anywhere) yet.

The very obvious next step would be to parse this file at runtime.
This would allow people to add their own printer definitions without
recompiling anything.

I initially generated this file with a one-shot throwaway program
(since the original printer definitions have been tossed).  I smoke
tested it on my printer, but it's likely that there are still a few
bugs left.  The Ghostscript driver compiles, but I haven't tested it.