<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 4, 2016 at 3:12 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"><span class="">On Wed, Feb 10, 2016 at 1:25 AM, <span dir="ltr"><<a href="mailto:spitzak@gmail.com" target="_blank">spitzak@gmail.com</a>></span> wrote:<br></span><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">From: Bill Spitzak <<a href="mailto:spitzak@gmail.com" target="_blank">spitzak@gmail.com</a>><br>
<br>
The IMPULSE special-cases did not sample the center of the of the region.<br>
This caused it to sample the filters outside their range, and produce<br>
assymetric filters and other errors. Fixing this required changing the<br>
arguments to integral() so the correct point could be determined.<br>
<br>
I fixed the nice filter and the integration to directly produce normalized<br>
values. Re-normalization is still needed for impulse.box or impulse.triangle<br>
so I did not remove it.<br>
<br>
Distribute fixed error over all filter samples, to remove a high-frequency<br>
bit of noise in the center of some filters (lancoz at large scale value).<br>
<br>
box.box, which I expect will be very common as it is the proposed "good" filter,<br>
was made a lot faster and more accurate. This is easy as the caller already<br>
intersected the two boxes, so the width is the integral.<br>
<br>
v7: This is a merge of 4 patches and lots of new code cleanup and fixes<br>
determined by examining the gnuplot output<br></blockquote><div><br></div></span><div>Please split this back out into separate patches that each fix one problem:<br><br></div><div>- Fixing IMPULSE special cases<br></div><div>- Distributing errors evenly<br></div>- BOX.BOX speedups<br><div><br></div><div>There are several of these changes I'm not convinced about, and they are hard to review as one big patch.<br></div></div></div></div></blockquote><div><br></div><div>I will try to split them up. This is the unfortunate result of trying to rebase them together, I merged because of conflicts. As you don't like the argument renaming I might as well fix all of these at the same time.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div>diff --git a/pixman/pixman-filter.c b/pixman/pixman-filter.c<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
index 8b8fb82..e82871f 100644<br>
--- a/pixman/pixman-filter.c<br>
+++ b/pixman/pixman-filter.c<br>
@@ -79,7 +79,7 @@ sinc (double x)<br>
}<br>
<br>
static double<br>
-lanczos (double x, int n)<br>
+lanczos (double x, double n)<br>
{<br>
return sinc (x) * sinc (x * (1.0 / n));<br>
}<br></blockquote><div><br></div></span><div>What is the point of this change? I don't think Lanczos makes sense with a non-integral number of lobes.<br></div></div></div></div></blockquote><div><br></div><div>It removes the int->float cast, but I think this was mostly accidental. Inline would probably remove the cast as well, and the division too.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
@@ -99,7 +99,7 @@ lanczos3_kernel (double x)<br>
static double<br>
nice_kernel (double x)<br>
{<br>
- return lanczos3_kernel (x * 0.75);<br>
+ return lanczos3_kernel (x * 0.75) * 0.75;<br>
}<br></blockquote><div><br></div></span><div>I don't think this makes sense given that normalization is happening later anyway.</div></div></div></div></blockquote><div><br></div><div>It is the only non-normalized one, and fixing this was very useful for finding out whether bugs were in the normalization or in the filter generators. Also it is plausable that future ones may be able to remove the normalization, though I could not because of the box and triangle being so non-continuous that they needed it.</div><div><br></div></div></div></div>