Cairo currently does only bilinear interpolation.
This is wrong for any scale less than 1, although the artifacts do not
really appear until a scale less that .5. Bilinear cannot use more than
4 adjacent pixels in a square to produce an output pixel, and if you
scale small enough the
Krzysztof Kosiński wrote:
2010/8/16 Bill Spitzak spit...@gmail.com:
The problem I am having is that this does not match how filtering of
transforms is done in any image processing software I am familiar with.
This is how all software I am familiar with works, this replaces the three
steps
On 08/17/2010 01:01 AM, Soeren Sandmann wrote:
Bill Spitzakspit...@gmail.com writes:
I'm not sure what's
the difference in quality between those approaches. I could try
prototyping both of them.
I suspect there is going to be a phasing problem with your approach if
the scale is
This appears to be for floating point pixels.
Is there work on floating point *coordinates*, which I think is
probably a lot more useful!
On Sep 21, 2010, at 5:42 AM, Dmitri Vorobiev wrote:
On Tue, Sep 21, 2010 at 3:17 PM, Dmitri Vorobiev
dmitri.vorob...@movial.com wrote:
Recently, there
Another thing to think about with floating point pixels is to perhaps do
math in *linear* floating point. This is values where multiplying by N
makes it N times brighter, no matter what the color.
This requires gamma correction when converting the output to the screen.
If the screen takes
On Sep 21, 2010, at 9:04 PM, Siarhei Siamashka wrote:
But now returning back to this issue. Ideally, PAD repeat would be a
better
default instead of NONE. Just because NONE repeat is a bit strange and
hard to accelerate in hardware. This is one example from
freedesktop.org
bugzilla (and
If you are using lookup tables to convert floating point to integers, I
have found that you can use the lower bits to linearly interpolate a
much smaller number of entries.
You can also eliminate all the negative numbers and all numbers greater
than 1 and all NAN, making the table 1/4 size.
It sounds to me like you are proposing that a binary zero-or-source
decision be made for each pixel in the output space. I don't think this
will work.
The pixel sampling of the source needs to do this, otherwise filtering
cannot be used to produce an antialiased edge where the image
Siarhei Siamashka wrote:
Anyway, right now I'm actually working on a similar function
specifically for
bilinear scaling, which would detect 5 zones:
Actually it appears it would be very helpful if None instead produced
an image identical to using repeat or mirror of the edges, but with the
Soeren Sandmann wrote:
(1) The equation would be
(src OP dst) LERP_mask dst
and not
(src IN mask) OP dst
(2) The RGB channels of Alpha-only images would be considered to be
the same as the alpha channel, and not 0 as they are now. For
example, a 0xb9 pixel in
Siarhei Siamashka wrote:
On Friday 11 February 2011 12:30:33 Soeren Sandmann wrote:
If I had a time machine, I would go back and make - among others -
these two changes to Render:
[...]
(2) The RGB channels of Alpha-only images would be considered to be
the same as the alpha channel,
Soeren Sandmann wrote:
Siarhei Siamashka siarhei.siamas...@gmail.com writes:
The pipeline as it is now:
1 convert image sample to a8r8g8b8
2 extend sample grid in all directions according to repeat
3 interpolate between sample according to filter
4 transform
5 resample
6
If I understand this right, I also think the simple test is all that
is needed. The only interesting matrixes are 1:1 scale with integer
translations. There are exactly eight arrangements of the upper-left
corner: with ±1 in location 0,0 and 1,1, and with ±1 in locations 0,1
and 1,0. I think
Box/sync filtering does NOT require the transform to be axis-aligned.
The ideal/slow solution is this:
- The inverse transform is used to map the *corners* of the output pixel
back to the input image space. This defines a quadrilateral in the input
image. If perspective transforms are not
Another way to do this that might be shorter is to compute the matrix
that transforms the 0,0,1,1 square to an arbitrary quad, which I will
call T(quad). Then the full transform is T(dest)*inverse(t(source))
Søren Sandmann wrote:
From: Søren Sandmann Pedersen s...@redhat.com
This program can
Søren Sandmann wrote:
Søren Sandmann sandm...@cs.au.dk writes:
Given a pixel with only the red component of these values, the results
are off-by-one.
0x03 - 0x19 (0x18)
0x07 - 0x3A (0x39)
0x18 - 0xC5 (0xC6)
0x1C - 0xE6 (0xE7)
(Same for blue, and green has many more cases)
It uses
R8 = (
Also this original one:
R8 = ( R5 * 527 + 23 ) 6;
produces the same results as the floor(i*255/31.0+.5) result.
I believe almost *all* graphics software will do the bit-shifting math
and thus the (i*33)2 result is the one to use.
Bill Spitzak wrote:
Søren Sandmann wrote:
Søren
A problem with sRGB for line art is that drawing an inverted drawing
will not look correct to users. White lines and text will look much too
thin, while black lines and text look thicker. This appears to be
because humans invert images in perceptual space. It is possible this
could be
Søren Sandmann wrote:
OpenGL has two extensions that deal with sRGB [1, 2]. One adds a new
texture format, which has 8 bits per component and where the texture
sampler is supposed to raise the R, G, and B (but not A) components to
2.2 before filtering. The other allows framebuffers to marked
On 06/16/2012 07:08 AM, Siarhei Siamashka wrote:
An alternative idea is instead of changing the algorithm across the
board, we could stop requiring bit exact results. The main piece of work
here is to change the test suite so that it will accept pixels up to
some maximum relative error. There
On 08/25/2012 06:45 PM, Søren Sandmann Pedersen wrote:
Also note that the linear-sRGB scanline store routine is probably
slower with these patches because it now uses a binary search instead
of a simple table lookup. If someone has better suggestions here, I'm
definitely interested.
I would
people to do it that way, I apologize for that. The
approach advocated by Bill Spitzak in the various downsampling threads
of computing a convolution kernel up front, is the much better way to
go. To make up for being misleading, the following patches implement
comprehensive support for high-quality
Adrian Johnson wrote:
On 24/11/12 14:27, Søren Sandmann wrote:
-=- Adding support to cairo and further work
Once these patches have landed in Pixman, support will have to be
added to cairo to make use of them. How to do that exactly requires
figuring out what new API to offer, and how the
Siarhei Siamashka wrote:
Bilinear scaling uses weighted average of 2 pixels (in one direction),
with weights calculated on the go. Separable convolution uses weighted
average of N pixels, with weights obtained by table lookups. Both use
subpixel positions (7 phase bits or 128 phases for current
If these are individual glyphs I think you are going to have a problem
if any glyphs extend outside the box defined by their escapement. Either
these pixels will get clipped off, or portions of neighboring glyphs
will get erased.
So I think you have to composite glyphs at some point as though
Siarhei Siamashka wrote:
Going forward, we need to also add support for separable bilinear
scaling (first horizontal interpolation for single scanlines to
temporary buffers in L1 cache, then vertical interpolation of these
buffers to get the final result). Unless I misunderstood something,
Søren Sandmann wrote:
However, unless using 16 bpp for the internal buffers is really a
performance win, there doesn't seem to be any benefits to doing it this
way over just dithering the final image. And I definitely want to see
convincing numbers before believing that 16 bpp for internal
Søren Sandmann wrote:
Here is another proposal, but I'm not sure it's really better:
- The combiners are made to return a buffer. The returned buffer is
expected to contain the combined result and may be any of the passed
src/mask/dest buffers. Almost all combiners will continue to combine
Søren Sandmann wrote:
Consider a DISJOINT_ATOP operation with the following pixels:
- source: 0xff (8 bits)
- source alpha: 0x01 (8 bits)
- mask alpha: 0x7b (8 bits)
- dest: 0x00 (8 bits)
- dest alpha: 0xff (8 bits)
When (src IN mask) is computed in 8 bits, the resulting
This patch is for Cairo but I now feel the correct solution is to place
this in pixman (and thus into XRender). Although the patch is for Cairo
it primarily consists of a replacement for pixman_generate_separable_filter
and changes to how it is called for the GOOD and BEST settings. I could
try to
On 06/23/2014 08:05 PM, Krzysztof Kosiński wrote:
This looks way better and more comprehensive than my attempts at
fixing the downscaling problem. I would support getting this into
trunk, preferably along with the rest of your patches, before the 1.14
release.
I am also looking into the
New filter generation code that produces useful filters at all settings.
Added TENT filter and slightly changes some others.
Unfortunately I have not yet implemented the PIXMAN_FILTER_GOOD/BEST automatic
usage of this. That will be in a further patch that I hope to send soon. For
now you can
Added TENT filter.
Renamed other values to match what they are now producing.
Add back-compatibility #define for old names.
---
demos/scale.c |7 ---
pixman/pixman-filter.c | 41 +
pixman/pixman.h| 14 ++
3 files
On 07/25/2014 12:35 PM, Bryce Harrington wrote:
Like discussed on the v5 review, we don't expect this to be the final
version of this work (ideally the filters should move to pixman), but
will carry this in cairo for the time being so folks have a fix
available and so we can get more widespread
GOOD uses the BOX filter, and uses BILINEAR for all scales 1/1.35.
BEST uses CATMULL_ROM and fiddles with the filter scale so that it
produces square pixels at large zoom in, but normal filtering between
1 and 2.
---
pixman/pixman-image.c | 267 +++--
Uses filter evaluators that know the size of a pixel, and thus can
integrate with reconstruction filters directly. This is much faster
and easier to control. Most of them sample the filter in the center
of the pixel unless the size is less than one, in which case they
numerically integrate 2^n
This is much more accurate and less blurry. In particular the filtering does
not change as the image is rotated.
---
demos/scale.c | 43 ++-
1 file changed, 2 insertions(+), 41 deletions(-)
diff --git a/demos/scale.c b/demos/scale.c
index
Added TENT filter.
Renamed other values to match what they are now producing.
Add back-compatibility #define for old names.
---
demos/scale.c |7 ---
pixman/pixman-filter.c | 41 +
pixman/pixman.h| 14 ++
3 files
Added TENT filter.
Renamed IMPULSE to NEAREST as this is the term used elsewhere
Renamed other values to match what they are now producing.
Add back-compatibility #define for old names.
---
demos/scale.c |9 +
pixman/pixman-filter.c | 51
Changes from previous version of these patches:
- Renamed PIXMAN_KERNEL_IMPULSE to NEAREST to match PIXMAN_FILTER_NEAREST
- Use NEAREST for mirror reflections if possible
- Code cleanup to reduce diff and to use pixman coding standards
___
Pixman
On 08/10/2014 12:51 PM, Søren Sandmann wrote:
Hi,
The first patch in this series, which changes the choice of scale for so
that it is based on the bounding box of a transformed ellipse, rather
than a transformed square makes sense to me. As you say, this makes the
filter more invariant under
Actually. as long as you can also specify the filter width, there is no
need for a filter that matches BILINEAR, because linear at size = 1 will
match. So I think I can clean up this patch to remove the differences in
the set of filters from the older one.
This is still a problem for
This is much more accurate and less blurry. In particular the filtering does
not change as the image is rotated.
---
demos/scale.c | 43 ++-
1 file changed, 2 insertions(+), 41 deletions(-)
diff --git a/demos/scale.c b/demos/scale.c
index
GOOD uses the BOX filter, and uses BILINEAR for all scales 1/1.35.
BEST uses the LANCZOS2 filter. The size is chosen to produce normal
filtering up to a scale of 2, and square pixels with only slight
blurry borders beyond that. I think it looks really nice.
Uses NEAREST instead of BILINEAR,
This patch differs from the previous one in the following ways, to
try to address Soren's comments:
The filter names and selection are not changed. I did narrow GAUSSIAN to the
normal cutoff software I am familiar with uses.
More comments to attempt to explain the removal of reconstruction
I do not know enough about pixman to figure out how to add this yet, but
this is the idea and math:
Proposed 2-pass perspective-capable transform for pixman:
Overview:
The first pass moves the pixels vertically so they are all in the
correct vertical postion, producing an intermediate image.
Samples are multiplied in a 1,4,2,4,2,4,1 pattern, previous version
did 1,2,4,4,4,2,1.
I also reduced the number of samples greatly as there is no
numerical difference with the filter functions.
---
pixman/pixman-filter.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
This is much more accurate and less blurry. In particular the filtering does
not change as the image is rotated.
---
demos/scale.c | 43 ++-
1 file changed, 2 insertions(+), 41 deletions(-)
diff --git a/demos/scale.c b/demos/scale.c
index
---
pixman/pixman-filter.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/pixman/pixman-filter.c b/pixman/pixman-filter.c
index 3a73f9b..9860f7f 100644
--- a/pixman/pixman-filter.c
+++ b/pixman/pixman-filter.c
@@ -318,11 +318,13 @@
Removed the use of scale as 1/scale in integral().
---
pixman/pixman-filter.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/pixman/pixman-filter.c b/pixman/pixman-filter.c
index 15ea270..d26a549 100644
--- a/pixman/pixman-filter.c
+++ b/pixman/pixman-filter.c
@@
The subsampling can be ignored as all the filters are identical.
Code trying to duplicate PIXMAN_FILTER_NEAREST may generate this, so
it may pay off to have this optimization.
---
pixman/pixman-filter.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/pixman/pixman-filter.c
GOOD uses the BOX filter, and uses BILINEAR for all scales 1/1.35.
BEST uses the LANCZOS2 filter. The size is chosen to produce normal
filtering up to a scale of 2, and square pixels with only slight
blurry borders beyond that. I think it looks really nice.
Uses NEAREST instead of BILINEAR,
---
pixman/pixman-filter.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/pixman/pixman-filter.c b/pixman/pixman-filter.c
index 4ff02ec..15ea270 100644
--- a/pixman/pixman-filter.c
+++ b/pixman/pixman-filter.c
@@ -299,7 +299,7 @@ create_1d_filter (int *width,
PM, Bill Spitzak wrote:
Samples are multiplied in a 1,4,2,4,2,4,1 pattern, previous version
did 1,2,4,4,4,2,1.
I also reduced the number of samples greatly as there is no
numerical difference with the filter functions.
___
Pixman mailing list
Pixman
This is much more accurate and less blurry. In particular the filtering does
not change as the image is rotated.
---
demos/scale.c | 43 ++-
1 file changed, 2 insertions(+), 41 deletions(-)
diff --git a/demos/scale.c b/demos/scale.c
index
This is easy as the caller already intersected the two boxes.
---
pixman/pixman-filter.c | 25 +++--
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/pixman/pixman-filter.c b/pixman/pixman-filter.c
index 816d085..15ea270 100644
--- a/pixman/pixman-filter.c
+++
---
pixman/pixman-filter.c | 59
1 file changed, 25 insertions(+), 34 deletions(-)
diff --git a/pixman/pixman-filter.c b/pixman/pixman-filter.c
index 220496e..b656923 100644
--- a/pixman/pixman-filter.c
+++ b/pixman/pixman-filter.c
@@ -225,25
---
pixman/pixman-filter.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/pixman/pixman-filter.c b/pixman/pixman-filter.c
index b656923..78ea72d 100644
--- a/pixman/pixman-filter.c
+++ b/pixman/pixman-filter.c
@@ -323,11 +323,13 @@
Also made impulse filter not range check. All the other filters do
not test for x in range.
---
pixman/pixman-filter.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/pixman/pixman-filter.c b/pixman/pixman-filter.c
index dcbed11..8416550 100644
---
Rename kernel1/2 to reconstruct/sample and use 1/scale as the
scale argument, thus matching the names in other functions.
---
pixman/pixman-filter.c | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/pixman/pixman-filter.c
---
pixman/pixman-filter.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/pixman/pixman-filter.c b/pixman/pixman-filter.c
index a9af72c..816d085 100644
--- a/pixman/pixman-filter.c
+++ b/pixman/pixman-filter.c
@@ -294,7 +294,7 @@ create_1d_filter (int *width,
Simplified the function.
Expanded 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 new
value is less than 1/2 of 1/255, rather than greater than it.
---
pixman/pixman-filter.c |7 ++-
1 file changed, 2
GOOD uses the BOX.BOX filter, and uses BILINEAR for all scales 1/1.35. If
only one scale is 1/1.35 if uses LINEAR.IMPULSE for it to match the BILINEAR
result. At very small scales it clamps the filter size to 16.
BEST uses the IMPULSE.LANCZOS2 filter up to a scale of 2 with the filter size
This allows testing of GOOD/BEST and to do comparisons between
the basic filters and PIXMAN_FILTER_SEPARABLE_CONVOLUTION settings.
---
demos/scale.c | 14 +-
demos/scale.ui | 40 ++--
2 files changed, 43 insertions(+), 11 deletions(-)
diff
- Put error on center of odd-sized filters. This may fix other filters
some but the primary effect is to change the size=1 filters produced
by IMPULSE sampling from 0.0 to 1.0.
- Made IMPULSE.IMPULSE produce a filter of size 1, not zero.
- Reuse the above result to produce a faster BOX.IMPULSE
This is much more accurate and less blurry. In particular the filtering does
not change as the image is rotated.
---
demos/scale.c | 43 ++-
1 file changed, 2 insertions(+), 41 deletions(-)
diff --git a/demos/scale.c b/demos/scale.c
index
This is easy as the caller already intersected the two boxes.
---
pixman/pixman-filter.c | 25 +++--
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/pixman/pixman-filter.c b/pixman/pixman-filter.c
index a9af72c..4ff02ec 100644
--- a/pixman/pixman-filter.c
+++
---
pixman/pixman-filter.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/pixman/pixman-filter.c b/pixman/pixman-filter.c
index 035a784..4561af2 100644
--- a/pixman/pixman-filter.c
+++ b/pixman/pixman-filter.c
@@ -180,13 +180,13 @@ integral (pixman_kernel_t
This supersedes my previous patch. Changes are:
- Rebased atop current git master
- Corrected and clarified how bilinear is done by GOOD, removed
unnecessary filter switch because BOX.BOX as scale==1 is the same as
bilinear.
- Merged and rearranged some patches about impulse sampling.
Samples are multiplied in a 1,4,2,4,2...4,1 pattern, previous version
did 1,2,6,6...6,2,1 which produced 2x the correct integrated value
(this was corrected by the normalization) and also just did simple
numeric integration and not Simpsons.
I also reduced the number of samples a lot as it is
Simplified the function.
Expanded 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 new
value is less than 1/2 of 1/255, rather than greater than it.
---
pixman/pixman-filter.c |7 ++-
1 file changed, 2
Simplified the function.
Expanded 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 new
value is less than 1/2 of 1/255, rather than greater than it.
---
pixman/pixman-filter.c |7 ++-
1 file changed, 2
This is much more accurate and less blurry. In particular the filtering does
not change as the image is rotated.
---
demos/scale.c | 43 ++-
1 file changed, 2 insertions(+), 41 deletions(-)
diff --git a/demos/scale.c b/demos/scale.c
index
This is easy as the caller already intersected the two boxes.
---
pixman/pixman-filter.c | 25 +++--
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/pixman/pixman-filter.c b/pixman/pixman-filter.c
index a9af72c..4ff02ec 100644
--- a/pixman/pixman-filter.c
+++
Oops, these debugging printfs should be removed before use:
On 09/26/2014 07:06 PM, Bill Spitzak wrote:
+ if (bilinear_ok) {
+ printf(Using bilinear\n);
+ flags |= (FAST_PATH_BILINEAR_FILTER |
+ FAST_PATH_NO_CONVOLUTION_FILTER
Have you seen my new set of patches? I tried to preserve the
reconstruction/sampling filter api but fix some problems I found.
___
Pixman mailing list
Pixman@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pixman
This is much more accurate and less blurry. In particular the filtering does
not change as the image is rotated.
---
demos/scale.c | 43 ++-
1 file changed, 2 insertions(+), 41 deletions(-)
diff --git a/demos/scale.c b/demos/scale.c
index
---
pixman/pixman-filter.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/pixman/pixman-filter.c b/pixman/pixman-filter.c
index 035a784..4561af2 100644
--- a/pixman/pixman-filter.c
+++ b/pixman/pixman-filter.c
@@ -180,13 +180,13 @@ integral (pixman_kernel_t
---
pixman/pixman-filter.c | 57
1 file changed, 24 insertions(+), 33 deletions(-)
diff --git a/pixman/pixman-filter.c b/pixman/pixman-filter.c
index 4561af2..1a465ac 100644
--- a/pixman/pixman-filter.c
+++ b/pixman/pixman-filter.c
@@ -225,25
GOOD uses the BOX.BOX filter, with a filter size of 1 for all scales larger
than .75, which is identical to BILINEAR. At very small scales it clamps the
filter size to 16. Uses the BILINEAR code if both directions are bilinear
or are exactly .5 scale with integer translations.
BEST uses the
- Put error on center of odd-sized filters. This may fix other filters
some but the primary effect is to change the size=1 filters produced
by IMPULSE sampling from 0.0 to 1.0.
- Made IMPULSE.IMPULSE produce a filter of size 1, not zero.
- Reuse the above result to produce a faster BOX.IMPULSE
This is easy as the caller already intersected the two boxes.
---
pixman/pixman-filter.c | 25 +++--
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/pixman/pixman-filter.c b/pixman/pixman-filter.c
index a9af72c..4ff02ec 100644
--- a/pixman/pixman-filter.c
+++
Simplified the function.
Expanded 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 new
value is less than 1/2 of 1/255, rather than greater than it.
---
pixman/pixman-filter.c |7 ++-
1 file changed, 2
Rename kernel1/2 to reconstruct/sample and use 1/scale as the
scale argument, thus matching the names in other functions.
---
pixman/pixman-filter.c | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/pixman/pixman-filter.c
This allows testing of GOOD/BEST and to do comparisons between
the basic filters and PIXMAN_FILTER_SEPARABLE_CONVOLUTION settings.
---
demos/scale.c | 14 +-
demos/scale.ui | 40 ++--
2 files changed, 43 insertions(+), 11 deletions(-)
diff
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 new
value is less than 1/2 of 1/255, rather than greater than it.
---
pixman/pixman-filter.c |7 ++-
This is easy as the caller already intersected the two boxes, so
the width is the integral.
---
pixman/pixman-filter.c |5 +
1 file changed, 5 insertions(+)
diff --git a/pixman/pixman-filter.c b/pixman/pixman-filter.c
index 4aafa51..782f73d 100644
--- a/pixman/pixman-filter.c
+++
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 needed.
---
pixman/pixman-filter.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/pixman/pixman-filter.c
The other filters don't range-check, so there is no need for this
one to either. It is only called with x==0.
---
pixman/pixman-filter.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/pixman/pixman-filter.c b/pixman/pixman-filter.c
index fbc657d..00126cd 100644
---
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 insertion(+), 1 deletion(-)
diff --git a/pixman/pixman-filter.c b/pixman/pixman-filter.c
index
This allows testing of GOOD/BEST and to do comparisons between
the basic filters and PIXMAN_FILTER_SEPARABLE_CONVOLUTION settings.
---
demos/scale.c | 14 +-
demos/scale.ui | 40 ++--
2 files changed, 43 insertions(+), 11 deletions(-)
diff
This supersedes my previous set of patches. Changes are to fix some
rebase errors so that it compiles after each patch applies, and some
further rebasing to rearrange the patches and split them into a more
logical order.
___
Pixman mailing list
Rearranged so that the entire block of memory for the filter pair
is allocated first, and then filled in. Previous version allocated
and freed two temporary buffers for each filter and did an extra
memcpy.
---
pixman/pixman-filter.c | 59
1 file
Only LINEAR is not differentiable at zero, so only do the recursive
split of the integral for it.
---
pixman/pixman-filter.c | 34 +-
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/pixman/pixman-filter.c b/pixman/pixman-filter.c
index
The other filters do not check for x being in range, so there is
no reason for cubic to do so.
---
pixman/pixman-filter.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/pixman/pixman-filter.c b/pixman/pixman-filter.c
index 7e10108..bf9dce3 100644
---
This is much more accurate and less blurry. In particular the filtering does
not change as the image is rotated.
---
demos/scale.c | 43 ++-
1 file changed, 2 insertions(+), 41 deletions(-)
diff --git a/demos/scale.c b/demos/scale.c
index
Uses a wildcard to handle the majority which end in -test.
---
.gitignore | 45 +
1 file changed, 5 insertions(+), 40 deletions(-)
diff --git a/.gitignore b/.gitignore
index 7da6b6f..a245b69 100644
--- a/.gitignore
+++ b/.gitignore
@@ -26,62 +26,27
This is easy as the caller already intersected the two boxes, so
the width is the integral.
---
pixman/pixman-filter.c |5 +
1 file changed, 5 insertions(+)
diff --git a/pixman/pixman-filter.c b/pixman/pixman-filter.c
index 4aafa51..782f73d 100644
--- a/pixman/pixman-filter.c
+++
The other filters do not check for x being in range, so there is
no reason for cubic to do so.
---
pixman/pixman-filter.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/pixman/pixman-filter.c b/pixman/pixman-filter.c
index 7e10108..bf9dce3 100644
---
This is much more accurate and less blurry. In particular the filtering does
not change as the image is rotated.
---
demos/scale.c | 43 ++-
1 file changed, 2 insertions(+), 41 deletions(-)
diff --git a/demos/scale.c b/demos/scale.c
index
1 - 100 of 192 matches
Mail list logo
