BTW, I've put a new version on
http://www.tiac.net/users/rlk/print.tar.gz. This one improves the
smoothness of regions of mixed Cc and Mm (light and dark cyan and
magenta); that's about the only difference.
Date: Thu, 28 Oct 1999 15:37:26 -0400
From: Michael Sweet <[EMAIL PROTECTED]>
Robert L Krawitz wrote:
> 4) The K->CMY code is distinctly tuned for the Stylus Photo EX
> right now. Sorry, I don't have another color printer to play
> This should be addressed, but it won't be unless we get testers.
GCR and UCR can be a pain to get right. Here's a possible solution
based on the CMYK generation code we're currently using in CUPS:
This reduces the amount of black based on the saturation of
the color (more saturated means less black), and uses a GCR
function/lut to control the final amount of black.
The intent of doing this isn't to improve saturation, but rather to
minimize pixelation/graininess in bright (little ink) highlights. In
fact, it's largely in UNsaturated regions (even light to medium
grays!) that I want to eliminate the use of black altogether, to
create a smooth texture.
The other part of the problem is that an equal mix of CMY doesn't
actually produce a neutral gray, particularly when the use of light
inks is taken into account. Right now I'm using a ratio of
K = C + 9M/8 + 3Y/2
to get a reasonable gray balance, and of course this will vary with
implementation might just use a cutoff level and ramp the
values starting at the cut-off point, e.g.:
for (i = 0; i < GCRlevel; i ++)
GCR[i] = 0;
for (; i < 256; i ++)
GCR[i] = 1 + (i - GCRlevel) * 254 / (255 - GCRlevel);
That's similar to my approach, although not with a lookup table (look
for KDARKNESS_LOWER, which is your GCRlevel, and KDARKNESS_UPPER,
which is an upper bound at which we simply use all black). Actually,
kdarkness is a function of the other color intensities; the darker the
other colors are, the more black mixes in.
We're looking into doing something similar for CUPS 1.1 that will
also provide a gamma (power) value for the GCR LUT.
> 5) The Stylus Photo printing has become very slow for some reason
> (at least at 720 dpi). On the other hand, the
> microweave-induced banding has entirely vanished, yielding
> much (arguably spectacularly) better quality. I'm not
> positive exactly what did this, but it's not at the top of my
> list of priorities to "fix". If it takes 30 minutes to print a
> really high quality full-page print that doesn't seem so bad.
> Not to be fixed, since this "problem" improves output quality
> substantially in the highest quality output mode.
30 minutes is way too long. I'm still wrangling with EPSON over the
softweave algorithm; hopefully we'll be able to include the code in
a future print plug-in/CUPS driver, which lowers print times
I've seen prints made with softweaving, and I think that the 30-minute
print job produces better quality than any softweave I've seen thus
far. I'd like to offer it as an option for someone who wants the
absolute maximum quality. I have some softweave stuff generated from
other applications; even if you can't include it, I may be able to
reverse engineer it purely from generated output. I think someone
already has for Ghostscript.
Robert Krawitz <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
"Linux doesn't dictate how I work, I dictate how Linux works."