[Openicc] [Gimp-print-devel] Drop size calibration

Sat Feb 2 13:39:11 PST 2008

   Date: Sun, 27 Jan 2008 21:05:33 -0500
   From: Robert Krawitz <rlk at alum.mit.edu>

      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?

Just to follow up on this: I changed the segmented dither algorithm so
that if the bits to be printed are 0, it treats the value (shifted
left appropriately) as input to a normal ordered dither.  This lets me
directly compare multiple drop sizes against one drop size, so I can
do something like this:

xpattern 0.75 1.0 1.0;
xpattern 0.0 0.24999 1.0;

to compare the use of large drops only (top row) with all drops
(second row).

Upshot: the numbers 0.315, 0.4, 1.0 are much better than the current
setting of 0.23, 0.37, 1.0, but they aren't perfect, either.  The best
numbers I got when using the above comparison were 0.34, 0.4, 1.0 (so
comparing small/large and medium/large worked better than comparing
small/medium and medium/large).  The match isn't absolutely perfect,
but it's very close.

The actual file I used is below.  What this one does is compare 0~0.75
using all drops against 0~0.6 through 0~1.0 using only large drops.
By selectively turning off drop sizes 1 and 2, I can easily calibrate
both drop sizes separately (for drop size 1 I look for a close match
in the highlights; for drop size 2 I look in the midrange).  Errors
are easily visible as fine bands in the highlights or midrange.  The
upper part of the output pattern compares 0~1 in both large drops only
and in all drop sizes, so I can compare the exact choice of drop size.

Incidentally, I'm seeing only the faintest sign of the dot gain
problems we have been theorizing about, suggesting that there's
actually little need for a 3-level dither, at least on the paper I
used for my test.

So it looks like the workflow is:

1) Use the previous pattern I came up with for a rough calibration.
   It got me to within 5%.  Depending upon how good the quality
   control of the nozzles really is, that may be sufficient,
   particularly on lower end printers.

2) Use this vernier-like technique for a final calibration.  It takes
   a bit longer, but it appears to yield more accurate results (since
   it directly compares large drops against all drops).

I will retry this at 720 DPI, using the larger drop set, when I next
have an opportunity.  I don't know how well the vernier technique will
work with larger drops, but I'll try it and see.  I might need to use
wider bands because of the lower resolution.

printer "escp2-rx580";
hsize 1.0;
vsize 0.05;
left 0.0;
top 0.35;
mode gray 16;
steps 200;
blackline 0;
parameter "DitherAlgorithm" "Segmented";
parameter "ColorCorrection" "Raw";
parameter "Resolution" "1440x1440ov";
parameter "InkType" "PhotoCMYK";
parameter "PrintingMode" "BW";
parameter_float "DropSize1" 0.0;
parameter_float "DropSize1" 0.34;
parameter_float "DropSize2" 0.0;
parameter_float "DropSize2" 0.4;

xpattern 1.0 1.0 1.0;
xpattern 0.75 1.0 1.0;
xpattern 0.0 0.24999 1.0;
xpattern 0.75 1.0 1.0;
xpattern 0.0 0.24999 1.0;
xpattern 0.75 1.0 1.0;
xpattern 0.0 0.24999 1.0;
xpattern 0.75 1.0 1.0;
xpattern 0.0 0.24999 1.0;
xpattern 0.75 1.0 1.0;
xpattern 0.0 0.24999 1.0;
xpattern 0.75 1.0 1.0;
xpattern 0.0 0.24999 1.0;
xpattern 0.75 1.0 1.0;
xpattern 1.0 1.0 1.0;
xpattern 0.0 00.18749 1.0;
xpattern 0.75 0.9 1.0;
xpattern 0.0 00.18749 1.0;
xpattern 0.75 0.905 1.0;
xpattern 0.0 0.18749 1.0;
xpattern 0.75 0.91 1.0;
xpattern 0.0 0.18749 1.0;
xpattern 0.75 0.915 1.0;
xpattern 0.0 0.18749 1.0;
xpattern 0.75 0.92 1.0;
xpattern 0.0 0.18749 1.0;
xpattern 0.75 0.925 1.0;
xpattern 0.0 0.18749 1.0;
xpattern 0.75 0.93 1.0;
xpattern 0.0 0.18749 1.0;
xpattern 0.75 0.935 1.0;
xpattern 0.0 0.18749 1.0;
xpattern 0.75 0.94 1.0;
xpattern 0.0 0.18749 1.0;
xpattern 0.75 0.945 1.0;
xpattern 0.0 0.18749 1.0;
xpattern 0.75 0.95 1.0;
xpattern 0.0 0.18749 1.0;
xpattern 0.75 0.955 1.0;
xpattern 0.0 0.18749 1.0;
xpattern 0.75 0.96 1.0;
xpattern 0.0 0.18749 1.0;
xpattern 0.75 0.965 1.0;
xpattern 0.0 0.18749 1.0;
xpattern 0.75 0.97 1.0;
xpattern 0.0 0.18749 1.0;
xpattern 0.75 0.975 1.0;
xpattern 0.0 0.18749 1.0;
xpattern 0.75 0.98 1.0;
xpattern 0.0 0.18749 1.0;
xpattern 0.75 0.985 1.0;
xpattern 0.0 0.18749 1.0;
xpattern 0.75 0.99 1.0;
xpattern 0.0 0.18749 1.0;
xpattern 0.75 0.995 1.0;
xpattern 0.0 0.18749 1.0;
xpattern 0.75 1.0 1.0;
xpattern 1.0 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