Is the "blue noise" version actually slower than the Bayer? Seems to be
doing a bit less calculation but it reading the array of weights. The
removal of the need for the pattern offset seems like a win.
On Mon, Apr 22, 2019 at 9:27 AM Matt Turner wrote:
> On Fri, Apr 19, 2019 at 4:52 PM Bryce Ha
How difficult is it to just make the gradients use dithering, so they
produce 8-bit (or whatever) results directly but with the dithering pattern
in them?
What other operations would need dithering (a large blur comes to mind,
also zooming way in on an image in bilinear)?
I think the blue noise l
If you are rendering a solid color (so the result is either that color or
transparent black) then you can just fill the entire RGB with that color to
turn the premulitplied output into unpremultiplied.
However I am unsure what your precision problem is. You would have to
composite several dozen mos
Looks like if you can turn off -fsanitize=shift (not clear how you do this)
it would fix it.
It seems like using unsigned rather than int could fix a lot of this, but
it complains about left-shifts of negative numbers (such as (-2)< wrote:
> Hi,
>
> I just run the stress-test with CFLAGS="-fsanit
I don't like the fact that the design which allows the rgba to be different
sizes cannot make them vary between float and decimal. The main reason is
so that an integer for Alpha can be supported. I think maybe there should
be a bit that changes the interpretation of the bit widths to a 16-valued
t
I think an indicator for float can double as indicating the size is
multiplied by 8. All float formats I am familiar with take a mulitple of 8
bits, including an 8-bit format that is sometimes used in CG.
On Mon, Oct 29, 2018 at 2:18 AM Maarten Lankhorst <
maarten.lankho...@linux.intel.com> wrote
Another
possibility that Nuke does, but may be hard to implement here, is to start
at a random position and go left and right from that position. It seems to
hide the artifacts very well.
On Tue, Mar 27, 2018 at 1:13 PM, Marc Jeanmougin wrote:
>
>
> On 03/27/2018 07:45 PM, Bill Spitza
nt. I still think this is the right way to do it.
>
> Thank you for your input. Would it be possible to use your preferred way
> of doing it to my patch ?
>
> Le 27/03/2018 à 03:47, Bill Spitzak a écrit :
> > I don't understand why you would want to disable it when writ
I don't understand why you would want to disable it when writing .png
files. There will be banding in the .png file, which I would think is worse
than the increased size. Also kind of fools the user if they did not look
at the .png file and only at InkScape's display.
On Mon, Mar 26, 2018 at 5:04
Thanks that looks great, glad to see this stuff is finally in there.
I'm disappointed you did not accept the changes to the normalization.
I believe I can prove that the residual error will always be zero,
unless the filter is so large that it would not work anyway (due to
the entries being smalle
On Fri, Apr 29, 2016 at 4:55 AM, Oded Gabbay wrote:
> On Tue, Apr 12, 2016 at 5:36 AM, Søren Sandmann Pedersen
> wrote:
> > This new test tests a bunch of bilinear downscalings, where many have
> > a transformation such that the BILINEAR filter can be reduced to
> > NEAREST (and many don't).
> >
016 at 11:35, Pekka Paalanen wrote:
> > On Fri, 29 Apr 2016 10:15:37 +0100
> > Emil Velikov wrote:
> >
> >> On 27 April 2016 at 18:46, Bill Spitzak wrote:
> >> > On Wed, Apr 27, 2016 at 2:03 AM, Pekka Paalanen
> wrote:
> >> >>
> >&
On Wed, Apr 27, 2016 at 2:03 AM, Pekka Paalanen wrote:
> On Wed, 27 Apr 2016 09:56:44 +0100
> Emil Velikov wrote:
>
> > On 26 April 2016 at 19:12, Bill Spitzak wrote:
> > > The old code is comparing pixman_fixed_48_16_t values to
> > > pixman_fixed_16_16_
The old code is comparing pixman_fixed_48_16_t values to
pixman_fixed_16_16_t values, thus it is checking for truncation of overflow
values.
It would probably be better to clamp these overflowed values, like
pixman_transform_point_31_16 is doing to clamp to the pixman_fixed_48_16
result. Right now
The attached patch changes the normalization to the version I was
suggesting. I added some print statements and discovered that the "residual
error" was always zero, after some analysis I figured out that this version
will always produce a set of values that sum to pixman_fixed_1 (unless the
filter
res filter. subsample=1 produces a quite visible shift that I think is a
good indication the sampling locations will need to be fixed.
On Wed, Apr 13, 2016 at 7:24 AM, Bill Spitzak wrote:
> On 04/12/2016 01:55 PM, Søren Sandmann wrote:
>
> This series is available as a git repository h
On 04/12/2016 01:55 PM, Søren Sandmann wrote:
This series is available as a git repository here:
https://cgit.freedesktop.org/~sandmann/pixman/log/?h=spitzak-for-master
Not having much luck with that url:
fatal: repository
'https://cgit.freedesktop.org/~sandmann/pixman/log/?h=spitzak-for-ma
return 1 for all x). Oded did not like that idea but I wonder if you
have any opinion.
On Mon, Apr 11, 2016 at 7:36 PM, Søren Sandmann Pedersen <
soren.sandm...@gmail.com> wrote:
> From: Bill Spitzak
>
> v11: Restored range checks
>
> Signed-off-by: Bill Spitzak
>
Excellent idea to put the error diffusion into the division. Just a bit of
cleanup and changes for some suspected bugs (that are probably invisible
but might as well get them):
On Mon, Apr 11, 2016 at 7:36 PM, Søren Sandmann Pedersen <
soren.sandm...@gmail.com> wrote:
> There are a few bugs in th
On Tue, Apr 12, 2016 at 1:55 PM, Søren Sandmann
wrote:
>
> 1-wide filters - looks triangular, but a 1-wide box would be more
>>>accurate
>>>
>>
>> Because you are not plotting the two dummy points at (0,±width/2), a
>> 1-wide filter is actually just a single point.
>>
>> You
On Mon, Apr 11, 2016 at 7:36 PM, Søren Sandmann Pedersen <
soren.sandm...@gmail.com> wrote:
> From: Bill Spitzak
>
> If enable-gnuplot is configured, then you can pipe the output of a
> pixman-using program to gnuplot and get a continuously-updated plot of
> the horizont
(t10 + t11) are both
odd. This is a sufficient condition for the resulting transformed
coordinates to be exactly at the center of a pixel so that BILINEAR
becomes identical to NEAREST.
V2: Address some comments by Bill Spitzak
Signed-off-by: Søren Sandmann
---
pixman/pixman-image.c | 66
Reviewed-by: Bill Spitzak
On 04/11/2016 07:36 PM, Søren Sandmann Pedersen wrote:
This new test tests a bunch of bilinear downscalings, where many have
a transformation such that the BILINEAR filter can be reduced to
NEAREST (and many don't).
A CRC32 is computed for all the resulting i
I can confirm this fixes the problem and allows multiple fast path flags
to be set.
Reviewed-by: Bill Spitzak
On 04/11/2016 07:36 PM, Søren Sandmann Pedersen wrote:
When a BILINEAR filter is reduced to NEAREST, it is possible for both
types of fast paths to run; in this case, the NEAREST
On Mon, Apr 11, 2016 at 12:35 PM, Søren Sandmann
wrote:
> On Mon, Apr 11, 2016 at 2:43 PM, Bill Spitzak wrote:
>
>
>> 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
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.
But I very much agree with Owen (and you?) that the current behavior is
incorrect and should be fixed exactly a
On 04/09/2016 01:13 PM, Søren Sandmann wrote:
On Sat, Apr 9, 2016 at 3:45 PM, Bill Spitzak mailto:spit...@gmail.com>> wrote:
On 04/03/2016 11:17 AM, Søren Sandmann wrote:
I don't believe this patch is correct.
As an example, consider an image with
On 04/03/2016 11:17 AM, Søren Sandmann wrote:
I don't believe this patch is correct.
As an example, consider an image with an identity transformation and a
cubic filter (which has width 4) with subsample_bits = 0. The current
code will compute a matrix
[ cubic(-2), cubic(-1), cubic(0), cub
, 2016 at 12:21 PM, Søren Sandmann
wrote:
> No, it changes behavior when the number of *phases* is odd, which it is in
> the example I gave.
>
>
> Søren
>
> On Mon, Apr 4, 2016 at 2:51 PM, Bill Spitzak wrote:
>
>> That's why this only changes the behavior w
ally find it confusing to use the
same term for different numbers.
On Sun, Apr 3, 2016 at 9:29 AM, Søren Sandmann
wrote:
> I guess I can live with 'rscale' (for reciprocal scale).
>
>
> Søren
>
> On Thu, Mar 24, 2016 at 9:30 PM, Bill Spitzak wrote:
>
>> Would
th width 3, but since this would only work with subsample_bits=0, it's
> not worth the special-casing.
>
>
> On Sun, Mar 6, 2016 at 8:06 PM, wrote:
>
>> From: Bill Spitzak
>>
>> The position of only one subsample was wrong as ceil() was done on an
Would using "iscale" (for inverse scale) work? Another is "tscale" because
it is the scale from the transform matrix.
I really would like to use two different names for these variables as it is
really confusing using the same one.
On Fri, Mar 18, 2016 at 8:24 AM, Bill Spitz
On Mon, Mar 21, 2016 at 7:41 PM, Søren Sandmann
wrote:
>
>
> On Mon, Mar 21, 2016 at 12:29 PM, Bill Spitzak wrote:
>
>> On Sun, Mar 20, 2016 at 11:36 PM, Søren Sandmann <
>> soren.sandm...@gmail.com> wrote:
>>
>>> On Sun, Mar 6, 2016 at
On Fri, Mar 18, 2016 at 6:54 PM, Søren Sandmann
wrote:
> On Sun, Mar 6, 2016 at 8:06 PM, wrote:
>
>> From: Bill Spitzak
>>
>> This removes a high-frequency spike in the middle of some filters that is
>> caused by math errors all being in the same direction.
>
On Sun, Mar 20, 2016 at 11:36 PM, Søren Sandmann
wrote:
> On Sun, Mar 6, 2016 at 8:06 PM, wrote:
>
>> From: Bill Spitzak
>>
>> The IMPULSE special-cases did not sample the center of the of the region.
>> This
>> caused it to sample the filters outside th
Looks correct to me, and a really good idea. I noticed this but did not
know how to fix it, so I had to make sure only one optimization flag was
turned on. The ability to turn on multiple ones is a lot better.
On Wed, Mar 16, 2016 at 9:14 PM, Søren Sandmann Pedersen <
soren.sandm...@gmail.com> wro
(t00 + t01) and (t10 + t11) are both
> odd. This is a sufficient condition for the resulting transformed
> coordinates to be exactly at the center of a pixel so that BILINEAR
> becomes identical to NEAREST.
>
> V2: Address some comments by Bill Spitzak
>
> Signed-off-by: Søren Sand
idth. How about "dx" and
"dy" since it is almost always the derivative of the x and y in the input
(or du,dv or dtx dtx)
>
>
> Søren
>
>
> On Sun, Mar 6, 2016 at 8:06 PM, wrote:
>
>> From: Bill Spitzak
>>
>> This is to remove some confu
On Thu, Mar 17, 2016 at 9:48 PM, Søren Sandmann
wrote:
>
> This makes the speed of the demo more accurate, as the filter generation
>> is a visible fraction of the time it takes to do a transform. This also
>> prevents the output of unused filters in the gnuplot option in the next
>> patch.
>>
>>
Looks like a good idea to me. It is unfortunate that if it fails there is
not much indication which image failed but that would require a lot more
checksums.
I would guess the checksums are computed by running this with the fast
paths disabled?
___
Pixma
Seems correct and gets more cases than my code did (I was assuming nobody
would use bilinear for scales less than 1/2 so I did not check for it).
Minor comments:
On Mon, Mar 14, 2016 at 11:19 PM, Søren Sandmann Pedersen <
soren.sandm...@gmail.com> wrote:
> Generalize and simplify the code that re
Great idea to test this.
On Mon, Mar 14, 2016 at 11:24 PM, Søren Sandmann
wrote:
> diff --git a/test/filter-reduction-test.c b/test/filter-reduction-test.c
>
>> new file mode 100644
>> index 000..72b3142
>> --- /dev/null
>> +++ b/test/filter-reduction-test.c
>> @@ -0,0 +1,119 @@
>> +/*
>> +
On Mon, Mar 7, 2016 at 1:15 AM, Pekka Paalanen wrote:
> On Fri, 4 Mar 2016 19:12:36 -0800
> Bill Spitzak wrote:
>
> > On Fri, Mar 4, 2016 at 4:17 PM, Søren Sandmann >
> > wrote:
> >
> > > On Wed, Feb 10, 2016 at 1:25 AM, wrote:
> > >
> >
I believe on the good/best patch you are worried about the freeing of
the filter array. However in commit 756b54f6 you made pixman_set_filter
always copy the one provided by the caller. This means my code works
because the filter cannot be changed away from/to good/best without also
freeing the
On Fri, Mar 4, 2016 at 4:19 PM, Søren Sandmann
wrote:
> On Wed, Feb 10, 2016 at 1:25 AM, wrote:
>
> From: Bill Spitzak
>>
>> This makes the demo match normal behavior of pixman/cairo at startup.
>>
>
> Defaulting to 'locked' makes sense, but in
On Fri, Mar 4, 2016 at 4:17 PM, Søren Sandmann
wrote:
> On Wed, Feb 10, 2016 at 1:25 AM, wrote:
>
>> From: Bill Spitzak
>>
>> Detects and uses PIXMAN_FILTER_NEAREST for all 8 90-degree rotations and
>> reflections when the scale is 1.0 and integer translation.
>
On Fri, Mar 4, 2016 at 3:49 PM, Søren Sandmann
wrote:
> On Tue, Feb 16, 2016 at 4:45 PM, Bill Spitzak wrote:
>
>> I have a new version of this patch, which fixes a math error that
>> caused it to produce too many samples at small sizes (large scales). I
>> am not clear
On Fri, Mar 4, 2016 at 3:39 PM, Søren Sandmann
wrote:
>
>
> On Wed, Feb 10, 2016 at 1:25 AM, wrote:
>
>> From: Bill Spitzak
>>
>> The SIGMA term drops out on simplification.
>>
>
> But SIGMA has a meaning here: it's the standard deviation for
On Fri, Mar 4, 2016 at 3:12 PM, Søren Sandmann
wrote:
> On Wed, Feb 10, 2016 at 1:25 AM, wrote:
>
>> From: Bill Spitzak
>>
>> The IMPULSE special-cases did not sample the center of the of the region.
>> This caused it to sample the filters outside their range, and
On Fri, Mar 4, 2016 at 3:05 PM, Søren Sandmann
wrote:
> On Wed, Feb 10, 2016 at 1:25 AM, wrote:
>
>> From: Bill Spitzak
>>
>> v11: Restored range checks
>>
>> Signed-off-by: Bill Spitzak
>> Reviewed-by: Oded Gabbay
>>
>
> What's the
On Fri, Mar 4, 2016 at 3:00 PM, Søren Sandmann
wrote:
> On Wed, Feb 10, 2016 at 1:25 AM, wrote:
>
>> From: Bill Spitzak
>>
>> Simpsons uses cubic curve fitting, with 3 samples defining each cubic.
>> This
>> makes the weights of the samples be in a pat
On Fri, Mar 4, 2016 at 2:52 PM, Søren Sandmann
wrote:
>
>
> On Wed, Feb 10, 2016 at 1:25 AM, wrote:
>
>> From: Bill Spitzak
>>
>> Rearranged so that the entire block of memory for the filter pair
>> is allocated first, and then filled in. Previous version
On Fri, Mar 4, 2016 at 2:51 PM, Søren Sandmann
wrote:
> On Wed, Feb 10, 2016 at 1:25 AM, wrote:
>
>> From: Bill Spitzak
>>
>> Rename kernel1/2 to reconstruct/sample to match the other functions.
>> Rename "scale" to "size" to avoid confusion w
On Fri, Mar 4, 2016 at 2:44 PM, Søren Sandmann
wrote:
>
>
> On Wed, Feb 10, 2016 at 1:25 AM, wrote:
>
>> From: Bill Spitzak
>>
>> This makes the speed of the demo more accurate, as the filter generation
>> is a visible fraction of the time it takes to do a
On Fri, Mar 4, 2016 at 2:41 PM, Søren Sandmann
wrote:
> On Wed, Feb 10, 2016 at 1:25 AM, wrote:
>
>> From: Bill Spitzak
>>
>> This allows testing of GOOD/BEST and to do comparisons between
>> the basic filters and PIXMAN_FILTER_SEPARABLE_CONVOLUTION settings.
>
On 02/16/2016 01:58 PM, Oded Gabbay wrote:
On Tue, Feb 16, 2016 at 11:45 PM, Bill Spitzak wrote:
I have a new version of this patch, which fixes a math error that
caused it to produce too many samples at small sizes (large scales). I
am not clear if I can submit a v14 of just this patch or I
I have a new version of this patch, which fixes a math error that
caused it to produce too many samples at small sizes (large scales). I
am not clear if I can submit a v14 of just this patch or I should
instead submit a v14 of the entire patch series.
___
On 02/07/2016 04:57 AM, Oded Gabbay wrote:
On Fri, Feb 5, 2016 at 9:49 AM, wrote:
From: Bill Spitzak
v11: Restored range checks
Signed-off-by: Bill Spitzak
---
pixman/pixman-filter.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/pixman/pixman
On 02/04/2016 02:47 AM, Oded Gabbay wrote:
On Tue, Feb 2, 2016 at 8:28 AM, wrote:
From: Bill Spitzak
If a negative value is used for the subsampling, then -n subsamples are
used at scale==1, and fewer are used at larger scale, more are used at
smaller scale, so that the total number of
On 02/04/2016 05:42 AM, Oded Gabbay wrote:
On Tue, Feb 2, 2016 at 8:28 AM, wrote:
From: Bill Spitzak
Detects and uses PIXMAN_FILTER_NEAREST for all 8 90-degree rotations and
reflections when the scale is 1.0 and integer translation.
GOOD uses:
scale < 1/16 : BOX.BOX at size 16
sc
On 02/04/2016 02:39 AM, Oded Gabbay wrote:
On Tue, Feb 2, 2016 at 8:28 AM, wrote:
From: Bill Spitzak
This replaces settings that don't work (because the filter cannot be normalized)
with something that produces an image.
v7: First version with this. Previously you got lots of st
On 02/04/2016 02:39 AM, Oded Gabbay wrote:
On Tue, Feb 2, 2016 at 8:28 AM, wrote:
From: Bill Spitzak
Due to normalization these filters must all be identical (a single 1.0).
Also make IMPULSE.IMPULSE produce a width=1 filter, rather than zero
(which did not work).
v7: Replaced earlier
On 02/04/2016 02:30 AM, Oded Gabbay wrote:
On Tue, Feb 2, 2016 at 8:28 AM, wrote:
From: Bill Spitzak
The SIGMA term drops out on simplification.
Expanded the size slightly (from ~4.25 to 5) to make the cutoff less noticable.
The filter is truncated at a value of .001 instead of .006, this
Okay, thanks for the info. Will try to fix them all.
On Mon, Feb 1, 2016 at 5:51 AM, Oded Gabbay wrote:
> On Fri, Jan 22, 2016 at 11:41 AM, wrote:
> >
> > From: Bill Spitzak
> >
> > This is much more accurate and less blurry. In particular the filtering
> does
On Mon, Feb 1, 2016 at 6:10 AM, Oded Gabbay wrote:
>
> > -params = pixman_filter_create_separable_convolution (
> > -&n_params,
> > -sx * 65536.0 + 0.5,
> > - sy * 65536.0 + 0.5,
> > - get_value (app, filters, "reconstruct_x_combo_box"),
> > - get_value (app,
On Mon, Feb 1, 2016 at 6:11 AM, Oded Gabbay wrote:
> On Mon, Feb 1, 2016 at 4:10 PM, Oded Gabbay wrote:
> > On Fri, Jan 22, 2016 at 11:42 AM, wrote:
> >> From: Bill Spitzak
> >>
> >> If enable-gnuplot is configured, then you can pipe the output of a
> p
ng each patch.
On Mon, Feb 1, 2016 at 6:34 AM, Oded Gabbay wrote:
> On Fri, Jan 22, 2016 at 11:42 AM, wrote:
> > From: Bill Spitzak
> >
> > Simpsons uses cubic curve fitting, with 3 samples defining each cubic.
> This
> > makes the weights of the samples be in a pa
The ability to disabling everything except the library itself seems like a
good idea.
Make sure "make test" fails if tests are disabled.
I do think it would be nice to actually patch the tests so they compile on
these platforms.
On Wed, Jan 20, 2016 at 1:13 AM, Thomas Petazzoni <
thomas.petazz..
gt; On Fri, Jan 8, 2016 at 8:53 PM, Bill Spitzak wrote:
> >
> >
> > On Thu, Jan 7, 2016 at 11:44 PM, Pekka Paalanen
> wrote:
> >>
> >>
> >> Please keep in mind that the filters GOOD and BEST have been as is for
> >> a long long time, AFAIU,
On Thu, Jan 7, 2016 at 11:44 PM, Pekka Paalanen wrote:
>
> Please keep in mind that the filters GOOD and BEST have been as is for
> a long long time, AFAIU, so changing their behaviour now is likely not
> a good idea. They are no longer "a good filter" and "whatever best
> filter", but "the speci
On Mon, Jan 4, 2016 at 1:24 AM, Oded Gabbay wrote:
> On Mon, Jan 4, 2016 at 5:12 AM, wrote:
> > From: Bill Spitzak
> >
> > This allows testing of GOOD/BEST and to do comparisons between
> > the basic filters and PIXMAN_FILTER_SEPARABLE_CONVOLUTION settings.
>
>
On Mon, Jan 4, 2016 at 3:25 AM, Oded Gabbay wrote:
> On Mon, Jan 4, 2016 at 5:12 AM, wrote:
> > From: Bill Spitzak
> >
> > If GNUPLOT_OUTPUT is set, then you can pipe the output of a pixman-using
> program
> > to gnuplot and get a continuously-updated plot of
Indeed, further tests reveal there was a bug if one of the filters is
IMPULSE. It was not sampling at the center of the filter, but instead
offset by the width. I have a patch to fix this that will be in the next
set.
On 12/26/2015 08:05 PM, Bill Spitzak wrote:
Sounds like I better look at
Sounds like I better look at this more carefully, it is quite possible it
is producing bad filters but with small enough error that the images look
OK.
On Dec 23, 2015 5:25 AM, "Oded Gabbay" wrote:
> On Tue, Dec 22, 2015 at 9:01 PM, Bill Spitzak wrote:
> >
> >
> &g
I think the improvement is obvious if you check how much code is run to do
the Simpson's integration. BOX.BOX will literally be the filter used almost
always once this is finally fixed.
On Tue, Dec 22, 2015 at 12:08 PM, Oded Gabbay wrote:
> On Tue, Dec 22, 2015 at 9:44 PM, Bill Spitza
15 at 12:12 PM, Oded Gabbay wrote:
> On Tue, Dec 22, 2015 at 9:25 PM, Bill Spitzak wrote:
> >
> >
> > On Tue, Dec 22, 2015 at 2:32 AM, Oded Gabbay
> wrote:
> >>
> >> On Sat, Dec 12, 2015 at 8:06 PM, wrote:
> >> > From: Bill Spitzak
> &
1:33 AM, Oded Gabbay wrote:
> On Sat, Dec 12, 2015 at 8:06 PM, wrote:
> > From: Bill Spitzak
> >
> > This is easy as the caller already intersected the two boxes, so
> > the width is the integral.
> > ---
> > pixman/pixman-filter.c | 5 +
> > 1
On Tue, Dec 22, 2015 at 1:38 AM, Oded Gabbay wrote:
> On Sat, Dec 12, 2015 at 8:06 PM, wrote:
> > From: Bill Spitzak
> >
> > Only LINEAR is not differentiable at zero,
>
> I'm sorry, I don't understand this sentence. Could you please give me
> a more d
On Tue, Dec 22, 2015 at 2:32 AM, Oded Gabbay wrote:
> On Sat, Dec 12, 2015 at 8:06 PM, wrote:
> > From: Bill Spitzak
> >
> > The other filters don't range-check, so there is no need for this
> > one to either. It is only called with x==0.
>
> Actually, I
of 1.0.
On Tue, Dec 22, 2015 at 2:41 AM, Oded Gabbay wrote:
> On Sat, Dec 12, 2015 at 8:06 PM, wrote:
> > From: Bill Spitzak
> >
> > Any error in filter normalization is placed on the center of odd-sized
> filters,
> > rather than 1 pixel to the right.
> >
On Tue, Dec 22, 2015 at 4:21 AM, Oded Gabbay wrote:
> On Sat, Dec 12, 2015 at 8:06 PM, wrote:
> > From: Bill Spitzak
> >
> > With the other patch to put error on the center pixel, this produces
> > the same result as BOX.IMPULSE filter.
> > ---
> > pi
On Tue, Dec 22, 2015 at 4:38 AM, Oded Gabbay wrote:
> On Sat, Dec 12, 2015 at 8:06 PM, wrote:
> > From: Bill Spitzak
> >
> > The other filters do not check for x being in range, so there is
> > no reason for cubic to do so.
>
> This argument is a bit proble
On Tue, Dec 22, 2015 at 4:44 AM, Oded Gabbay wrote:
> On Sat, Dec 12, 2015 at 8:06 PM, wrote:
> > From: Bill Spitzak
> >
> > If sample is IMPULSE and reconstruct is BOX or IMPULSE the sub-pixel
> > position of the sample is not relevant, so only one subsample is n
, Dec 20, 2015 at 5:58 AM, Oded Gabbay wrote:
> On Wed, Dec 16, 2015 at 4:41 AM, Bill Spitzak wrote:
> >
> >
> > On Tue, Dec 15, 2015 at 1:29 AM, Oded Gabbay
> wrote:
> >>
> >> On Sat, Dec 12, 2015 at 9:10 PM, Bill Spitzak
> wrote:
> >> >
&g
PM, wrote:
> > From: Bill Spitzak
> >
> > With the cubic fix this is plenty accurate enough, far in excess of the
> pixman
> > fixed-point error limit. Likely even 16 samples is too many.
> > ---
> > pixman/pixman-filter.c | 2 +-
> > 1 file changed, 1
Best one I think:
http://www.intmath.com/integration/6-simpsons-rule.php
On Thu, Dec 17, 2015 at 1:50 PM, Bill Spitzak wrote:
> This was based on looking up Simpson's integration on the web, from the
> wikipedia page and another page I found.
>
> It cuts the samples into s
mples to 3.
On Thu, Dec 17, 2015 at 10:21 AM, Oded Gabbay wrote:
> On Thu, Dec 17, 2015 at 8:20 PM, Oded Gabbay
> wrote:
> > On Sat, Dec 12, 2015 at 8:06 PM, wrote:
> >> From: Bill Spitzak
> >>
> >> Simpsons uses cubic curve fitting, with 3 samples defini
(5) and add:
x^2+y^2 = (a^2+c^2)/u^2
But x^2+y^2 is 1:
1 = (a^2+c^2)/u^2
u^2 = a^2+c^2
u = hypot(a,c)
Similarily the max/min of v is at:
v = hypot(b,d)
On Thu, Dec 17, 2015 at 1:52 AM, Oded Gabbay wrote:
> On Sat, Dec 12, 2015 at 8:06 PM, wrote:
> > From: Bil
On Tue, Dec 15, 2015 at 1:29 AM, Oded Gabbay wrote:
> On Sat, Dec 12, 2015 at 9:10 PM, Bill Spitzak wrote:
> >
> >
> > On Sat, Dec 12, 2015 at 10:37 AM, Oded Gabbay
> wrote:
> >>
> >> On Sat, Dec 12, 2015 at 8:34 PM, Bill Spitzak
> wrote:
> &
On Sat, Dec 12, 2015 at 10:37 AM, Oded Gabbay wrote:
> On Sat, Dec 12, 2015 at 8:34 PM, Bill Spitzak wrote:
> > On Fri, Dec 11, 2015 at 4:15 AM, Oded Gabbay
> wrote:
> >>
> >> On Thu, Dec 10, 2015 at 11:19 PM, Bill Spitzak
> wrote:
> >> > Can you
On Fri, Dec 11, 2015 at 4:15 AM, Oded Gabbay wrote:
> On Thu, Dec 10, 2015 at 11:19 PM, Bill Spitzak wrote:
> > Can you include my patches to fix the filtering? They have been posted
> for a
> > long time now.
> >
> > The last patch makes GOOD/BEST use filtering f
Can you include my patches to fix the filtering? They have been posted for
a long time now.
The last patch makes GOOD/BEST use filtering for scaling images down. This
matches the current Cairo behavior and would allow Cairo to use the pixman
backend rather than doing an image fallback for any imag
On Mon, Sep 21, 2015 at 10:07 PM, Søren Sandmann
wrote:
> Sure. The extra width check can't harm.
>
Actually it can, because it implies that such values *can* arrive at this
function, leading programmers to add tests to the calling functions, thus
leading to a large number of tests for condition
On Wed, Sep 16, 2015 at 7:30 AM, Ben Avison wrote:
Just by thinking things through, I realised that we would regularly fail
> to hit COVER paths if Pixman's caller set the scale factors such that the
> centre of the outermost destination pixels aligned with the centre of the
> outermost source pi
On Mon, Sep 14, 2015 at 11:52 AM, Søren Sandmann
wrote:
>
> A separate possibility is a flag that says "all pixels whose weights are
> non-zero are inside the borders of the source image". Is this useful
> information? It might be, and if so, it could be conveyed through some
> new flag, though I
On Thu, Sep 10, 2015 at 9:35 AM, Ben Avison wrote:
> On Thu, 10 Sep 2015 12:46:50 +0100, Pekka Paalanen
> wrote:
>
>> you're right, documenting this is important. However, I think this
>> particular patch is not the best place, and here is why.
>>
>> When we recently discussed this, both I and S
On Thu, Aug 20, 2015 at 6:58 AM, Pekka Paalanen wrote:
> A thing that explains a great deal of these anomalies, but not all of it,
> has
> something to do with function addresses. There are hypotheses that it might
> have to do with the branch predictor and its cache. We made a test
> targeting
Can't this just assume/require b to be positive? That would make them a lot
simpler:
#define DIV(a,b) ((a) / (b) - ((a) % (b) < 0 ? (b) : 0))
#define MOD(a,b) ((a) % (b) + ((a) % (b) < 0 ? (b) : 0))
On Fri, Aug 14, 2015 at 7:06 AM, Ben Avison wrote:
> The previous implementations of DIV and
On 06/03/2015 12:36 AM, Pekka Paalanen wrote:
On Tue, 2 Jun 2015 15:03:01 -0700
Bill Spitzak wrote:
I would have the first call return 0.0 and all the others return the
difference between current time and when that first call was done. Then
there is no worry about accuracy of floating point
I would have the first call return 0.0 and all the others return the
difference between current time and when that first call was done. Then
there is no worry about accuracy of floating point. I do not think any
callers are interested in the absolute time, only in subtracting two
results to get an
1 - 100 of 281 matches
Mail list logo
