[Openicc] [Gimp-print-devel] Drop size calibration
Robert Krawitz
rlk at alum.mit.edu
Sun Jan 27 18:05:33 PST 2008
Date: Sun, 27 Jan 2008 17:37:23 -0800
From: "Roy Harrington" <roy at harrington.com>
As far as I can tell your method is matching the density of a 10%
large dot with say a 20% small dot. But in a real print the
transition from small dot to large dot happens at a much higher
percentage -- say 100% small to 50% large. So while it would seem
that mathematically its the same thing, the non-linearity of dot
gain makes a difference. Small dots have more relative dot gain
than larger dots because the circumference to area ratio is larger.
I suspect this is a least one factor causing your "larger" small
dots.
I think you can use the same idea but make the constant strip 100%
small dot and the gradient strip the large dot. This is basically
what I measure. I like your idea about making the different ranges
for each dot size, I may have to try something similar. (I've been
using an environment variable to force single dots but this
requires 3 print jobs not 1).
OK, I just tried it (this new way of doing things is *so much faster*
than it used to be).
At 1440x1440 DPI, the crossover from medium to large is at about 0.40
and from medium to large, at about 0.77. The crossover from small to
large is at about 0.325 (interpolating). It should be about 0.308.
That's within about 5%.
At 720 DPI, the crossover from medium to large is at about 0.40, and
from small to medium, at about 0.30. The crossover from small to
large is at about 0.14 (it should be around 0.12).
At 1440x1440 DPI, these numbers are an almost perfect match for what I
got from the 10% dark method, and are very different from what we
previously came up with. At 720 DPI, it's not such a perfect match,
but it's closer to what I'd expect.
This implies that the small drop sizes are 1.5, 2.0, and ~4.5 pl. The
large drop sizes are 1.5, 3.75, and somewhere between 10.5 and 12 pl.
That's a lot different from what we came up with.
However, we believe that the large drop size in the small set is the
same as the medium drop size in the large set (the small set is drop
sizes 1, 2, 3 and the large set is 1, 3, 5). This is off by almost
20%.
I'm going to have to try this, and compare it with 5760x1440, where
only the smallest drop size is used. If it works better, then we have
a bit of a problem: do we go back and retune existing printers, or
just use this going forward?
Here's the test pattern config file I used.
printer "escp2-rx580";
hsize 1.0;
vsize 0.1;
left 0.0;
top 0.7;
mode gray 16;
steps 100;
blackline 0;
parameter "DitherAlgorithm" "Segmented";
parameter "ColorCorrection" "Raw";
parameter "Resolution" "720sw";
parameter "InkType" "PhotoCMYK";
parameter "PrintingMode" "BW";
xpattern 0.75 1.0 1.0;
xpattern 0.74999 0.74999 1.0;
xpattern 0.75 1.0 1.0;
xpattern 0.74999 0.74999 1.0;
xpattern 0.75 1.0 1.0;
xpattern 0.74999 0.74999 1.0;
xpattern 0.75 1.0 1.0;
xpattern 0.74999 0.74999 1.0;
xpattern 0.75 1.0 1.0;
grid 100;
grid 100;
grid 20;
grid 20;
grid 10;
grid 10;
grid 20;
grid 20;
grid 100;
grid 100;
xpattern 0.5 0.74999 1.0;
xpattern 0.49999 0.49999 1.0;
xpattern 0.5 0.74999 1.0;
xpattern 0.49999 0.49999 1.0;
xpattern 0.5 0.74999 1.0;
xpattern 0.49999 0.49999 1.0;
xpattern 0.5 0.74999 1.0;
xpattern 0.49999 0.49999 1.0;
xpattern 0.5 0.74999 1.0;
grid 100;
grid 100;
grid 20;
grid 20;
grid 10;
grid 10;
grid 20;
grid 20;
grid 100;
grid 100;
xpattern 0.75 1.0 1.0;
xpattern 0.49999 0.49999 1.0;
xpattern 0.75 1.0 1.0;
xpattern 0.49999 0.49999 1.0;
xpattern 0.75 1.0 1.0;
xpattern 0.49999 0.49999 1.0;
xpattern 0.75 1.0 1.0;
xpattern 0.49999 0.49999 1.0;
xpattern 0.75 1.0 1.0;
--
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
More information about the openicc
mailing list