<div dir="ltr"><div>Okay the actual bug is that the gnuplot output is wrong for subsample_bits==0. It apparently is correct for other values of subsampling. I will try to get an updated version posted soon.</div><div><br></div><div>But I very much agree with Owen (and you?) that the current behavior is incorrect and should be fixed exactly as stated. The current version produces different images from fallbacks to impulse, bilinear, or integer-sized box filters, when the filter math says the fallback should produce an identical result. Scaling down by an integer produces a slightly blurry and offset result, when a perfect result could be achieved at the same speed. Increasing the subsamples moves the existing samples, thus may increase artifacts, rather than always reducing them. All of this is not a good situation.</div><div><br></div><div>I feel this can be fixed. It is already correct for subsample_bits==0. Since both the filter generator and filtering code would be changed in the same version, only programs that generate their own filters would actually be incompatible. And as you point out the error is very tiny for large numbers of subsamples, and Cairo is already using an excessively large number of subsamples (likely because I was trying to remove the difference between identity filters and nearest filtering, and did not realize this was the underlying problem).</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Apr 10, 2016 at 10:01 PM, Søren Sandmann <span dir="ltr"><<a href="mailto:soren.sandmann@gmail.com" target="_blank">soren.sandmann@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
It does look like there is something really wrong. I compared and (except for the subsample_bits==0 case) my version produces the same output as the current git head.<br>
<br>
I think your intention is that there is a sample at offset=0 whether the filter width is even or odd. However (except when subsample_bits==0) the filter generator makes a symmetric filter for even sizes, with two equal samples around the maximum center value. If a sample was at offset==0 then it would be unique and larger than all the other samples.<br></blockquote><div><br></div></span><div>The root of this confusion is probably that when subsample_bits = k, the subpixel positions used are:<br><br></div><div>    0.5 / 2^k, 1.5 / 2^k, ..., (2^k-0.5)/2^k</div><div><br></div><div>For example, for subsample_bits = 2:<br><br>    0.125, 0.375, 0.625, 0.875<br></div><div><br></div><div>and for subsample_bits = 0:<br><br>    0.5<br></div><div><br></div><div>That is, they are regularly spaced, but centered within the pixel. When there is an even number of them, this means there will not be a filter position at 0.5, and therefore no sample at offset 0. And the only case where number of subpixel locations is odd, is when subsample_bits = 0.<br><br>I'm pretty sure that the existing code gets the filter generation right for these subpixel positions.<br><br><br>[ You can argue that it would be better to use the sampling positions<br><br>    0, 0.25, 0.5, 0.75<br></div></div><div class="gmail_quote"><br></div><div class="gmail_quote">for subsample_bits = 2, as Owen did here:<br><br>    <a href="https://lists.cairographics.org/archives/cairo/2014-March/025105.html" target="_blank">https://lists.cairographics.org/archives/cairo/2014-March/025105.html</a><br><br></div><div class="gmail_quote">and I agree that that would have been better. ]<span class="HOEnZb"><font color="#888888"><br> <br></font></span></div><span class="HOEnZb"><font color="#888888"><div class="gmail_quote"><br></div><div class="gmail_quote">Søren<br></div></font></span></div></div>
</blockquote></div><br></div>