Hi Robert,<div><br class="webkit-block-placeholder"></div><div>As far as I can tell your method is matching the density of a 10% large dot with</div><div>say a 20% small dot. But in a real print the transition from small dot to large</div>
<div>dot happens at a much higher percentage -- say 100% small to 50% large.</div><div>So while it would seem that mathematically its the same thing, the non-linearity</div><div>of dot gain makes a difference. Small dots have more relative dot gain than</div>
<div>larger dots because the circumference to area ratio is larger. I suspect this is</div><div>a least one factor causing your "larger" small dots.</div><div><br class="webkit-block-placeholder"></div><div>I think you can use the same idea but make the constant strip 100% small dot and</div>
<div>the gradient strip the large dot. This is basically what I measure. I like</div><div>your idea about making the different ranges for each dot size, I may have</div><div>to try something similar. (I've been using an environment variable to force</div>
<div>single dots but this requires 3 print jobs not 1).</div><div><br class="webkit-block-placeholder"></div><div>Roy<br><br><div class="gmail_quote">On Jan 27, 2008 4:31 PM, Robert Krawitz <<a href="mailto:rlk@alum.mit.edu">rlk@alum.mit.edu</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">I'm experimenting with another approach to drop size calibration.<br>This uses the new segmented dither algorithm to print stripes using<br>
different drop sizes.<br><br>The exact technique I use is to interleave fixed 10% stripes of a<br>larger drop size with variable stripes (0-100%) of a smaller drop<br>size. I then look for where there's no visible banding; that spot<br>
should indicate where equal amounts of ink are being printed with both<br>drop sizes. For example, if there is no banding at 20%, that means<br>2 small drops are equivalent to 1 large drop.<br><br>The only problem I'm having is that this method is yielding very<br>
different results on the RX580 from what I've already tuned, and my<br>tunings agree with Roy Harrington's. I've tried with 5% instead of<br>10%, and get essentially the same results.<br><br>Using this method, I've derived ratios of approximately 0.33:0.43:1.00<br>
for the smallest set of drops on the RX580, but the ratios currently<br>in use are 0.23:0.37:1.00. For the large drops, I'm getting ratios of<br>0.17:0.47:1.0 (vs. 0.071:0.30:1.0 that we're currently using). The<br>
ratio between the small and medium drops in the large set should be<br>very close to the ratio between the small and large drops in the large<br>set, but the eyeball approach isn't quite giving that result (it's off<br>
by about 10%). I'm also seeing slightly different results for cyan<br>vs. black (by maybe 5%), but that's likely to be within margin of<br>error for the printer.<br><br>Right now I don't know why this is happening, or what it means. In<br>
any case, this is the testpattern config file that I'm using for this<br>(you'll need the most recent CVS update for all of this to work<br>correctly). Perhaps I'll try these drop sizes and see what happens.<br>
<br>printer "escp2-rx580";<br>hsize 1.0;<br>vsize 0.2;<br>left 0.0;<br>top 0.0;<br>mode gray 16;<br>steps 100;<br>blackline 0;<br>parameter "DitherAlgorithm" "Segmented";<br>parameter "ColorCorrection" "Raw";<br>
parameter "Resolution" "1440x1440ov";<br>parameter "PrintingMode" "BW";<br>...<br><br>--<br>Robert Krawitz <<a href="mailto:rlk@alum.mit.edu">rlk@alum.mit.edu</a>><br>
<br>Tall Clubs International -- <a href="http://www.tall.org/" target="_blank">http://www.tall.org/</a> or 1-888-IM-TALL-2<br>Member of the League for Programming Freedom -- mail <a href="mailto:lpf@uunet.uu.net">lpf@uunet.uu.net</a><br>
Project lead for Gutenprint -- <a href="http://gimp-print.sourceforge.net" target="_blank">http://gimp-print.sourceforge.net</a><br><br>"Linux doesn't dictate how I work, I dictate how Linux works."<br>
--Eric Crampton<br></blockquote></div><br></div>