2012-03-30 23:13:38 +00:00
|
|
|
/*
|
filter_kernels: replace AGG-based code
This commit replaces code based on AGG, taken from this source file:
http://vector-agg.cvs.sourceforge.net/viewvc/vector-agg/agg-2.5/include/agg_image_filters.h
The intention is that filter_kernels.c can be relicensed to LGPL or BSD.
Because the AGG author died, full replacement is the only way to achieve
it.
This affects only some filter functions. These are exclusively
mathematical functions for computing filter coefficients. (Other parts
in filter_kernel.c were originally written by me, with heavy additions
and refactoring done by other mpv contributors.) While the code is
mostly just well-known mathematical formulas written down in C form,
AGG copyright could perhaps be claimed anyway.
To remove the AGG code, I replaced it with the filter functions from:
https://github.com/glumpy/glumpy/blob/master/glumpy/library/build-spatial-filters.py
These functions conveniently compute exactly the same thing in mpv,
Glumpy, AGG (and about anything that will filter images using the same
mathematical principles).
First I ported the Python code in the file to C. Then I replaced all
functions in filter_kernels.c with this code that could be replaced.
Then I investigated whether the remaining functions were based on AGG
code and took appropriate action:
hanning(), hamming(), quadric(), bicubic(), kaiser(), blackman(),
spline16(), spline36(), gaussian(), sinc() were taken straight from
Glumpy.
For sinc(), re-add the "fabs(x) < 1e-8" check, which was added in commit
586dc557 for unknown reasons.
gaussian() loses its filter parameter for some reason. (Well, who cares,
not my problem.)
The really awkward thing is that the text for hanning() and hamming()
does not change. In theory these functions are now based on Glumpy code,
but it seems like this can be neither proven nor denied. (The same
happened in some other cases with at least a few lines of code.)
sphinx() was added in commit 586dc557, and looks suspiciously like
sinc() as well. Replace the first 3 lines of the body with the ported
function (of which 2 lines do not change; the first uses code only in
mpv, and the second is just "return 1.0;"). The 4th line is only similar
on an abstract level (and that because of the mathematical relation
between these functions). Although the original sinc() was probably used
as template for it, with the other lines replaced, I don't think you
could make the claim that it falls under AGG copyright.
jinc() was added in commit 26baf5b9, but the code for it might be based
on sinc(). Rewrite it based on the "new" sinc(). Some of the same
remarks as with sphinx() apply.
cubic_bc() was ported from Glumpy's Mitchell(). (As far as I'm aware,
with the default parameters it's called "the" Mitchell-Netravali filter,
but in mpv this function is used to generate a whole group of filters.)
spline64() was added in commit a8b67c66, and was probably derived from
spline36(). Re-derive it from the "new" spline36().
triangle() could be considered derived from the original bilinear().
This is this in the original commit:
static double bilinear(kernel *k, double x)
{
return 1.0 - x;
}
This _might_ be based on AGG's image_filter_bilinear:
struct image_filter_bilinear
{
static double radius() { return 1.0; }
static double calc_weight(double x)
{
return 1.0 - x;
}
};
Considering that the "framework" was written by me, and the only part
from AGG taken is "return 1.0 - x;", and this part is trivial and was
later thoroughly replaced, this is probably not under the AGG copyright.
I'm hoping this doesn't introduce regressions. But the main focus is not
being productive anyway, and I didn't rigorously check unintended
changes in functionality.
2016-01-06 17:35:01 +00:00
|
|
|
* Some of the filter code was taken from Glumpy:
|
|
|
|
* # Copyright (c) 2009-2016 Nicolas P. Rougier. All rights reserved.
|
|
|
|
* # Distributed under the (new) BSD License.
|
|
|
|
* (https://github.com/glumpy/glumpy/blob/master/glumpy/library/build-spatial-filters.py)
|
2014-08-25 20:15:42 +00:00
|
|
|
*
|
2015-04-13 07:36:54 +00:00
|
|
|
* Also see:
|
filter_kernels: replace AGG-based code
This commit replaces code based on AGG, taken from this source file:
http://vector-agg.cvs.sourceforge.net/viewvc/vector-agg/agg-2.5/include/agg_image_filters.h
The intention is that filter_kernels.c can be relicensed to LGPL or BSD.
Because the AGG author died, full replacement is the only way to achieve
it.
This affects only some filter functions. These are exclusively
mathematical functions for computing filter coefficients. (Other parts
in filter_kernel.c were originally written by me, with heavy additions
and refactoring done by other mpv contributors.) While the code is
mostly just well-known mathematical formulas written down in C form,
AGG copyright could perhaps be claimed anyway.
To remove the AGG code, I replaced it with the filter functions from:
https://github.com/glumpy/glumpy/blob/master/glumpy/library/build-spatial-filters.py
These functions conveniently compute exactly the same thing in mpv,
Glumpy, AGG (and about anything that will filter images using the same
mathematical principles).
First I ported the Python code in the file to C. Then I replaced all
functions in filter_kernels.c with this code that could be replaced.
Then I investigated whether the remaining functions were based on AGG
code and took appropriate action:
hanning(), hamming(), quadric(), bicubic(), kaiser(), blackman(),
spline16(), spline36(), gaussian(), sinc() were taken straight from
Glumpy.
For sinc(), re-add the "fabs(x) < 1e-8" check, which was added in commit
586dc557 for unknown reasons.
gaussian() loses its filter parameter for some reason. (Well, who cares,
not my problem.)
The really awkward thing is that the text for hanning() and hamming()
does not change. In theory these functions are now based on Glumpy code,
but it seems like this can be neither proven nor denied. (The same
happened in some other cases with at least a few lines of code.)
sphinx() was added in commit 586dc557, and looks suspiciously like
sinc() as well. Replace the first 3 lines of the body with the ported
function (of which 2 lines do not change; the first uses code only in
mpv, and the second is just "return 1.0;"). The 4th line is only similar
on an abstract level (and that because of the mathematical relation
between these functions). Although the original sinc() was probably used
as template for it, with the other lines replaced, I don't think you
could make the claim that it falls under AGG copyright.
jinc() was added in commit 26baf5b9, but the code for it might be based
on sinc(). Rewrite it based on the "new" sinc(). Some of the same
remarks as with sphinx() apply.
cubic_bc() was ported from Glumpy's Mitchell(). (As far as I'm aware,
with the default parameters it's called "the" Mitchell-Netravali filter,
but in mpv this function is used to generate a whole group of filters.)
spline64() was added in commit a8b67c66, and was probably derived from
spline36(). Re-derive it from the "new" spline36().
triangle() could be considered derived from the original bilinear().
This is this in the original commit:
static double bilinear(kernel *k, double x)
{
return 1.0 - x;
}
This _might_ be based on AGG's image_filter_bilinear:
struct image_filter_bilinear
{
static double radius() { return 1.0; }
static double calc_weight(double x)
{
return 1.0 - x;
}
};
Considering that the "framework" was written by me, and the only part
from AGG taken is "return 1.0 - x;", and this part is trivial and was
later thoroughly replaced, this is probably not under the AGG copyright.
I'm hoping this doesn't introduce regressions. But the main focus is not
being productive anyway, and I didn't rigorously check unintended
changes in functionality.
2016-01-06 17:35:01 +00:00
|
|
|
* - http://vector-agg.cvs.sourceforge.net/viewvc/vector-agg/agg-2.5/include/agg_image_filters.h
|
2015-04-13 07:36:54 +00:00
|
|
|
* - Vapoursynth plugin fmtconv (WTFPL Licensed), which is based on
|
|
|
|
* dither plugin for avisynth from the same author:
|
|
|
|
* https://github.com/vapoursynth/fmtconv/tree/master/src/fmtc
|
|
|
|
* - Paul Heckbert's "zoom"
|
|
|
|
* - XBMC: ConvolutionKernels.cpp etc.
|
2012-03-30 23:13:38 +00:00
|
|
|
*
|
2015-04-13 07:36:54 +00:00
|
|
|
* This file is part of mpv.
|
2012-03-30 23:13:38 +00:00
|
|
|
*
|
2016-01-07 10:27:18 +00:00
|
|
|
* This file can be distributed under the 3-clause license ("New BSD License").
|
2012-03-30 23:13:38 +00:00
|
|
|
*
|
2016-01-07 10:27:18 +00:00
|
|
|
* You can alternatively redistribute the non-Glumpy parts of this file and/or
|
|
|
|
* modify it under the terms of the GNU Lesser General Public
|
|
|
|
* License as published by the Free Software Foundation; either
|
|
|
|
* version 2.1 of the License, or (at your option) any later version.
|
2012-03-30 23:13:38 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
#include <stddef.h>
|
|
|
|
#include <string.h>
|
|
|
|
#include <math.h>
|
|
|
|
#include <assert.h>
|
|
|
|
|
|
|
|
#include "filter_kernels.h"
|
2017-03-05 01:13:18 +00:00
|
|
|
#include "common/common.h"
|
2012-03-30 23:13:38 +00:00
|
|
|
|
vo_opengl: separate kernel and window
This makes the core much more elegant, reusable, reconfigurable and also
allows us to more easily add aliases for specific configurations.
Furthermore, this lets us apply a generic blur factor / window function
to arbitrary filters, so we can finally "mix and match" in order to
fine-tune windowing functions.
A few notes are in order:
1. The current system for configuring scalers is ugly and rapidly
getting unwieldy. I modified the man page to make it a bit more
bearable, but long-term we have to do something about it; especially
since..
2. There's currently no way to affect the blur factor or parameters of
the window functions themselves. For example, I can't actually
fine-tune the kaiser window's param1, since there's simply no way to
do so in the current API - even though filter_kernels.c supports it
just fine!
3. This removes some lesser used filters (especially those which are
purely window functions to begin with). If anybody asks, you can get
eg. the old behavior of scale=hanning by using
scale=box:scale-window=hanning:scale-radius=1 (and yes, the result is
just as terrible as that sounds - which is why nobody should have
been using them in the first place).
4. This changes the semantics of the "triangle" scaler slightly - it now
has an arbitrary radius. This can possibly produce weird results for
people who were previously using scale-down=triangle, especially if
in combination with scale-radius (for the usual upscaling). The
correct fix for this is to use scale-down=bilinear_slow instead,
which is an alias for triangle at radius 1.
In regards to the last point, in future I want to make it so that
filters have a filter-specific "preferred radius" (for the ones that
are arbitrarily tunable), once the configuration system for filters has
been redesigned (in particular in a way that will let us separate scale
and scale-down cleanly). That way, "triangle" can simply have the
preferred radius of 1 by default, while still being tunable. (Rather
than the default radius being hard-coded to 3 always)
2015-03-25 03:40:28 +00:00
|
|
|
// NOTE: all filters are designed for discrete convolution
|
|
|
|
|
|
|
|
const struct filter_window *mp_find_filter_window(const char *name)
|
|
|
|
{
|
|
|
|
if (!name)
|
|
|
|
return NULL;
|
|
|
|
for (const struct filter_window *w = mp_filter_windows; w->name; w++) {
|
|
|
|
if (strcmp(w->name, name) == 0)
|
|
|
|
return w;
|
|
|
|
}
|
|
|
|
return NULL;
|
|
|
|
}
|
2012-03-30 23:13:38 +00:00
|
|
|
|
|
|
|
const struct filter_kernel *mp_find_filter_kernel(const char *name)
|
|
|
|
{
|
vo_opengl: refactor scaler configuration
This merges all of the scaler-related options into a single
configuration struct, and also cleans up the way they're passed through
the code. (For example, the scaler index is no longer threaded through
pass_sample, just the scaler configuration itself, and there's no longer
duplication of the params etc.)
In addition, this commit makes scale-down more principled, and turns it
into a scaler in its own right - so there's no longer an ugly separation
between scale and scale-down in the code.
Finally, the radius stuff has been made more proper - filters always
have a radius now (there's no more radius -1), and get a new .resizable
attribute instead for when it's tunable.
User-visible changes:
1. scale-down has been renamed dscale and now has its own set of config
options (dscale-param1, dscale-radius) etc., instead of reusing
scale-param1 (which was arguably a bug).
2. The default radius is no longer fixed at 3, but instead uses that
filter's preferred radius by default. (Scalers with a default radius
other than 3 include sinc, gaussian, box and triangle)
3. scale-radius etc. now goes down to 0.5, rather than 1.0. 0.5 is the
smallest radius that theoretically makes sense, and indeed it's used
by at least one filter (nearest).
Apart from that, it should just be internal changes only.
Note that this sets up for the refactor discussed in #1720, which would
be to merge scaler and window configurations (include parameters etc.)
into a single, simplified string. In the code, this would now basically
just mean getting rid of all the OPT_FLOATRANGE etc. lines related to
scalers and replacing them by a single function that parses a string and
updates the struct scaler_config as appropriate.
2015-03-26 00:55:32 +00:00
|
|
|
if (!name)
|
|
|
|
return NULL;
|
vo_opengl: separate kernel and window
This makes the core much more elegant, reusable, reconfigurable and also
allows us to more easily add aliases for specific configurations.
Furthermore, this lets us apply a generic blur factor / window function
to arbitrary filters, so we can finally "mix and match" in order to
fine-tune windowing functions.
A few notes are in order:
1. The current system for configuring scalers is ugly and rapidly
getting unwieldy. I modified the man page to make it a bit more
bearable, but long-term we have to do something about it; especially
since..
2. There's currently no way to affect the blur factor or parameters of
the window functions themselves. For example, I can't actually
fine-tune the kaiser window's param1, since there's simply no way to
do so in the current API - even though filter_kernels.c supports it
just fine!
3. This removes some lesser used filters (especially those which are
purely window functions to begin with). If anybody asks, you can get
eg. the old behavior of scale=hanning by using
scale=box:scale-window=hanning:scale-radius=1 (and yes, the result is
just as terrible as that sounds - which is why nobody should have
been using them in the first place).
4. This changes the semantics of the "triangle" scaler slightly - it now
has an arbitrary radius. This can possibly produce weird results for
people who were previously using scale-down=triangle, especially if
in combination with scale-radius (for the usual upscaling). The
correct fix for this is to use scale-down=bilinear_slow instead,
which is an alias for triangle at radius 1.
In regards to the last point, in future I want to make it so that
filters have a filter-specific "preferred radius" (for the ones that
are arbitrarily tunable), once the configuration system for filters has
been redesigned (in particular in a way that will let us separate scale
and scale-down cleanly). That way, "triangle" can simply have the
preferred radius of 1 by default, while still being tunable. (Rather
than the default radius being hard-coded to 3 always)
2015-03-25 03:40:28 +00:00
|
|
|
for (const struct filter_kernel *k = mp_filter_kernels; k->f.name; k++) {
|
|
|
|
if (strcmp(k->f.name, name) == 0)
|
2012-03-30 23:13:38 +00:00
|
|
|
return k;
|
|
|
|
}
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
// sizes = sorted list of available filter sizes, terminated with size 0
|
|
|
|
// inv_scale = source_size / dest_size
|
|
|
|
bool mp_init_filter(struct filter_kernel *filter, const int *sizes,
|
|
|
|
double inv_scale)
|
|
|
|
{
|
vo_opengl: separate kernel and window
This makes the core much more elegant, reusable, reconfigurable and also
allows us to more easily add aliases for specific configurations.
Furthermore, this lets us apply a generic blur factor / window function
to arbitrary filters, so we can finally "mix and match" in order to
fine-tune windowing functions.
A few notes are in order:
1. The current system for configuring scalers is ugly and rapidly
getting unwieldy. I modified the man page to make it a bit more
bearable, but long-term we have to do something about it; especially
since..
2. There's currently no way to affect the blur factor or parameters of
the window functions themselves. For example, I can't actually
fine-tune the kaiser window's param1, since there's simply no way to
do so in the current API - even though filter_kernels.c supports it
just fine!
3. This removes some lesser used filters (especially those which are
purely window functions to begin with). If anybody asks, you can get
eg. the old behavior of scale=hanning by using
scale=box:scale-window=hanning:scale-radius=1 (and yes, the result is
just as terrible as that sounds - which is why nobody should have
been using them in the first place).
4. This changes the semantics of the "triangle" scaler slightly - it now
has an arbitrary radius. This can possibly produce weird results for
people who were previously using scale-down=triangle, especially if
in combination with scale-radius (for the usual upscaling). The
correct fix for this is to use scale-down=bilinear_slow instead,
which is an alias for triangle at radius 1.
In regards to the last point, in future I want to make it so that
filters have a filter-specific "preferred radius" (for the ones that
are arbitrarily tunable), once the configuration system for filters has
been redesigned (in particular in a way that will let us separate scale
and scale-down cleanly). That way, "triangle" can simply have the
preferred radius of 1 by default, while still being tunable. (Rather
than the default radius being hard-coded to 3 always)
2015-03-25 03:40:28 +00:00
|
|
|
assert(filter->f.radius > 0);
|
|
|
|
// Only downscaling requires widening the filter
|
2017-03-05 01:13:18 +00:00
|
|
|
filter->filter_scale = MPMAX(1.0, inv_scale);
|
|
|
|
double src_radius = filter->f.radius * filter->filter_scale;
|
vo_opengl: separate kernel and window
This makes the core much more elegant, reusable, reconfigurable and also
allows us to more easily add aliases for specific configurations.
Furthermore, this lets us apply a generic blur factor / window function
to arbitrary filters, so we can finally "mix and match" in order to
fine-tune windowing functions.
A few notes are in order:
1. The current system for configuring scalers is ugly and rapidly
getting unwieldy. I modified the man page to make it a bit more
bearable, but long-term we have to do something about it; especially
since..
2. There's currently no way to affect the blur factor or parameters of
the window functions themselves. For example, I can't actually
fine-tune the kaiser window's param1, since there's simply no way to
do so in the current API - even though filter_kernels.c supports it
just fine!
3. This removes some lesser used filters (especially those which are
purely window functions to begin with). If anybody asks, you can get
eg. the old behavior of scale=hanning by using
scale=box:scale-window=hanning:scale-radius=1 (and yes, the result is
just as terrible as that sounds - which is why nobody should have
been using them in the first place).
4. This changes the semantics of the "triangle" scaler slightly - it now
has an arbitrary radius. This can possibly produce weird results for
people who were previously using scale-down=triangle, especially if
in combination with scale-radius (for the usual upscaling). The
correct fix for this is to use scale-down=bilinear_slow instead,
which is an alias for triangle at radius 1.
In regards to the last point, in future I want to make it so that
filters have a filter-specific "preferred radius" (for the ones that
are arbitrarily tunable), once the configuration system for filters has
been redesigned (in particular in a way that will let us separate scale
and scale-down cleanly). That way, "triangle" can simply have the
preferred radius of 1 by default, while still being tunable. (Rather
than the default radius being hard-coded to 3 always)
2015-03-25 03:40:28 +00:00
|
|
|
// Polar filters are dependent solely on the radius
|
2015-01-04 22:11:27 +00:00
|
|
|
if (filter->polar) {
|
2017-03-05 01:13:18 +00:00
|
|
|
filter->size = 1; // Not meaningful for EWA/polar scalers.
|
vo_opengl: separate kernel and window
This makes the core much more elegant, reusable, reconfigurable and also
allows us to more easily add aliases for specific configurations.
Furthermore, this lets us apply a generic blur factor / window function
to arbitrary filters, so we can finally "mix and match" in order to
fine-tune windowing functions.
A few notes are in order:
1. The current system for configuring scalers is ugly and rapidly
getting unwieldy. I modified the man page to make it a bit more
bearable, but long-term we have to do something about it; especially
since..
2. There's currently no way to affect the blur factor or parameters of
the window functions themselves. For example, I can't actually
fine-tune the kaiser window's param1, since there's simply no way to
do so in the current API - even though filter_kernels.c supports it
just fine!
3. This removes some lesser used filters (especially those which are
purely window functions to begin with). If anybody asks, you can get
eg. the old behavior of scale=hanning by using
scale=box:scale-window=hanning:scale-radius=1 (and yes, the result is
just as terrible as that sounds - which is why nobody should have
been using them in the first place).
4. This changes the semantics of the "triangle" scaler slightly - it now
has an arbitrary radius. This can possibly produce weird results for
people who were previously using scale-down=triangle, especially if
in combination with scale-radius (for the usual upscaling). The
correct fix for this is to use scale-down=bilinear_slow instead,
which is an alias for triangle at radius 1.
In regards to the last point, in future I want to make it so that
filters have a filter-specific "preferred radius" (for the ones that
are arbitrarily tunable), once the configuration system for filters has
been redesigned (in particular in a way that will let us separate scale
and scale-down cleanly). That way, "triangle" can simply have the
preferred radius of 1 by default, while still being tunable. (Rather
than the default radius being hard-coded to 3 always)
2015-03-25 03:40:28 +00:00
|
|
|
// Safety precaution to avoid generating a gigantic shader
|
2017-03-05 01:13:18 +00:00
|
|
|
if (src_radius > 16.0) {
|
|
|
|
src_radius = 16.0;
|
|
|
|
filter->filter_scale = src_radius / filter->f.radius;
|
vo_opengl: separate kernel and window
This makes the core much more elegant, reusable, reconfigurable and also
allows us to more easily add aliases for specific configurations.
Furthermore, this lets us apply a generic blur factor / window function
to arbitrary filters, so we can finally "mix and match" in order to
fine-tune windowing functions.
A few notes are in order:
1. The current system for configuring scalers is ugly and rapidly
getting unwieldy. I modified the man page to make it a bit more
bearable, but long-term we have to do something about it; especially
since..
2. There's currently no way to affect the blur factor or parameters of
the window functions themselves. For example, I can't actually
fine-tune the kaiser window's param1, since there's simply no way to
do so in the current API - even though filter_kernels.c supports it
just fine!
3. This removes some lesser used filters (especially those which are
purely window functions to begin with). If anybody asks, you can get
eg. the old behavior of scale=hanning by using
scale=box:scale-window=hanning:scale-radius=1 (and yes, the result is
just as terrible as that sounds - which is why nobody should have
been using them in the first place).
4. This changes the semantics of the "triangle" scaler slightly - it now
has an arbitrary radius. This can possibly produce weird results for
people who were previously using scale-down=triangle, especially if
in combination with scale-radius (for the usual upscaling). The
correct fix for this is to use scale-down=bilinear_slow instead,
which is an alias for triangle at radius 1.
In regards to the last point, in future I want to make it so that
filters have a filter-specific "preferred radius" (for the ones that
are arbitrarily tunable), once the configuration system for filters has
been redesigned (in particular in a way that will let us separate scale
and scale-down cleanly). That way, "triangle" can simply have the
preferred radius of 1 by default, while still being tunable. (Rather
than the default radius being hard-coded to 3 always)
2015-03-25 03:40:28 +00:00
|
|
|
return false;
|
|
|
|
}
|
2015-01-04 22:11:27 +00:00
|
|
|
return true;
|
|
|
|
}
|
2017-03-05 01:13:18 +00:00
|
|
|
int size = ceil(2.0 * src_radius);
|
2012-03-30 23:13:38 +00:00
|
|
|
// round up to smallest available size that's still large enough
|
|
|
|
if (size < sizes[0])
|
|
|
|
size = sizes[0];
|
|
|
|
const int *cursize = sizes;
|
|
|
|
while (size > *cursize && *cursize)
|
|
|
|
cursize++;
|
|
|
|
if (*cursize) {
|
|
|
|
filter->size = *cursize;
|
|
|
|
return true;
|
|
|
|
} else {
|
|
|
|
// The filter doesn't fit - instead of failing completely, use the
|
|
|
|
// largest filter available. This is incorrect, but better than refusing
|
|
|
|
// to do anything.
|
|
|
|
filter->size = cursize[-1];
|
2017-03-05 01:13:18 +00:00
|
|
|
filter->filter_scale = (filter->size/2.0) / filter->f.radius;
|
2012-03-30 23:13:38 +00:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-10-26 14:32:57 +00:00
|
|
|
// Sample from a blurred and tapered window
|
|
|
|
static double sample_window(struct filter_window *kernel, double x)
|
vo_opengl: separate kernel and window
This makes the core much more elegant, reusable, reconfigurable and also
allows us to more easily add aliases for specific configurations.
Furthermore, this lets us apply a generic blur factor / window function
to arbitrary filters, so we can finally "mix and match" in order to
fine-tune windowing functions.
A few notes are in order:
1. The current system for configuring scalers is ugly and rapidly
getting unwieldy. I modified the man page to make it a bit more
bearable, but long-term we have to do something about it; especially
since..
2. There's currently no way to affect the blur factor or parameters of
the window functions themselves. For example, I can't actually
fine-tune the kaiser window's param1, since there's simply no way to
do so in the current API - even though filter_kernels.c supports it
just fine!
3. This removes some lesser used filters (especially those which are
purely window functions to begin with). If anybody asks, you can get
eg. the old behavior of scale=hanning by using
scale=box:scale-window=hanning:scale-radius=1 (and yes, the result is
just as terrible as that sounds - which is why nobody should have
been using them in the first place).
4. This changes the semantics of the "triangle" scaler slightly - it now
has an arbitrary radius. This can possibly produce weird results for
people who were previously using scale-down=triangle, especially if
in combination with scale-radius (for the usual upscaling). The
correct fix for this is to use scale-down=bilinear_slow instead,
which is an alias for triangle at radius 1.
In regards to the last point, in future I want to make it so that
filters have a filter-specific "preferred radius" (for the ones that
are arbitrarily tunable), once the configuration system for filters has
been redesigned (in particular in a way that will let us separate scale
and scale-down cleanly). That way, "triangle" can simply have the
preferred radius of 1 by default, while still being tunable. (Rather
than the default radius being hard-coded to 3 always)
2015-03-25 03:40:28 +00:00
|
|
|
{
|
2016-10-26 14:32:57 +00:00
|
|
|
if (!kernel->weight)
|
|
|
|
return 1.0;
|
|
|
|
|
|
|
|
// All windows are symmetric, this makes life easier
|
|
|
|
x = fabs(x);
|
|
|
|
|
|
|
|
// Stretch and taper the window size as needed
|
|
|
|
x = kernel->blur > 0.0 ? x / kernel->blur : x;
|
|
|
|
x = x <= kernel->taper ? 0.0 : (x - kernel->taper) / (1 - kernel->taper);
|
|
|
|
|
2017-03-04 04:35:22 +00:00
|
|
|
if (x < kernel->radius)
|
|
|
|
return kernel->weight(kernel, x);
|
|
|
|
return 0.0;
|
2016-10-26 14:32:57 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// Evaluate a filter's kernel and window at a given absolute position
|
|
|
|
static double sample_filter(struct filter_kernel *filter, double x)
|
|
|
|
{
|
|
|
|
// The window is always stretched to the entire kernel
|
|
|
|
double w = sample_window(&filter->w, x / filter->f.radius * filter->w.radius);
|
2017-07-12 17:08:58 +00:00
|
|
|
double k = w * sample_window(&filter->f, x);
|
|
|
|
return k < 0 ? (1 - filter->clamp) * k : k;
|
vo_opengl: separate kernel and window
This makes the core much more elegant, reusable, reconfigurable and also
allows us to more easily add aliases for specific configurations.
Furthermore, this lets us apply a generic blur factor / window function
to arbitrary filters, so we can finally "mix and match" in order to
fine-tune windowing functions.
A few notes are in order:
1. The current system for configuring scalers is ugly and rapidly
getting unwieldy. I modified the man page to make it a bit more
bearable, but long-term we have to do something about it; especially
since..
2. There's currently no way to affect the blur factor or parameters of
the window functions themselves. For example, I can't actually
fine-tune the kaiser window's param1, since there's simply no way to
do so in the current API - even though filter_kernels.c supports it
just fine!
3. This removes some lesser used filters (especially those which are
purely window functions to begin with). If anybody asks, you can get
eg. the old behavior of scale=hanning by using
scale=box:scale-window=hanning:scale-radius=1 (and yes, the result is
just as terrible as that sounds - which is why nobody should have
been using them in the first place).
4. This changes the semantics of the "triangle" scaler slightly - it now
has an arbitrary radius. This can possibly produce weird results for
people who were previously using scale-down=triangle, especially if
in combination with scale-radius (for the usual upscaling). The
correct fix for this is to use scale-down=bilinear_slow instead,
which is an alias for triangle at radius 1.
In regards to the last point, in future I want to make it so that
filters have a filter-specific "preferred radius" (for the ones that
are arbitrarily tunable), once the configuration system for filters has
been redesigned (in particular in a way that will let us separate scale
and scale-down cleanly). That way, "triangle" can simply have the
preferred radius of 1 by default, while still being tunable. (Rather
than the default radius being hard-coded to 3 always)
2015-03-25 03:40:28 +00:00
|
|
|
}
|
|
|
|
|
2012-03-30 23:13:38 +00:00
|
|
|
// Calculate the 1D filtering kernel for N sample points.
|
|
|
|
// N = number of samples, which is filter->size
|
|
|
|
// The weights will be stored in out_w[0] to out_w[N - 1]
|
|
|
|
// f = x0 - abs(x0), subpixel position in the range [0,1) or [0,1].
|
2016-10-26 14:32:57 +00:00
|
|
|
static void mp_compute_weights(struct filter_kernel *filter, double f,
|
|
|
|
float *out_w)
|
2012-03-30 23:13:38 +00:00
|
|
|
{
|
|
|
|
assert(filter->size > 0);
|
|
|
|
double sum = 0;
|
|
|
|
for (int n = 0; n < filter->size; n++) {
|
|
|
|
double x = f - (n - filter->size / 2 + 1);
|
2017-03-05 01:13:18 +00:00
|
|
|
double w = sample_filter(filter, x / filter->filter_scale);
|
2012-03-30 23:13:38 +00:00
|
|
|
out_w[n] = w;
|
|
|
|
sum += w;
|
|
|
|
}
|
vo_opengl: separate kernel and window
This makes the core much more elegant, reusable, reconfigurable and also
allows us to more easily add aliases for specific configurations.
Furthermore, this lets us apply a generic blur factor / window function
to arbitrary filters, so we can finally "mix and match" in order to
fine-tune windowing functions.
A few notes are in order:
1. The current system for configuring scalers is ugly and rapidly
getting unwieldy. I modified the man page to make it a bit more
bearable, but long-term we have to do something about it; especially
since..
2. There's currently no way to affect the blur factor or parameters of
the window functions themselves. For example, I can't actually
fine-tune the kaiser window's param1, since there's simply no way to
do so in the current API - even though filter_kernels.c supports it
just fine!
3. This removes some lesser used filters (especially those which are
purely window functions to begin with). If anybody asks, you can get
eg. the old behavior of scale=hanning by using
scale=box:scale-window=hanning:scale-radius=1 (and yes, the result is
just as terrible as that sounds - which is why nobody should have
been using them in the first place).
4. This changes the semantics of the "triangle" scaler slightly - it now
has an arbitrary radius. This can possibly produce weird results for
people who were previously using scale-down=triangle, especially if
in combination with scale-radius (for the usual upscaling). The
correct fix for this is to use scale-down=bilinear_slow instead,
which is an alias for triangle at radius 1.
In regards to the last point, in future I want to make it so that
filters have a filter-specific "preferred radius" (for the ones that
are arbitrarily tunable), once the configuration system for filters has
been redesigned (in particular in a way that will let us separate scale
and scale-down cleanly). That way, "triangle" can simply have the
preferred radius of 1 by default, while still being tunable. (Rather
than the default radius being hard-coded to 3 always)
2015-03-25 03:40:28 +00:00
|
|
|
// Normalize to preserve energy
|
2012-03-30 23:13:38 +00:00
|
|
|
for (int n = 0; n < filter->size; n++)
|
|
|
|
out_w[n] /= sum;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Fill the given array with weights for the range [0.0, 1.0]. The array is
|
2017-08-27 07:15:50 +00:00
|
|
|
// interpreted as rectangular array of count * filter->size items, with a
|
|
|
|
// stride of `stride` floats in between each array element. (For polar filters,
|
|
|
|
// the `count` indicates the row size and filter->size/stride are ignored)
|
2015-12-05 17:32:36 +00:00
|
|
|
//
|
|
|
|
// There will be slight sampling error if these weights are used in a OpenGL
|
|
|
|
// texture as LUT directly. The sampling point of a texel is located at its
|
|
|
|
// center, so out_array[0] will end up at 0.5 / count instead of 0.0.
|
|
|
|
// Correct lookup requires a linear coordinate mapping from [0.0, 1.0] to
|
|
|
|
// [0.5 / count, 1.0 - 0.5 / count].
|
2017-08-27 07:15:50 +00:00
|
|
|
void mp_compute_lut(struct filter_kernel *filter, int count, int stride,
|
|
|
|
float *out_array)
|
2012-03-30 23:13:38 +00:00
|
|
|
{
|
2015-01-18 15:28:41 +00:00
|
|
|
if (filter->polar) {
|
2017-07-03 09:23:48 +00:00
|
|
|
filter->radius_cutoff = 0.0;
|
2015-01-17 16:28:47 +00:00
|
|
|
// Compute a 1D array indexed by radius
|
2015-01-18 15:28:41 +00:00
|
|
|
for (int x = 0; x < count; x++) {
|
vo_opengl: separate kernel and window
This makes the core much more elegant, reusable, reconfigurable and also
allows us to more easily add aliases for specific configurations.
Furthermore, this lets us apply a generic blur factor / window function
to arbitrary filters, so we can finally "mix and match" in order to
fine-tune windowing functions.
A few notes are in order:
1. The current system for configuring scalers is ugly and rapidly
getting unwieldy. I modified the man page to make it a bit more
bearable, but long-term we have to do something about it; especially
since..
2. There's currently no way to affect the blur factor or parameters of
the window functions themselves. For example, I can't actually
fine-tune the kaiser window's param1, since there's simply no way to
do so in the current API - even though filter_kernels.c supports it
just fine!
3. This removes some lesser used filters (especially those which are
purely window functions to begin with). If anybody asks, you can get
eg. the old behavior of scale=hanning by using
scale=box:scale-window=hanning:scale-radius=1 (and yes, the result is
just as terrible as that sounds - which is why nobody should have
been using them in the first place).
4. This changes the semantics of the "triangle" scaler slightly - it now
has an arbitrary radius. This can possibly produce weird results for
people who were previously using scale-down=triangle, especially if
in combination with scale-radius (for the usual upscaling). The
correct fix for this is to use scale-down=bilinear_slow instead,
which is an alias for triangle at radius 1.
In regards to the last point, in future I want to make it so that
filters have a filter-specific "preferred radius" (for the ones that
are arbitrarily tunable), once the configuration system for filters has
been redesigned (in particular in a way that will let us separate scale
and scale-down cleanly). That way, "triangle" can simply have the
preferred radius of 1 by default, while still being tunable. (Rather
than the default radius being hard-coded to 3 always)
2015-03-25 03:40:28 +00:00
|
|
|
double r = x * filter->f.radius / (count - 1);
|
2016-10-26 14:32:57 +00:00
|
|
|
out_array[x] = sample_filter(filter, r);
|
2017-07-03 09:23:48 +00:00
|
|
|
|
|
|
|
if (fabs(out_array[x]) > filter->value_cutoff)
|
|
|
|
filter->radius_cutoff = r;
|
2015-01-18 15:28:41 +00:00
|
|
|
}
|
|
|
|
} else {
|
2015-01-17 16:28:47 +00:00
|
|
|
// Compute a 2D array indexed by subpixel position
|
2015-01-18 15:28:41 +00:00
|
|
|
for (int n = 0; n < count; n++) {
|
2016-10-26 14:32:57 +00:00
|
|
|
mp_compute_weights(filter, n / (double)(count - 1),
|
2017-08-27 07:15:50 +00:00
|
|
|
out_array + stride * n);
|
2015-01-18 15:28:41 +00:00
|
|
|
}
|
2015-01-04 22:11:27 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
vo_opengl: separate kernel and window
This makes the core much more elegant, reusable, reconfigurable and also
allows us to more easily add aliases for specific configurations.
Furthermore, this lets us apply a generic blur factor / window function
to arbitrary filters, so we can finally "mix and match" in order to
fine-tune windowing functions.
A few notes are in order:
1. The current system for configuring scalers is ugly and rapidly
getting unwieldy. I modified the man page to make it a bit more
bearable, but long-term we have to do something about it; especially
since..
2. There's currently no way to affect the blur factor or parameters of
the window functions themselves. For example, I can't actually
fine-tune the kaiser window's param1, since there's simply no way to
do so in the current API - even though filter_kernels.c supports it
just fine!
3. This removes some lesser used filters (especially those which are
purely window functions to begin with). If anybody asks, you can get
eg. the old behavior of scale=hanning by using
scale=box:scale-window=hanning:scale-radius=1 (and yes, the result is
just as terrible as that sounds - which is why nobody should have
been using them in the first place).
4. This changes the semantics of the "triangle" scaler slightly - it now
has an arbitrary radius. This can possibly produce weird results for
people who were previously using scale-down=triangle, especially if
in combination with scale-radius (for the usual upscaling). The
correct fix for this is to use scale-down=bilinear_slow instead,
which is an alias for triangle at radius 1.
In regards to the last point, in future I want to make it so that
filters have a filter-specific "preferred radius" (for the ones that
are arbitrarily tunable), once the configuration system for filters has
been redesigned (in particular in a way that will let us separate scale
and scale-down cleanly). That way, "triangle" can simply have the
preferred radius of 1 by default, while still being tunable. (Rather
than the default radius being hard-coded to 3 always)
2015-03-25 03:40:28 +00:00
|
|
|
typedef struct filter_window params;
|
2012-03-30 23:13:38 +00:00
|
|
|
|
vo_opengl: separate kernel and window
This makes the core much more elegant, reusable, reconfigurable and also
allows us to more easily add aliases for specific configurations.
Furthermore, this lets us apply a generic blur factor / window function
to arbitrary filters, so we can finally "mix and match" in order to
fine-tune windowing functions.
A few notes are in order:
1. The current system for configuring scalers is ugly and rapidly
getting unwieldy. I modified the man page to make it a bit more
bearable, but long-term we have to do something about it; especially
since..
2. There's currently no way to affect the blur factor or parameters of
the window functions themselves. For example, I can't actually
fine-tune the kaiser window's param1, since there's simply no way to
do so in the current API - even though filter_kernels.c supports it
just fine!
3. This removes some lesser used filters (especially those which are
purely window functions to begin with). If anybody asks, you can get
eg. the old behavior of scale=hanning by using
scale=box:scale-window=hanning:scale-radius=1 (and yes, the result is
just as terrible as that sounds - which is why nobody should have
been using them in the first place).
4. This changes the semantics of the "triangle" scaler slightly - it now
has an arbitrary radius. This can possibly produce weird results for
people who were previously using scale-down=triangle, especially if
in combination with scale-radius (for the usual upscaling). The
correct fix for this is to use scale-down=bilinear_slow instead,
which is an alias for triangle at radius 1.
In regards to the last point, in future I want to make it so that
filters have a filter-specific "preferred radius" (for the ones that
are arbitrarily tunable), once the configuration system for filters has
been redesigned (in particular in a way that will let us separate scale
and scale-down cleanly). That way, "triangle" can simply have the
preferred radius of 1 by default, while still being tunable. (Rather
than the default radius being hard-coded to 3 always)
2015-03-25 03:40:28 +00:00
|
|
|
static double box(params *p, double x)
|
2014-06-03 20:49:22 +00:00
|
|
|
{
|
vo_opengl: separate kernel and window
This makes the core much more elegant, reusable, reconfigurable and also
allows us to more easily add aliases for specific configurations.
Furthermore, this lets us apply a generic blur factor / window function
to arbitrary filters, so we can finally "mix and match" in order to
fine-tune windowing functions.
A few notes are in order:
1. The current system for configuring scalers is ugly and rapidly
getting unwieldy. I modified the man page to make it a bit more
bearable, but long-term we have to do something about it; especially
since..
2. There's currently no way to affect the blur factor or parameters of
the window functions themselves. For example, I can't actually
fine-tune the kaiser window's param1, since there's simply no way to
do so in the current API - even though filter_kernels.c supports it
just fine!
3. This removes some lesser used filters (especially those which are
purely window functions to begin with). If anybody asks, you can get
eg. the old behavior of scale=hanning by using
scale=box:scale-window=hanning:scale-radius=1 (and yes, the result is
just as terrible as that sounds - which is why nobody should have
been using them in the first place).
4. This changes the semantics of the "triangle" scaler slightly - it now
has an arbitrary radius. This can possibly produce weird results for
people who were previously using scale-down=triangle, especially if
in combination with scale-radius (for the usual upscaling). The
correct fix for this is to use scale-down=bilinear_slow instead,
which is an alias for triangle at radius 1.
In regards to the last point, in future I want to make it so that
filters have a filter-specific "preferred radius" (for the ones that
are arbitrarily tunable), once the configuration system for filters has
been redesigned (in particular in a way that will let us separate scale
and scale-down cleanly). That way, "triangle" can simply have the
preferred radius of 1 by default, while still being tunable. (Rather
than the default radius being hard-coded to 3 always)
2015-03-25 03:40:28 +00:00
|
|
|
// This is mathematically 1.0 everywhere, the clipping is done implicitly
|
|
|
|
// based on the radius.
|
|
|
|
return 1.0;
|
2014-06-03 20:49:22 +00:00
|
|
|
}
|
|
|
|
|
vo_opengl: separate kernel and window
This makes the core much more elegant, reusable, reconfigurable and also
allows us to more easily add aliases for specific configurations.
Furthermore, this lets us apply a generic blur factor / window function
to arbitrary filters, so we can finally "mix and match" in order to
fine-tune windowing functions.
A few notes are in order:
1. The current system for configuring scalers is ugly and rapidly
getting unwieldy. I modified the man page to make it a bit more
bearable, but long-term we have to do something about it; especially
since..
2. There's currently no way to affect the blur factor or parameters of
the window functions themselves. For example, I can't actually
fine-tune the kaiser window's param1, since there's simply no way to
do so in the current API - even though filter_kernels.c supports it
just fine!
3. This removes some lesser used filters (especially those which are
purely window functions to begin with). If anybody asks, you can get
eg. the old behavior of scale=hanning by using
scale=box:scale-window=hanning:scale-radius=1 (and yes, the result is
just as terrible as that sounds - which is why nobody should have
been using them in the first place).
4. This changes the semantics of the "triangle" scaler slightly - it now
has an arbitrary radius. This can possibly produce weird results for
people who were previously using scale-down=triangle, especially if
in combination with scale-radius (for the usual upscaling). The
correct fix for this is to use scale-down=bilinear_slow instead,
which is an alias for triangle at radius 1.
In regards to the last point, in future I want to make it so that
filters have a filter-specific "preferred radius" (for the ones that
are arbitrarily tunable), once the configuration system for filters has
been redesigned (in particular in a way that will let us separate scale
and scale-down cleanly). That way, "triangle" can simply have the
preferred radius of 1 by default, while still being tunable. (Rather
than the default radius being hard-coded to 3 always)
2015-03-25 03:40:28 +00:00
|
|
|
static double triangle(params *p, double x)
|
2012-03-30 23:13:38 +00:00
|
|
|
{
|
vo_opengl: separate kernel and window
This makes the core much more elegant, reusable, reconfigurable and also
allows us to more easily add aliases for specific configurations.
Furthermore, this lets us apply a generic blur factor / window function
to arbitrary filters, so we can finally "mix and match" in order to
fine-tune windowing functions.
A few notes are in order:
1. The current system for configuring scalers is ugly and rapidly
getting unwieldy. I modified the man page to make it a bit more
bearable, but long-term we have to do something about it; especially
since..
2. There's currently no way to affect the blur factor or parameters of
the window functions themselves. For example, I can't actually
fine-tune the kaiser window's param1, since there's simply no way to
do so in the current API - even though filter_kernels.c supports it
just fine!
3. This removes some lesser used filters (especially those which are
purely window functions to begin with). If anybody asks, you can get
eg. the old behavior of scale=hanning by using
scale=box:scale-window=hanning:scale-radius=1 (and yes, the result is
just as terrible as that sounds - which is why nobody should have
been using them in the first place).
4. This changes the semantics of the "triangle" scaler slightly - it now
has an arbitrary radius. This can possibly produce weird results for
people who were previously using scale-down=triangle, especially if
in combination with scale-radius (for the usual upscaling). The
correct fix for this is to use scale-down=bilinear_slow instead,
which is an alias for triangle at radius 1.
In regards to the last point, in future I want to make it so that
filters have a filter-specific "preferred radius" (for the ones that
are arbitrarily tunable), once the configuration system for filters has
been redesigned (in particular in a way that will let us separate scale
and scale-down cleanly). That way, "triangle" can simply have the
preferred radius of 1 by default, while still being tunable. (Rather
than the default radius being hard-coded to 3 always)
2015-03-25 03:40:28 +00:00
|
|
|
return fmax(0.0, 1.0 - fabs(x / p->radius));
|
2012-03-30 23:13:38 +00:00
|
|
|
}
|
|
|
|
|
vo_opengl: separate kernel and window
This makes the core much more elegant, reusable, reconfigurable and also
allows us to more easily add aliases for specific configurations.
Furthermore, this lets us apply a generic blur factor / window function
to arbitrary filters, so we can finally "mix and match" in order to
fine-tune windowing functions.
A few notes are in order:
1. The current system for configuring scalers is ugly and rapidly
getting unwieldy. I modified the man page to make it a bit more
bearable, but long-term we have to do something about it; especially
since..
2. There's currently no way to affect the blur factor or parameters of
the window functions themselves. For example, I can't actually
fine-tune the kaiser window's param1, since there's simply no way to
do so in the current API - even though filter_kernels.c supports it
just fine!
3. This removes some lesser used filters (especially those which are
purely window functions to begin with). If anybody asks, you can get
eg. the old behavior of scale=hanning by using
scale=box:scale-window=hanning:scale-radius=1 (and yes, the result is
just as terrible as that sounds - which is why nobody should have
been using them in the first place).
4. This changes the semantics of the "triangle" scaler slightly - it now
has an arbitrary radius. This can possibly produce weird results for
people who were previously using scale-down=triangle, especially if
in combination with scale-radius (for the usual upscaling). The
correct fix for this is to use scale-down=bilinear_slow instead,
which is an alias for triangle at radius 1.
In regards to the last point, in future I want to make it so that
filters have a filter-specific "preferred radius" (for the ones that
are arbitrarily tunable), once the configuration system for filters has
been redesigned (in particular in a way that will let us separate scale
and scale-down cleanly). That way, "triangle" can simply have the
preferred radius of 1 by default, while still being tunable. (Rather
than the default radius being hard-coded to 3 always)
2015-03-25 03:40:28 +00:00
|
|
|
static double hanning(params *p, double x)
|
2012-03-30 23:13:38 +00:00
|
|
|
{
|
|
|
|
return 0.5 + 0.5 * cos(M_PI * x);
|
|
|
|
}
|
|
|
|
|
vo_opengl: separate kernel and window
This makes the core much more elegant, reusable, reconfigurable and also
allows us to more easily add aliases for specific configurations.
Furthermore, this lets us apply a generic blur factor / window function
to arbitrary filters, so we can finally "mix and match" in order to
fine-tune windowing functions.
A few notes are in order:
1. The current system for configuring scalers is ugly and rapidly
getting unwieldy. I modified the man page to make it a bit more
bearable, but long-term we have to do something about it; especially
since..
2. There's currently no way to affect the blur factor or parameters of
the window functions themselves. For example, I can't actually
fine-tune the kaiser window's param1, since there's simply no way to
do so in the current API - even though filter_kernels.c supports it
just fine!
3. This removes some lesser used filters (especially those which are
purely window functions to begin with). If anybody asks, you can get
eg. the old behavior of scale=hanning by using
scale=box:scale-window=hanning:scale-radius=1 (and yes, the result is
just as terrible as that sounds - which is why nobody should have
been using them in the first place).
4. This changes the semantics of the "triangle" scaler slightly - it now
has an arbitrary radius. This can possibly produce weird results for
people who were previously using scale-down=triangle, especially if
in combination with scale-radius (for the usual upscaling). The
correct fix for this is to use scale-down=bilinear_slow instead,
which is an alias for triangle at radius 1.
In regards to the last point, in future I want to make it so that
filters have a filter-specific "preferred radius" (for the ones that
are arbitrarily tunable), once the configuration system for filters has
been redesigned (in particular in a way that will let us separate scale
and scale-down cleanly). That way, "triangle" can simply have the
preferred radius of 1 by default, while still being tunable. (Rather
than the default radius being hard-coded to 3 always)
2015-03-25 03:40:28 +00:00
|
|
|
static double hamming(params *p, double x)
|
2012-03-30 23:13:38 +00:00
|
|
|
{
|
|
|
|
return 0.54 + 0.46 * cos(M_PI * x);
|
|
|
|
}
|
|
|
|
|
vo_opengl: separate kernel and window
This makes the core much more elegant, reusable, reconfigurable and also
allows us to more easily add aliases for specific configurations.
Furthermore, this lets us apply a generic blur factor / window function
to arbitrary filters, so we can finally "mix and match" in order to
fine-tune windowing functions.
A few notes are in order:
1. The current system for configuring scalers is ugly and rapidly
getting unwieldy. I modified the man page to make it a bit more
bearable, but long-term we have to do something about it; especially
since..
2. There's currently no way to affect the blur factor or parameters of
the window functions themselves. For example, I can't actually
fine-tune the kaiser window's param1, since there's simply no way to
do so in the current API - even though filter_kernels.c supports it
just fine!
3. This removes some lesser used filters (especially those which are
purely window functions to begin with). If anybody asks, you can get
eg. the old behavior of scale=hanning by using
scale=box:scale-window=hanning:scale-radius=1 (and yes, the result is
just as terrible as that sounds - which is why nobody should have
been using them in the first place).
4. This changes the semantics of the "triangle" scaler slightly - it now
has an arbitrary radius. This can possibly produce weird results for
people who were previously using scale-down=triangle, especially if
in combination with scale-radius (for the usual upscaling). The
correct fix for this is to use scale-down=bilinear_slow instead,
which is an alias for triangle at radius 1.
In regards to the last point, in future I want to make it so that
filters have a filter-specific "preferred radius" (for the ones that
are arbitrarily tunable), once the configuration system for filters has
been redesigned (in particular in a way that will let us separate scale
and scale-down cleanly). That way, "triangle" can simply have the
preferred radius of 1 by default, while still being tunable. (Rather
than the default radius being hard-coded to 3 always)
2015-03-25 03:40:28 +00:00
|
|
|
static double quadric(params *p, double x)
|
2012-03-30 23:13:38 +00:00
|
|
|
{
|
filter_kernels: replace AGG-based code
This commit replaces code based on AGG, taken from this source file:
http://vector-agg.cvs.sourceforge.net/viewvc/vector-agg/agg-2.5/include/agg_image_filters.h
The intention is that filter_kernels.c can be relicensed to LGPL or BSD.
Because the AGG author died, full replacement is the only way to achieve
it.
This affects only some filter functions. These are exclusively
mathematical functions for computing filter coefficients. (Other parts
in filter_kernel.c were originally written by me, with heavy additions
and refactoring done by other mpv contributors.) While the code is
mostly just well-known mathematical formulas written down in C form,
AGG copyright could perhaps be claimed anyway.
To remove the AGG code, I replaced it with the filter functions from:
https://github.com/glumpy/glumpy/blob/master/glumpy/library/build-spatial-filters.py
These functions conveniently compute exactly the same thing in mpv,
Glumpy, AGG (and about anything that will filter images using the same
mathematical principles).
First I ported the Python code in the file to C. Then I replaced all
functions in filter_kernels.c with this code that could be replaced.
Then I investigated whether the remaining functions were based on AGG
code and took appropriate action:
hanning(), hamming(), quadric(), bicubic(), kaiser(), blackman(),
spline16(), spline36(), gaussian(), sinc() were taken straight from
Glumpy.
For sinc(), re-add the "fabs(x) < 1e-8" check, which was added in commit
586dc557 for unknown reasons.
gaussian() loses its filter parameter for some reason. (Well, who cares,
not my problem.)
The really awkward thing is that the text for hanning() and hamming()
does not change. In theory these functions are now based on Glumpy code,
but it seems like this can be neither proven nor denied. (The same
happened in some other cases with at least a few lines of code.)
sphinx() was added in commit 586dc557, and looks suspiciously like
sinc() as well. Replace the first 3 lines of the body with the ported
function (of which 2 lines do not change; the first uses code only in
mpv, and the second is just "return 1.0;"). The 4th line is only similar
on an abstract level (and that because of the mathematical relation
between these functions). Although the original sinc() was probably used
as template for it, with the other lines replaced, I don't think you
could make the claim that it falls under AGG copyright.
jinc() was added in commit 26baf5b9, but the code for it might be based
on sinc(). Rewrite it based on the "new" sinc(). Some of the same
remarks as with sphinx() apply.
cubic_bc() was ported from Glumpy's Mitchell(). (As far as I'm aware,
with the default parameters it's called "the" Mitchell-Netravali filter,
but in mpv this function is used to generate a whole group of filters.)
spline64() was added in commit a8b67c66, and was probably derived from
spline36(). Re-derive it from the "new" spline36().
triangle() could be considered derived from the original bilinear().
This is this in the original commit:
static double bilinear(kernel *k, double x)
{
return 1.0 - x;
}
This _might_ be based on AGG's image_filter_bilinear:
struct image_filter_bilinear
{
static double radius() { return 1.0; }
static double calc_weight(double x)
{
return 1.0 - x;
}
};
Considering that the "framework" was written by me, and the only part
from AGG taken is "return 1.0 - x;", and this part is trivial and was
later thoroughly replaced, this is probably not under the AGG copyright.
I'm hoping this doesn't introduce regressions. But the main focus is not
being productive anyway, and I didn't rigorously check unintended
changes in functionality.
2016-01-06 17:35:01 +00:00
|
|
|
if (x < 0.75) {
|
2012-03-30 23:13:38 +00:00
|
|
|
return 0.75 - x * x;
|
filter_kernels: replace AGG-based code
This commit replaces code based on AGG, taken from this source file:
http://vector-agg.cvs.sourceforge.net/viewvc/vector-agg/agg-2.5/include/agg_image_filters.h
The intention is that filter_kernels.c can be relicensed to LGPL or BSD.
Because the AGG author died, full replacement is the only way to achieve
it.
This affects only some filter functions. These are exclusively
mathematical functions for computing filter coefficients. (Other parts
in filter_kernel.c were originally written by me, with heavy additions
and refactoring done by other mpv contributors.) While the code is
mostly just well-known mathematical formulas written down in C form,
AGG copyright could perhaps be claimed anyway.
To remove the AGG code, I replaced it with the filter functions from:
https://github.com/glumpy/glumpy/blob/master/glumpy/library/build-spatial-filters.py
These functions conveniently compute exactly the same thing in mpv,
Glumpy, AGG (and about anything that will filter images using the same
mathematical principles).
First I ported the Python code in the file to C. Then I replaced all
functions in filter_kernels.c with this code that could be replaced.
Then I investigated whether the remaining functions were based on AGG
code and took appropriate action:
hanning(), hamming(), quadric(), bicubic(), kaiser(), blackman(),
spline16(), spline36(), gaussian(), sinc() were taken straight from
Glumpy.
For sinc(), re-add the "fabs(x) < 1e-8" check, which was added in commit
586dc557 for unknown reasons.
gaussian() loses its filter parameter for some reason. (Well, who cares,
not my problem.)
The really awkward thing is that the text for hanning() and hamming()
does not change. In theory these functions are now based on Glumpy code,
but it seems like this can be neither proven nor denied. (The same
happened in some other cases with at least a few lines of code.)
sphinx() was added in commit 586dc557, and looks suspiciously like
sinc() as well. Replace the first 3 lines of the body with the ported
function (of which 2 lines do not change; the first uses code only in
mpv, and the second is just "return 1.0;"). The 4th line is only similar
on an abstract level (and that because of the mathematical relation
between these functions). Although the original sinc() was probably used
as template for it, with the other lines replaced, I don't think you
could make the claim that it falls under AGG copyright.
jinc() was added in commit 26baf5b9, but the code for it might be based
on sinc(). Rewrite it based on the "new" sinc(). Some of the same
remarks as with sphinx() apply.
cubic_bc() was ported from Glumpy's Mitchell(). (As far as I'm aware,
with the default parameters it's called "the" Mitchell-Netravali filter,
but in mpv this function is used to generate a whole group of filters.)
spline64() was added in commit a8b67c66, and was probably derived from
spline36(). Re-derive it from the "new" spline36().
triangle() could be considered derived from the original bilinear().
This is this in the original commit:
static double bilinear(kernel *k, double x)
{
return 1.0 - x;
}
This _might_ be based on AGG's image_filter_bilinear:
struct image_filter_bilinear
{
static double radius() { return 1.0; }
static double calc_weight(double x)
{
return 1.0 - x;
}
};
Considering that the "framework" was written by me, and the only part
from AGG taken is "return 1.0 - x;", and this part is trivial and was
later thoroughly replaced, this is probably not under the AGG copyright.
I'm hoping this doesn't introduce regressions. But the main focus is not
being productive anyway, and I didn't rigorously check unintended
changes in functionality.
2016-01-06 17:35:01 +00:00
|
|
|
} else if (x < 1.5) {
|
|
|
|
double t = x - 1.5;
|
|
|
|
return 0.5 * t * t;
|
|
|
|
}
|
|
|
|
return 0.0;
|
2012-03-30 23:13:38 +00:00
|
|
|
}
|
|
|
|
|
filter_kernels: replace AGG-based code
This commit replaces code based on AGG, taken from this source file:
http://vector-agg.cvs.sourceforge.net/viewvc/vector-agg/agg-2.5/include/agg_image_filters.h
The intention is that filter_kernels.c can be relicensed to LGPL or BSD.
Because the AGG author died, full replacement is the only way to achieve
it.
This affects only some filter functions. These are exclusively
mathematical functions for computing filter coefficients. (Other parts
in filter_kernel.c were originally written by me, with heavy additions
and refactoring done by other mpv contributors.) While the code is
mostly just well-known mathematical formulas written down in C form,
AGG copyright could perhaps be claimed anyway.
To remove the AGG code, I replaced it with the filter functions from:
https://github.com/glumpy/glumpy/blob/master/glumpy/library/build-spatial-filters.py
These functions conveniently compute exactly the same thing in mpv,
Glumpy, AGG (and about anything that will filter images using the same
mathematical principles).
First I ported the Python code in the file to C. Then I replaced all
functions in filter_kernels.c with this code that could be replaced.
Then I investigated whether the remaining functions were based on AGG
code and took appropriate action:
hanning(), hamming(), quadric(), bicubic(), kaiser(), blackman(),
spline16(), spline36(), gaussian(), sinc() were taken straight from
Glumpy.
For sinc(), re-add the "fabs(x) < 1e-8" check, which was added in commit
586dc557 for unknown reasons.
gaussian() loses its filter parameter for some reason. (Well, who cares,
not my problem.)
The really awkward thing is that the text for hanning() and hamming()
does not change. In theory these functions are now based on Glumpy code,
but it seems like this can be neither proven nor denied. (The same
happened in some other cases with at least a few lines of code.)
sphinx() was added in commit 586dc557, and looks suspiciously like
sinc() as well. Replace the first 3 lines of the body with the ported
function (of which 2 lines do not change; the first uses code only in
mpv, and the second is just "return 1.0;"). The 4th line is only similar
on an abstract level (and that because of the mathematical relation
between these functions). Although the original sinc() was probably used
as template for it, with the other lines replaced, I don't think you
could make the claim that it falls under AGG copyright.
jinc() was added in commit 26baf5b9, but the code for it might be based
on sinc(). Rewrite it based on the "new" sinc(). Some of the same
remarks as with sphinx() apply.
cubic_bc() was ported from Glumpy's Mitchell(). (As far as I'm aware,
with the default parameters it's called "the" Mitchell-Netravali filter,
but in mpv this function is used to generate a whole group of filters.)
spline64() was added in commit a8b67c66, and was probably derived from
spline36(). Re-derive it from the "new" spline36().
triangle() could be considered derived from the original bilinear().
This is this in the original commit:
static double bilinear(kernel *k, double x)
{
return 1.0 - x;
}
This _might_ be based on AGG's image_filter_bilinear:
struct image_filter_bilinear
{
static double radius() { return 1.0; }
static double calc_weight(double x)
{
return 1.0 - x;
}
};
Considering that the "framework" was written by me, and the only part
from AGG taken is "return 1.0 - x;", and this part is trivial and was
later thoroughly replaced, this is probably not under the AGG copyright.
I'm hoping this doesn't introduce regressions. But the main focus is not
being productive anyway, and I didn't rigorously check unintended
changes in functionality.
2016-01-06 17:35:01 +00:00
|
|
|
#define POW3(x) ((x) <= 0 ? 0 : (x) * (x) * (x))
|
vo_opengl: separate kernel and window
This makes the core much more elegant, reusable, reconfigurable and also
allows us to more easily add aliases for specific configurations.
Furthermore, this lets us apply a generic blur factor / window function
to arbitrary filters, so we can finally "mix and match" in order to
fine-tune windowing functions.
A few notes are in order:
1. The current system for configuring scalers is ugly and rapidly
getting unwieldy. I modified the man page to make it a bit more
bearable, but long-term we have to do something about it; especially
since..
2. There's currently no way to affect the blur factor or parameters of
the window functions themselves. For example, I can't actually
fine-tune the kaiser window's param1, since there's simply no way to
do so in the current API - even though filter_kernels.c supports it
just fine!
3. This removes some lesser used filters (especially those which are
purely window functions to begin with). If anybody asks, you can get
eg. the old behavior of scale=hanning by using
scale=box:scale-window=hanning:scale-radius=1 (and yes, the result is
just as terrible as that sounds - which is why nobody should have
been using them in the first place).
4. This changes the semantics of the "triangle" scaler slightly - it now
has an arbitrary radius. This can possibly produce weird results for
people who were previously using scale-down=triangle, especially if
in combination with scale-radius (for the usual upscaling). The
correct fix for this is to use scale-down=bilinear_slow instead,
which is an alias for triangle at radius 1.
In regards to the last point, in future I want to make it so that
filters have a filter-specific "preferred radius" (for the ones that
are arbitrarily tunable), once the configuration system for filters has
been redesigned (in particular in a way that will let us separate scale
and scale-down cleanly). That way, "triangle" can simply have the
preferred radius of 1 by default, while still being tunable. (Rather
than the default radius being hard-coded to 3 always)
2015-03-25 03:40:28 +00:00
|
|
|
static double bicubic(params *p, double x)
|
2012-03-30 23:13:38 +00:00
|
|
|
{
|
filter_kernels: replace AGG-based code
This commit replaces code based on AGG, taken from this source file:
http://vector-agg.cvs.sourceforge.net/viewvc/vector-agg/agg-2.5/include/agg_image_filters.h
The intention is that filter_kernels.c can be relicensed to LGPL or BSD.
Because the AGG author died, full replacement is the only way to achieve
it.
This affects only some filter functions. These are exclusively
mathematical functions for computing filter coefficients. (Other parts
in filter_kernel.c were originally written by me, with heavy additions
and refactoring done by other mpv contributors.) While the code is
mostly just well-known mathematical formulas written down in C form,
AGG copyright could perhaps be claimed anyway.
To remove the AGG code, I replaced it with the filter functions from:
https://github.com/glumpy/glumpy/blob/master/glumpy/library/build-spatial-filters.py
These functions conveniently compute exactly the same thing in mpv,
Glumpy, AGG (and about anything that will filter images using the same
mathematical principles).
First I ported the Python code in the file to C. Then I replaced all
functions in filter_kernels.c with this code that could be replaced.
Then I investigated whether the remaining functions were based on AGG
code and took appropriate action:
hanning(), hamming(), quadric(), bicubic(), kaiser(), blackman(),
spline16(), spline36(), gaussian(), sinc() were taken straight from
Glumpy.
For sinc(), re-add the "fabs(x) < 1e-8" check, which was added in commit
586dc557 for unknown reasons.
gaussian() loses its filter parameter for some reason. (Well, who cares,
not my problem.)
The really awkward thing is that the text for hanning() and hamming()
does not change. In theory these functions are now based on Glumpy code,
but it seems like this can be neither proven nor denied. (The same
happened in some other cases with at least a few lines of code.)
sphinx() was added in commit 586dc557, and looks suspiciously like
sinc() as well. Replace the first 3 lines of the body with the ported
function (of which 2 lines do not change; the first uses code only in
mpv, and the second is just "return 1.0;"). The 4th line is only similar
on an abstract level (and that because of the mathematical relation
between these functions). Although the original sinc() was probably used
as template for it, with the other lines replaced, I don't think you
could make the claim that it falls under AGG copyright.
jinc() was added in commit 26baf5b9, but the code for it might be based
on sinc(). Rewrite it based on the "new" sinc(). Some of the same
remarks as with sphinx() apply.
cubic_bc() was ported from Glumpy's Mitchell(). (As far as I'm aware,
with the default parameters it's called "the" Mitchell-Netravali filter,
but in mpv this function is used to generate a whole group of filters.)
spline64() was added in commit a8b67c66, and was probably derived from
spline36(). Re-derive it from the "new" spline36().
triangle() could be considered derived from the original bilinear().
This is this in the original commit:
static double bilinear(kernel *k, double x)
{
return 1.0 - x;
}
This _might_ be based on AGG's image_filter_bilinear:
struct image_filter_bilinear
{
static double radius() { return 1.0; }
static double calc_weight(double x)
{
return 1.0 - x;
}
};
Considering that the "framework" was written by me, and the only part
from AGG taken is "return 1.0 - x;", and this part is trivial and was
later thoroughly replaced, this is probably not under the AGG copyright.
I'm hoping this doesn't introduce regressions. But the main focus is not
being productive anyway, and I didn't rigorously check unintended
changes in functionality.
2016-01-06 17:35:01 +00:00
|
|
|
return (1.0/6.0) * ( POW3(x + 2)
|
|
|
|
- 4 * POW3(x + 1)
|
|
|
|
+ 6 * POW3(x)
|
|
|
|
- 4 * POW3(x - 1));
|
2012-03-30 23:13:38 +00:00
|
|
|
}
|
|
|
|
|
filter_kernels: replace AGG-based code
This commit replaces code based on AGG, taken from this source file:
http://vector-agg.cvs.sourceforge.net/viewvc/vector-agg/agg-2.5/include/agg_image_filters.h
The intention is that filter_kernels.c can be relicensed to LGPL or BSD.
Because the AGG author died, full replacement is the only way to achieve
it.
This affects only some filter functions. These are exclusively
mathematical functions for computing filter coefficients. (Other parts
in filter_kernel.c were originally written by me, with heavy additions
and refactoring done by other mpv contributors.) While the code is
mostly just well-known mathematical formulas written down in C form,
AGG copyright could perhaps be claimed anyway.
To remove the AGG code, I replaced it with the filter functions from:
https://github.com/glumpy/glumpy/blob/master/glumpy/library/build-spatial-filters.py
These functions conveniently compute exactly the same thing in mpv,
Glumpy, AGG (and about anything that will filter images using the same
mathematical principles).
First I ported the Python code in the file to C. Then I replaced all
functions in filter_kernels.c with this code that could be replaced.
Then I investigated whether the remaining functions were based on AGG
code and took appropriate action:
hanning(), hamming(), quadric(), bicubic(), kaiser(), blackman(),
spline16(), spline36(), gaussian(), sinc() were taken straight from
Glumpy.
For sinc(), re-add the "fabs(x) < 1e-8" check, which was added in commit
586dc557 for unknown reasons.
gaussian() loses its filter parameter for some reason. (Well, who cares,
not my problem.)
The really awkward thing is that the text for hanning() and hamming()
does not change. In theory these functions are now based on Glumpy code,
but it seems like this can be neither proven nor denied. (The same
happened in some other cases with at least a few lines of code.)
sphinx() was added in commit 586dc557, and looks suspiciously like
sinc() as well. Replace the first 3 lines of the body with the ported
function (of which 2 lines do not change; the first uses code only in
mpv, and the second is just "return 1.0;"). The 4th line is only similar
on an abstract level (and that because of the mathematical relation
between these functions). Although the original sinc() was probably used
as template for it, with the other lines replaced, I don't think you
could make the claim that it falls under AGG copyright.
jinc() was added in commit 26baf5b9, but the code for it might be based
on sinc(). Rewrite it based on the "new" sinc(). Some of the same
remarks as with sphinx() apply.
cubic_bc() was ported from Glumpy's Mitchell(). (As far as I'm aware,
with the default parameters it's called "the" Mitchell-Netravali filter,
but in mpv this function is used to generate a whole group of filters.)
spline64() was added in commit a8b67c66, and was probably derived from
spline36(). Re-derive it from the "new" spline36().
triangle() could be considered derived from the original bilinear().
This is this in the original commit:
static double bilinear(kernel *k, double x)
{
return 1.0 - x;
}
This _might_ be based on AGG's image_filter_bilinear:
struct image_filter_bilinear
{
static double radius() { return 1.0; }
static double calc_weight(double x)
{
return 1.0 - x;
}
};
Considering that the "framework" was written by me, and the only part
from AGG taken is "return 1.0 - x;", and this part is trivial and was
later thoroughly replaced, this is probably not under the AGG copyright.
I'm hoping this doesn't introduce regressions. But the main focus is not
being productive anyway, and I didn't rigorously check unintended
changes in functionality.
2016-01-06 17:35:01 +00:00
|
|
|
static double bessel_i0(double x)
|
2012-03-30 23:13:38 +00:00
|
|
|
{
|
filter_kernels: replace AGG-based code
This commit replaces code based on AGG, taken from this source file:
http://vector-agg.cvs.sourceforge.net/viewvc/vector-agg/agg-2.5/include/agg_image_filters.h
The intention is that filter_kernels.c can be relicensed to LGPL or BSD.
Because the AGG author died, full replacement is the only way to achieve
it.
This affects only some filter functions. These are exclusively
mathematical functions for computing filter coefficients. (Other parts
in filter_kernel.c were originally written by me, with heavy additions
and refactoring done by other mpv contributors.) While the code is
mostly just well-known mathematical formulas written down in C form,
AGG copyright could perhaps be claimed anyway.
To remove the AGG code, I replaced it with the filter functions from:
https://github.com/glumpy/glumpy/blob/master/glumpy/library/build-spatial-filters.py
These functions conveniently compute exactly the same thing in mpv,
Glumpy, AGG (and about anything that will filter images using the same
mathematical principles).
First I ported the Python code in the file to C. Then I replaced all
functions in filter_kernels.c with this code that could be replaced.
Then I investigated whether the remaining functions were based on AGG
code and took appropriate action:
hanning(), hamming(), quadric(), bicubic(), kaiser(), blackman(),
spline16(), spline36(), gaussian(), sinc() were taken straight from
Glumpy.
For sinc(), re-add the "fabs(x) < 1e-8" check, which was added in commit
586dc557 for unknown reasons.
gaussian() loses its filter parameter for some reason. (Well, who cares,
not my problem.)
The really awkward thing is that the text for hanning() and hamming()
does not change. In theory these functions are now based on Glumpy code,
but it seems like this can be neither proven nor denied. (The same
happened in some other cases with at least a few lines of code.)
sphinx() was added in commit 586dc557, and looks suspiciously like
sinc() as well. Replace the first 3 lines of the body with the ported
function (of which 2 lines do not change; the first uses code only in
mpv, and the second is just "return 1.0;"). The 4th line is only similar
on an abstract level (and that because of the mathematical relation
between these functions). Although the original sinc() was probably used
as template for it, with the other lines replaced, I don't think you
could make the claim that it falls under AGG copyright.
jinc() was added in commit 26baf5b9, but the code for it might be based
on sinc(). Rewrite it based on the "new" sinc(). Some of the same
remarks as with sphinx() apply.
cubic_bc() was ported from Glumpy's Mitchell(). (As far as I'm aware,
with the default parameters it's called "the" Mitchell-Netravali filter,
but in mpv this function is used to generate a whole group of filters.)
spline64() was added in commit a8b67c66, and was probably derived from
spline36(). Re-derive it from the "new" spline36().
triangle() could be considered derived from the original bilinear().
This is this in the original commit:
static double bilinear(kernel *k, double x)
{
return 1.0 - x;
}
This _might_ be based on AGG's image_filter_bilinear:
struct image_filter_bilinear
{
static double radius() { return 1.0; }
static double calc_weight(double x)
{
return 1.0 - x;
}
};
Considering that the "framework" was written by me, and the only part
from AGG taken is "return 1.0 - x;", and this part is trivial and was
later thoroughly replaced, this is probably not under the AGG copyright.
I'm hoping this doesn't introduce regressions. But the main focus is not
being productive anyway, and I didn't rigorously check unintended
changes in functionality.
2016-01-06 17:35:01 +00:00
|
|
|
double s = 1.0;
|
|
|
|
double y = x * x / 4.0;
|
2012-03-30 23:13:38 +00:00
|
|
|
double t = y;
|
filter_kernels: replace AGG-based code
This commit replaces code based on AGG, taken from this source file:
http://vector-agg.cvs.sourceforge.net/viewvc/vector-agg/agg-2.5/include/agg_image_filters.h
The intention is that filter_kernels.c can be relicensed to LGPL or BSD.
Because the AGG author died, full replacement is the only way to achieve
it.
This affects only some filter functions. These are exclusively
mathematical functions for computing filter coefficients. (Other parts
in filter_kernel.c were originally written by me, with heavy additions
and refactoring done by other mpv contributors.) While the code is
mostly just well-known mathematical formulas written down in C form,
AGG copyright could perhaps be claimed anyway.
To remove the AGG code, I replaced it with the filter functions from:
https://github.com/glumpy/glumpy/blob/master/glumpy/library/build-spatial-filters.py
These functions conveniently compute exactly the same thing in mpv,
Glumpy, AGG (and about anything that will filter images using the same
mathematical principles).
First I ported the Python code in the file to C. Then I replaced all
functions in filter_kernels.c with this code that could be replaced.
Then I investigated whether the remaining functions were based on AGG
code and took appropriate action:
hanning(), hamming(), quadric(), bicubic(), kaiser(), blackman(),
spline16(), spline36(), gaussian(), sinc() were taken straight from
Glumpy.
For sinc(), re-add the "fabs(x) < 1e-8" check, which was added in commit
586dc557 for unknown reasons.
gaussian() loses its filter parameter for some reason. (Well, who cares,
not my problem.)
The really awkward thing is that the text for hanning() and hamming()
does not change. In theory these functions are now based on Glumpy code,
but it seems like this can be neither proven nor denied. (The same
happened in some other cases with at least a few lines of code.)
sphinx() was added in commit 586dc557, and looks suspiciously like
sinc() as well. Replace the first 3 lines of the body with the ported
function (of which 2 lines do not change; the first uses code only in
mpv, and the second is just "return 1.0;"). The 4th line is only similar
on an abstract level (and that because of the mathematical relation
between these functions). Although the original sinc() was probably used
as template for it, with the other lines replaced, I don't think you
could make the claim that it falls under AGG copyright.
jinc() was added in commit 26baf5b9, but the code for it might be based
on sinc(). Rewrite it based on the "new" sinc(). Some of the same
remarks as with sphinx() apply.
cubic_bc() was ported from Glumpy's Mitchell(). (As far as I'm aware,
with the default parameters it's called "the" Mitchell-Netravali filter,
but in mpv this function is used to generate a whole group of filters.)
spline64() was added in commit a8b67c66, and was probably derived from
spline36(). Re-derive it from the "new" spline36().
triangle() could be considered derived from the original bilinear().
This is this in the original commit:
static double bilinear(kernel *k, double x)
{
return 1.0 - x;
}
This _might_ be based on AGG's image_filter_bilinear:
struct image_filter_bilinear
{
static double radius() { return 1.0; }
static double calc_weight(double x)
{
return 1.0 - x;
}
};
Considering that the "framework" was written by me, and the only part
from AGG taken is "return 1.0 - x;", and this part is trivial and was
later thoroughly replaced, this is probably not under the AGG copyright.
I'm hoping this doesn't introduce regressions. But the main focus is not
being productive anyway, and I didn't rigorously check unintended
changes in functionality.
2016-01-06 17:35:01 +00:00
|
|
|
int i = 2;
|
|
|
|
while (t > 1e-12) {
|
|
|
|
s += t;
|
2012-03-30 23:13:38 +00:00
|
|
|
t *= y / (i * i);
|
filter_kernels: replace AGG-based code
This commit replaces code based on AGG, taken from this source file:
http://vector-agg.cvs.sourceforge.net/viewvc/vector-agg/agg-2.5/include/agg_image_filters.h
The intention is that filter_kernels.c can be relicensed to LGPL or BSD.
Because the AGG author died, full replacement is the only way to achieve
it.
This affects only some filter functions. These are exclusively
mathematical functions for computing filter coefficients. (Other parts
in filter_kernel.c were originally written by me, with heavy additions
and refactoring done by other mpv contributors.) While the code is
mostly just well-known mathematical formulas written down in C form,
AGG copyright could perhaps be claimed anyway.
To remove the AGG code, I replaced it with the filter functions from:
https://github.com/glumpy/glumpy/blob/master/glumpy/library/build-spatial-filters.py
These functions conveniently compute exactly the same thing in mpv,
Glumpy, AGG (and about anything that will filter images using the same
mathematical principles).
First I ported the Python code in the file to C. Then I replaced all
functions in filter_kernels.c with this code that could be replaced.
Then I investigated whether the remaining functions were based on AGG
code and took appropriate action:
hanning(), hamming(), quadric(), bicubic(), kaiser(), blackman(),
spline16(), spline36(), gaussian(), sinc() were taken straight from
Glumpy.
For sinc(), re-add the "fabs(x) < 1e-8" check, which was added in commit
586dc557 for unknown reasons.
gaussian() loses its filter parameter for some reason. (Well, who cares,
not my problem.)
The really awkward thing is that the text for hanning() and hamming()
does not change. In theory these functions are now based on Glumpy code,
but it seems like this can be neither proven nor denied. (The same
happened in some other cases with at least a few lines of code.)
sphinx() was added in commit 586dc557, and looks suspiciously like
sinc() as well. Replace the first 3 lines of the body with the ported
function (of which 2 lines do not change; the first uses code only in
mpv, and the second is just "return 1.0;"). The 4th line is only similar
on an abstract level (and that because of the mathematical relation
between these functions). Although the original sinc() was probably used
as template for it, with the other lines replaced, I don't think you
could make the claim that it falls under AGG copyright.
jinc() was added in commit 26baf5b9, but the code for it might be based
on sinc(). Rewrite it based on the "new" sinc(). Some of the same
remarks as with sphinx() apply.
cubic_bc() was ported from Glumpy's Mitchell(). (As far as I'm aware,
with the default parameters it's called "the" Mitchell-Netravali filter,
but in mpv this function is used to generate a whole group of filters.)
spline64() was added in commit a8b67c66, and was probably derived from
spline36(). Re-derive it from the "new" spline36().
triangle() could be considered derived from the original bilinear().
This is this in the original commit:
static double bilinear(kernel *k, double x)
{
return 1.0 - x;
}
This _might_ be based on AGG's image_filter_bilinear:
struct image_filter_bilinear
{
static double radius() { return 1.0; }
static double calc_weight(double x)
{
return 1.0 - x;
}
};
Considering that the "framework" was written by me, and the only part
from AGG taken is "return 1.0 - x;", and this part is trivial and was
later thoroughly replaced, this is probably not under the AGG copyright.
I'm hoping this doesn't introduce regressions. But the main focus is not
being productive anyway, and I didn't rigorously check unintended
changes in functionality.
2016-01-06 17:35:01 +00:00
|
|
|
i += 1;
|
2012-03-30 23:13:38 +00:00
|
|
|
}
|
filter_kernels: replace AGG-based code
This commit replaces code based on AGG, taken from this source file:
http://vector-agg.cvs.sourceforge.net/viewvc/vector-agg/agg-2.5/include/agg_image_filters.h
The intention is that filter_kernels.c can be relicensed to LGPL or BSD.
Because the AGG author died, full replacement is the only way to achieve
it.
This affects only some filter functions. These are exclusively
mathematical functions for computing filter coefficients. (Other parts
in filter_kernel.c were originally written by me, with heavy additions
and refactoring done by other mpv contributors.) While the code is
mostly just well-known mathematical formulas written down in C form,
AGG copyright could perhaps be claimed anyway.
To remove the AGG code, I replaced it with the filter functions from:
https://github.com/glumpy/glumpy/blob/master/glumpy/library/build-spatial-filters.py
These functions conveniently compute exactly the same thing in mpv,
Glumpy, AGG (and about anything that will filter images using the same
mathematical principles).
First I ported the Python code in the file to C. Then I replaced all
functions in filter_kernels.c with this code that could be replaced.
Then I investigated whether the remaining functions were based on AGG
code and took appropriate action:
hanning(), hamming(), quadric(), bicubic(), kaiser(), blackman(),
spline16(), spline36(), gaussian(), sinc() were taken straight from
Glumpy.
For sinc(), re-add the "fabs(x) < 1e-8" check, which was added in commit
586dc557 for unknown reasons.
gaussian() loses its filter parameter for some reason. (Well, who cares,
not my problem.)
The really awkward thing is that the text for hanning() and hamming()
does not change. In theory these functions are now based on Glumpy code,
but it seems like this can be neither proven nor denied. (The same
happened in some other cases with at least a few lines of code.)
sphinx() was added in commit 586dc557, and looks suspiciously like
sinc() as well. Replace the first 3 lines of the body with the ported
function (of which 2 lines do not change; the first uses code only in
mpv, and the second is just "return 1.0;"). The 4th line is only similar
on an abstract level (and that because of the mathematical relation
between these functions). Although the original sinc() was probably used
as template for it, with the other lines replaced, I don't think you
could make the claim that it falls under AGG copyright.
jinc() was added in commit 26baf5b9, but the code for it might be based
on sinc(). Rewrite it based on the "new" sinc(). Some of the same
remarks as with sphinx() apply.
cubic_bc() was ported from Glumpy's Mitchell(). (As far as I'm aware,
with the default parameters it's called "the" Mitchell-Netravali filter,
but in mpv this function is used to generate a whole group of filters.)
spline64() was added in commit a8b67c66, and was probably derived from
spline36(). Re-derive it from the "new" spline36().
triangle() could be considered derived from the original bilinear().
This is this in the original commit:
static double bilinear(kernel *k, double x)
{
return 1.0 - x;
}
This _might_ be based on AGG's image_filter_bilinear:
struct image_filter_bilinear
{
static double radius() { return 1.0; }
static double calc_weight(double x)
{
return 1.0 - x;
}
};
Considering that the "framework" was written by me, and the only part
from AGG taken is "return 1.0 - x;", and this part is trivial and was
later thoroughly replaced, this is probably not under the AGG copyright.
I'm hoping this doesn't introduce regressions. But the main focus is not
being productive anyway, and I didn't rigorously check unintended
changes in functionality.
2016-01-06 17:35:01 +00:00
|
|
|
return s;
|
2012-03-30 23:13:38 +00:00
|
|
|
}
|
|
|
|
|
vo_opengl: separate kernel and window
This makes the core much more elegant, reusable, reconfigurable and also
allows us to more easily add aliases for specific configurations.
Furthermore, this lets us apply a generic blur factor / window function
to arbitrary filters, so we can finally "mix and match" in order to
fine-tune windowing functions.
A few notes are in order:
1. The current system for configuring scalers is ugly and rapidly
getting unwieldy. I modified the man page to make it a bit more
bearable, but long-term we have to do something about it; especially
since..
2. There's currently no way to affect the blur factor or parameters of
the window functions themselves. For example, I can't actually
fine-tune the kaiser window's param1, since there's simply no way to
do so in the current API - even though filter_kernels.c supports it
just fine!
3. This removes some lesser used filters (especially those which are
purely window functions to begin with). If anybody asks, you can get
eg. the old behavior of scale=hanning by using
scale=box:scale-window=hanning:scale-radius=1 (and yes, the result is
just as terrible as that sounds - which is why nobody should have
been using them in the first place).
4. This changes the semantics of the "triangle" scaler slightly - it now
has an arbitrary radius. This can possibly produce weird results for
people who were previously using scale-down=triangle, especially if
in combination with scale-radius (for the usual upscaling). The
correct fix for this is to use scale-down=bilinear_slow instead,
which is an alias for triangle at radius 1.
In regards to the last point, in future I want to make it so that
filters have a filter-specific "preferred radius" (for the ones that
are arbitrarily tunable), once the configuration system for filters has
been redesigned (in particular in a way that will let us separate scale
and scale-down cleanly). That way, "triangle" can simply have the
preferred radius of 1 by default, while still being tunable. (Rather
than the default radius being hard-coded to 3 always)
2015-03-25 03:40:28 +00:00
|
|
|
static double kaiser(params *p, double x)
|
2012-03-30 23:13:38 +00:00
|
|
|
{
|
filter_kernels: replace AGG-based code
This commit replaces code based on AGG, taken from this source file:
http://vector-agg.cvs.sourceforge.net/viewvc/vector-agg/agg-2.5/include/agg_image_filters.h
The intention is that filter_kernels.c can be relicensed to LGPL or BSD.
Because the AGG author died, full replacement is the only way to achieve
it.
This affects only some filter functions. These are exclusively
mathematical functions for computing filter coefficients. (Other parts
in filter_kernel.c were originally written by me, with heavy additions
and refactoring done by other mpv contributors.) While the code is
mostly just well-known mathematical formulas written down in C form,
AGG copyright could perhaps be claimed anyway.
To remove the AGG code, I replaced it with the filter functions from:
https://github.com/glumpy/glumpy/blob/master/glumpy/library/build-spatial-filters.py
These functions conveniently compute exactly the same thing in mpv,
Glumpy, AGG (and about anything that will filter images using the same
mathematical principles).
First I ported the Python code in the file to C. Then I replaced all
functions in filter_kernels.c with this code that could be replaced.
Then I investigated whether the remaining functions were based on AGG
code and took appropriate action:
hanning(), hamming(), quadric(), bicubic(), kaiser(), blackman(),
spline16(), spline36(), gaussian(), sinc() were taken straight from
Glumpy.
For sinc(), re-add the "fabs(x) < 1e-8" check, which was added in commit
586dc557 for unknown reasons.
gaussian() loses its filter parameter for some reason. (Well, who cares,
not my problem.)
The really awkward thing is that the text for hanning() and hamming()
does not change. In theory these functions are now based on Glumpy code,
but it seems like this can be neither proven nor denied. (The same
happened in some other cases with at least a few lines of code.)
sphinx() was added in commit 586dc557, and looks suspiciously like
sinc() as well. Replace the first 3 lines of the body with the ported
function (of which 2 lines do not change; the first uses code only in
mpv, and the second is just "return 1.0;"). The 4th line is only similar
on an abstract level (and that because of the mathematical relation
between these functions). Although the original sinc() was probably used
as template for it, with the other lines replaced, I don't think you
could make the claim that it falls under AGG copyright.
jinc() was added in commit 26baf5b9, but the code for it might be based
on sinc(). Rewrite it based on the "new" sinc(). Some of the same
remarks as with sphinx() apply.
cubic_bc() was ported from Glumpy's Mitchell(). (As far as I'm aware,
with the default parameters it's called "the" Mitchell-Netravali filter,
but in mpv this function is used to generate a whole group of filters.)
spline64() was added in commit a8b67c66, and was probably derived from
spline36(). Re-derive it from the "new" spline36().
triangle() could be considered derived from the original bilinear().
This is this in the original commit:
static double bilinear(kernel *k, double x)
{
return 1.0 - x;
}
This _might_ be based on AGG's image_filter_bilinear:
struct image_filter_bilinear
{
static double radius() { return 1.0; }
static double calc_weight(double x)
{
return 1.0 - x;
}
};
Considering that the "framework" was written by me, and the only part
from AGG taken is "return 1.0 - x;", and this part is trivial and was
later thoroughly replaced, this is probably not under the AGG copyright.
I'm hoping this doesn't introduce regressions. But the main focus is not
being productive anyway, and I didn't rigorously check unintended
changes in functionality.
2016-01-06 17:35:01 +00:00
|
|
|
if (x > 1)
|
|
|
|
return 0;
|
|
|
|
double i0a = 1.0 / bessel_i0(p->params[1]);
|
|
|
|
return bessel_i0(p->params[0] * sqrt(1.0 - x * x)) * i0a;
|
2012-03-30 23:13:38 +00:00
|
|
|
}
|
|
|
|
|
2015-03-27 05:36:27 +00:00
|
|
|
static double blackman(params *p, double x)
|
|
|
|
{
|
|
|
|
double a = p->params[0];
|
|
|
|
double a0 = (1-a)/2.0, a1 = 1/2.0, a2 = a/2.0;
|
|
|
|
double pix = M_PI * x;
|
|
|
|
return a0 + a1*cos(pix) + a2*cos(2 * pix);
|
|
|
|
}
|
|
|
|
|
|
|
|
static double welch(params *p, double x)
|
|
|
|
{
|
|
|
|
return 1.0 - x*x;
|
|
|
|
}
|
|
|
|
|
2015-02-24 00:32:45 +00:00
|
|
|
// Family of cubic B/C splines
|
vo_opengl: separate kernel and window
This makes the core much more elegant, reusable, reconfigurable and also
allows us to more easily add aliases for specific configurations.
Furthermore, this lets us apply a generic blur factor / window function
to arbitrary filters, so we can finally "mix and match" in order to
fine-tune windowing functions.
A few notes are in order:
1. The current system for configuring scalers is ugly and rapidly
getting unwieldy. I modified the man page to make it a bit more
bearable, but long-term we have to do something about it; especially
since..
2. There's currently no way to affect the blur factor or parameters of
the window functions themselves. For example, I can't actually
fine-tune the kaiser window's param1, since there's simply no way to
do so in the current API - even though filter_kernels.c supports it
just fine!
3. This removes some lesser used filters (especially those which are
purely window functions to begin with). If anybody asks, you can get
eg. the old behavior of scale=hanning by using
scale=box:scale-window=hanning:scale-radius=1 (and yes, the result is
just as terrible as that sounds - which is why nobody should have
been using them in the first place).
4. This changes the semantics of the "triangle" scaler slightly - it now
has an arbitrary radius. This can possibly produce weird results for
people who were previously using scale-down=triangle, especially if
in combination with scale-radius (for the usual upscaling). The
correct fix for this is to use scale-down=bilinear_slow instead,
which is an alias for triangle at radius 1.
In regards to the last point, in future I want to make it so that
filters have a filter-specific "preferred radius" (for the ones that
are arbitrarily tunable), once the configuration system for filters has
been redesigned (in particular in a way that will let us separate scale
and scale-down cleanly). That way, "triangle" can simply have the
preferred radius of 1 by default, while still being tunable. (Rather
than the default radius being hard-coded to 3 always)
2015-03-25 03:40:28 +00:00
|
|
|
static double cubic_bc(params *p, double x)
|
2012-03-30 23:13:38 +00:00
|
|
|
{
|
filter_kernels: replace AGG-based code
This commit replaces code based on AGG, taken from this source file:
http://vector-agg.cvs.sourceforge.net/viewvc/vector-agg/agg-2.5/include/agg_image_filters.h
The intention is that filter_kernels.c can be relicensed to LGPL or BSD.
Because the AGG author died, full replacement is the only way to achieve
it.
This affects only some filter functions. These are exclusively
mathematical functions for computing filter coefficients. (Other parts
in filter_kernel.c were originally written by me, with heavy additions
and refactoring done by other mpv contributors.) While the code is
mostly just well-known mathematical formulas written down in C form,
AGG copyright could perhaps be claimed anyway.
To remove the AGG code, I replaced it with the filter functions from:
https://github.com/glumpy/glumpy/blob/master/glumpy/library/build-spatial-filters.py
These functions conveniently compute exactly the same thing in mpv,
Glumpy, AGG (and about anything that will filter images using the same
mathematical principles).
First I ported the Python code in the file to C. Then I replaced all
functions in filter_kernels.c with this code that could be replaced.
Then I investigated whether the remaining functions were based on AGG
code and took appropriate action:
hanning(), hamming(), quadric(), bicubic(), kaiser(), blackman(),
spline16(), spline36(), gaussian(), sinc() were taken straight from
Glumpy.
For sinc(), re-add the "fabs(x) < 1e-8" check, which was added in commit
586dc557 for unknown reasons.
gaussian() loses its filter parameter for some reason. (Well, who cares,
not my problem.)
The really awkward thing is that the text for hanning() and hamming()
does not change. In theory these functions are now based on Glumpy code,
but it seems like this can be neither proven nor denied. (The same
happened in some other cases with at least a few lines of code.)
sphinx() was added in commit 586dc557, and looks suspiciously like
sinc() as well. Replace the first 3 lines of the body with the ported
function (of which 2 lines do not change; the first uses code only in
mpv, and the second is just "return 1.0;"). The 4th line is only similar
on an abstract level (and that because of the mathematical relation
between these functions). Although the original sinc() was probably used
as template for it, with the other lines replaced, I don't think you
could make the claim that it falls under AGG copyright.
jinc() was added in commit 26baf5b9, but the code for it might be based
on sinc(). Rewrite it based on the "new" sinc(). Some of the same
remarks as with sphinx() apply.
cubic_bc() was ported from Glumpy's Mitchell(). (As far as I'm aware,
with the default parameters it's called "the" Mitchell-Netravali filter,
but in mpv this function is used to generate a whole group of filters.)
spline64() was added in commit a8b67c66, and was probably derived from
spline36(). Re-derive it from the "new" spline36().
triangle() could be considered derived from the original bilinear().
This is this in the original commit:
static double bilinear(kernel *k, double x)
{
return 1.0 - x;
}
This _might_ be based on AGG's image_filter_bilinear:
struct image_filter_bilinear
{
static double radius() { return 1.0; }
static double calc_weight(double x)
{
return 1.0 - x;
}
};
Considering that the "framework" was written by me, and the only part
from AGG taken is "return 1.0 - x;", and this part is trivial and was
later thoroughly replaced, this is probably not under the AGG copyright.
I'm hoping this doesn't introduce regressions. But the main focus is not
being productive anyway, and I didn't rigorously check unintended
changes in functionality.
2016-01-06 17:35:01 +00:00
|
|
|
double b = p->params[0],
|
|
|
|
c = p->params[1];
|
|
|
|
double p0 = (6.0 - 2.0 * b) / 6.0,
|
|
|
|
p2 = (-18.0 + 12.0 * b + 6.0 * c) / 6.0,
|
|
|
|
p3 = (12.0 - 9.0 * b - 6.0 * c) / 6.0,
|
|
|
|
q0 = (8.0 * b + 24.0 * c) / 6.0,
|
|
|
|
q1 = (-12.0 * b - 48.0 * c) / 6.0,
|
|
|
|
q2 = (6.0 * b + 30.0 * c) / 6.0,
|
|
|
|
q3 = (-b - 6.0 * c) / 6.0;
|
|
|
|
|
|
|
|
if (x < 1.0) {
|
2012-03-30 23:13:38 +00:00
|
|
|
return p0 + x * x * (p2 + x * p3);
|
filter_kernels: replace AGG-based code
This commit replaces code based on AGG, taken from this source file:
http://vector-agg.cvs.sourceforge.net/viewvc/vector-agg/agg-2.5/include/agg_image_filters.h
The intention is that filter_kernels.c can be relicensed to LGPL or BSD.
Because the AGG author died, full replacement is the only way to achieve
it.
This affects only some filter functions. These are exclusively
mathematical functions for computing filter coefficients. (Other parts
in filter_kernel.c were originally written by me, with heavy additions
and refactoring done by other mpv contributors.) While the code is
mostly just well-known mathematical formulas written down in C form,
AGG copyright could perhaps be claimed anyway.
To remove the AGG code, I replaced it with the filter functions from:
https://github.com/glumpy/glumpy/blob/master/glumpy/library/build-spatial-filters.py
These functions conveniently compute exactly the same thing in mpv,
Glumpy, AGG (and about anything that will filter images using the same
mathematical principles).
First I ported the Python code in the file to C. Then I replaced all
functions in filter_kernels.c with this code that could be replaced.
Then I investigated whether the remaining functions were based on AGG
code and took appropriate action:
hanning(), hamming(), quadric(), bicubic(), kaiser(), blackman(),
spline16(), spline36(), gaussian(), sinc() were taken straight from
Glumpy.
For sinc(), re-add the "fabs(x) < 1e-8" check, which was added in commit
586dc557 for unknown reasons.
gaussian() loses its filter parameter for some reason. (Well, who cares,
not my problem.)
The really awkward thing is that the text for hanning() and hamming()
does not change. In theory these functions are now based on Glumpy code,
but it seems like this can be neither proven nor denied. (The same
happened in some other cases with at least a few lines of code.)
sphinx() was added in commit 586dc557, and looks suspiciously like
sinc() as well. Replace the first 3 lines of the body with the ported
function (of which 2 lines do not change; the first uses code only in
mpv, and the second is just "return 1.0;"). The 4th line is only similar
on an abstract level (and that because of the mathematical relation
between these functions). Although the original sinc() was probably used
as template for it, with the other lines replaced, I don't think you
could make the claim that it falls under AGG copyright.
jinc() was added in commit 26baf5b9, but the code for it might be based
on sinc(). Rewrite it based on the "new" sinc(). Some of the same
remarks as with sphinx() apply.
cubic_bc() was ported from Glumpy's Mitchell(). (As far as I'm aware,
with the default parameters it's called "the" Mitchell-Netravali filter,
but in mpv this function is used to generate a whole group of filters.)
spline64() was added in commit a8b67c66, and was probably derived from
spline36(). Re-derive it from the "new" spline36().
triangle() could be considered derived from the original bilinear().
This is this in the original commit:
static double bilinear(kernel *k, double x)
{
return 1.0 - x;
}
This _might_ be based on AGG's image_filter_bilinear:
struct image_filter_bilinear
{
static double radius() { return 1.0; }
static double calc_weight(double x)
{
return 1.0 - x;
}
};
Considering that the "framework" was written by me, and the only part
from AGG taken is "return 1.0 - x;", and this part is trivial and was
later thoroughly replaced, this is probably not under the AGG copyright.
I'm hoping this doesn't introduce regressions. But the main focus is not
being productive anyway, and I didn't rigorously check unintended
changes in functionality.
2016-01-06 17:35:01 +00:00
|
|
|
} else if (x < 2.0) {
|
2012-03-30 23:13:38 +00:00
|
|
|
return q0 + x * (q1 + x * (q2 + x * q3));
|
filter_kernels: replace AGG-based code
This commit replaces code based on AGG, taken from this source file:
http://vector-agg.cvs.sourceforge.net/viewvc/vector-agg/agg-2.5/include/agg_image_filters.h
The intention is that filter_kernels.c can be relicensed to LGPL or BSD.
Because the AGG author died, full replacement is the only way to achieve
it.
This affects only some filter functions. These are exclusively
mathematical functions for computing filter coefficients. (Other parts
in filter_kernel.c were originally written by me, with heavy additions
and refactoring done by other mpv contributors.) While the code is
mostly just well-known mathematical formulas written down in C form,
AGG copyright could perhaps be claimed anyway.
To remove the AGG code, I replaced it with the filter functions from:
https://github.com/glumpy/glumpy/blob/master/glumpy/library/build-spatial-filters.py
These functions conveniently compute exactly the same thing in mpv,
Glumpy, AGG (and about anything that will filter images using the same
mathematical principles).
First I ported the Python code in the file to C. Then I replaced all
functions in filter_kernels.c with this code that could be replaced.
Then I investigated whether the remaining functions were based on AGG
code and took appropriate action:
hanning(), hamming(), quadric(), bicubic(), kaiser(), blackman(),
spline16(), spline36(), gaussian(), sinc() were taken straight from
Glumpy.
For sinc(), re-add the "fabs(x) < 1e-8" check, which was added in commit
586dc557 for unknown reasons.
gaussian() loses its filter parameter for some reason. (Well, who cares,
not my problem.)
The really awkward thing is that the text for hanning() and hamming()
does not change. In theory these functions are now based on Glumpy code,
but it seems like this can be neither proven nor denied. (The same
happened in some other cases with at least a few lines of code.)
sphinx() was added in commit 586dc557, and looks suspiciously like
sinc() as well. Replace the first 3 lines of the body with the ported
function (of which 2 lines do not change; the first uses code only in
mpv, and the second is just "return 1.0;"). The 4th line is only similar
on an abstract level (and that because of the mathematical relation
between these functions). Although the original sinc() was probably used
as template for it, with the other lines replaced, I don't think you
could make the claim that it falls under AGG copyright.
jinc() was added in commit 26baf5b9, but the code for it might be based
on sinc(). Rewrite it based on the "new" sinc(). Some of the same
remarks as with sphinx() apply.
cubic_bc() was ported from Glumpy's Mitchell(). (As far as I'm aware,
with the default parameters it's called "the" Mitchell-Netravali filter,
but in mpv this function is used to generate a whole group of filters.)
spline64() was added in commit a8b67c66, and was probably derived from
spline36(). Re-derive it from the "new" spline36().
triangle() could be considered derived from the original bilinear().
This is this in the original commit:
static double bilinear(kernel *k, double x)
{
return 1.0 - x;
}
This _might_ be based on AGG's image_filter_bilinear:
struct image_filter_bilinear
{
static double radius() { return 1.0; }
static double calc_weight(double x)
{
return 1.0 - x;
}
};
Considering that the "framework" was written by me, and the only part
from AGG taken is "return 1.0 - x;", and this part is trivial and was
later thoroughly replaced, this is probably not under the AGG copyright.
I'm hoping this doesn't introduce regressions. But the main focus is not
being productive anyway, and I didn't rigorously check unintended
changes in functionality.
2016-01-06 17:35:01 +00:00
|
|
|
}
|
|
|
|
return 0.0;
|
2012-03-30 23:13:38 +00:00
|
|
|
}
|
|
|
|
|
vo_opengl: separate kernel and window
This makes the core much more elegant, reusable, reconfigurable and also
allows us to more easily add aliases for specific configurations.
Furthermore, this lets us apply a generic blur factor / window function
to arbitrary filters, so we can finally "mix and match" in order to
fine-tune windowing functions.
A few notes are in order:
1. The current system for configuring scalers is ugly and rapidly
getting unwieldy. I modified the man page to make it a bit more
bearable, but long-term we have to do something about it; especially
since..
2. There's currently no way to affect the blur factor or parameters of
the window functions themselves. For example, I can't actually
fine-tune the kaiser window's param1, since there's simply no way to
do so in the current API - even though filter_kernels.c supports it
just fine!
3. This removes some lesser used filters (especially those which are
purely window functions to begin with). If anybody asks, you can get
eg. the old behavior of scale=hanning by using
scale=box:scale-window=hanning:scale-radius=1 (and yes, the result is
just as terrible as that sounds - which is why nobody should have
been using them in the first place).
4. This changes the semantics of the "triangle" scaler slightly - it now
has an arbitrary radius. This can possibly produce weird results for
people who were previously using scale-down=triangle, especially if
in combination with scale-radius (for the usual upscaling). The
correct fix for this is to use scale-down=bilinear_slow instead,
which is an alias for triangle at radius 1.
In regards to the last point, in future I want to make it so that
filters have a filter-specific "preferred radius" (for the ones that
are arbitrarily tunable), once the configuration system for filters has
been redesigned (in particular in a way that will let us separate scale
and scale-down cleanly). That way, "triangle" can simply have the
preferred radius of 1 by default, while still being tunable. (Rather
than the default radius being hard-coded to 3 always)
2015-03-25 03:40:28 +00:00
|
|
|
static double spline16(params *p, double x)
|
2012-03-30 23:13:38 +00:00
|
|
|
{
|
filter_kernels: replace AGG-based code
This commit replaces code based on AGG, taken from this source file:
http://vector-agg.cvs.sourceforge.net/viewvc/vector-agg/agg-2.5/include/agg_image_filters.h
The intention is that filter_kernels.c can be relicensed to LGPL or BSD.
Because the AGG author died, full replacement is the only way to achieve
it.
This affects only some filter functions. These are exclusively
mathematical functions for computing filter coefficients. (Other parts
in filter_kernel.c were originally written by me, with heavy additions
and refactoring done by other mpv contributors.) While the code is
mostly just well-known mathematical formulas written down in C form,
AGG copyright could perhaps be claimed anyway.
To remove the AGG code, I replaced it with the filter functions from:
https://github.com/glumpy/glumpy/blob/master/glumpy/library/build-spatial-filters.py
These functions conveniently compute exactly the same thing in mpv,
Glumpy, AGG (and about anything that will filter images using the same
mathematical principles).
First I ported the Python code in the file to C. Then I replaced all
functions in filter_kernels.c with this code that could be replaced.
Then I investigated whether the remaining functions were based on AGG
code and took appropriate action:
hanning(), hamming(), quadric(), bicubic(), kaiser(), blackman(),
spline16(), spline36(), gaussian(), sinc() were taken straight from
Glumpy.
For sinc(), re-add the "fabs(x) < 1e-8" check, which was added in commit
586dc557 for unknown reasons.
gaussian() loses its filter parameter for some reason. (Well, who cares,
not my problem.)
The really awkward thing is that the text for hanning() and hamming()
does not change. In theory these functions are now based on Glumpy code,
but it seems like this can be neither proven nor denied. (The same
happened in some other cases with at least a few lines of code.)
sphinx() was added in commit 586dc557, and looks suspiciously like
sinc() as well. Replace the first 3 lines of the body with the ported
function (of which 2 lines do not change; the first uses code only in
mpv, and the second is just "return 1.0;"). The 4th line is only similar
on an abstract level (and that because of the mathematical relation
between these functions). Although the original sinc() was probably used
as template for it, with the other lines replaced, I don't think you
could make the claim that it falls under AGG copyright.
jinc() was added in commit 26baf5b9, but the code for it might be based
on sinc(). Rewrite it based on the "new" sinc(). Some of the same
remarks as with sphinx() apply.
cubic_bc() was ported from Glumpy's Mitchell(). (As far as I'm aware,
with the default parameters it's called "the" Mitchell-Netravali filter,
but in mpv this function is used to generate a whole group of filters.)
spline64() was added in commit a8b67c66, and was probably derived from
spline36(). Re-derive it from the "new" spline36().
triangle() could be considered derived from the original bilinear().
This is this in the original commit:
static double bilinear(kernel *k, double x)
{
return 1.0 - x;
}
This _might_ be based on AGG's image_filter_bilinear:
struct image_filter_bilinear
{
static double radius() { return 1.0; }
static double calc_weight(double x)
{
return 1.0 - x;
}
};
Considering that the "framework" was written by me, and the only part
from AGG taken is "return 1.0 - x;", and this part is trivial and was
later thoroughly replaced, this is probably not under the AGG copyright.
I'm hoping this doesn't introduce regressions. But the main focus is not
being productive anyway, and I didn't rigorously check unintended
changes in functionality.
2016-01-06 17:35:01 +00:00
|
|
|
if (x < 1.0) {
|
2012-03-30 23:13:38 +00:00
|
|
|
return ((x - 9.0/5.0 ) * x - 1.0/5.0 ) * x + 1.0;
|
filter_kernels: replace AGG-based code
This commit replaces code based on AGG, taken from this source file:
http://vector-agg.cvs.sourceforge.net/viewvc/vector-agg/agg-2.5/include/agg_image_filters.h
The intention is that filter_kernels.c can be relicensed to LGPL or BSD.
Because the AGG author died, full replacement is the only way to achieve
it.
This affects only some filter functions. These are exclusively
mathematical functions for computing filter coefficients. (Other parts
in filter_kernel.c were originally written by me, with heavy additions
and refactoring done by other mpv contributors.) While the code is
mostly just well-known mathematical formulas written down in C form,
AGG copyright could perhaps be claimed anyway.
To remove the AGG code, I replaced it with the filter functions from:
https://github.com/glumpy/glumpy/blob/master/glumpy/library/build-spatial-filters.py
These functions conveniently compute exactly the same thing in mpv,
Glumpy, AGG (and about anything that will filter images using the same
mathematical principles).
First I ported the Python code in the file to C. Then I replaced all
functions in filter_kernels.c with this code that could be replaced.
Then I investigated whether the remaining functions were based on AGG
code and took appropriate action:
hanning(), hamming(), quadric(), bicubic(), kaiser(), blackman(),
spline16(), spline36(), gaussian(), sinc() were taken straight from
Glumpy.
For sinc(), re-add the "fabs(x) < 1e-8" check, which was added in commit
586dc557 for unknown reasons.
gaussian() loses its filter parameter for some reason. (Well, who cares,
not my problem.)
The really awkward thing is that the text for hanning() and hamming()
does not change. In theory these functions are now based on Glumpy code,
but it seems like this can be neither proven nor denied. (The same
happened in some other cases with at least a few lines of code.)
sphinx() was added in commit 586dc557, and looks suspiciously like
sinc() as well. Replace the first 3 lines of the body with the ported
function (of which 2 lines do not change; the first uses code only in
mpv, and the second is just "return 1.0;"). The 4th line is only similar
on an abstract level (and that because of the mathematical relation
between these functions). Although the original sinc() was probably used
as template for it, with the other lines replaced, I don't think you
could make the claim that it falls under AGG copyright.
jinc() was added in commit 26baf5b9, but the code for it might be based
on sinc(). Rewrite it based on the "new" sinc(). Some of the same
remarks as with sphinx() apply.
cubic_bc() was ported from Glumpy's Mitchell(). (As far as I'm aware,
with the default parameters it's called "the" Mitchell-Netravali filter,
but in mpv this function is used to generate a whole group of filters.)
spline64() was added in commit a8b67c66, and was probably derived from
spline36(). Re-derive it from the "new" spline36().
triangle() could be considered derived from the original bilinear().
This is this in the original commit:
static double bilinear(kernel *k, double x)
{
return 1.0 - x;
}
This _might_ be based on AGG's image_filter_bilinear:
struct image_filter_bilinear
{
static double radius() { return 1.0; }
static double calc_weight(double x)
{
return 1.0 - x;
}
};
Considering that the "framework" was written by me, and the only part
from AGG taken is "return 1.0 - x;", and this part is trivial and was
later thoroughly replaced, this is probably not under the AGG copyright.
I'm hoping this doesn't introduce regressions. But the main focus is not
being productive anyway, and I didn't rigorously check unintended
changes in functionality.
2016-01-06 17:35:01 +00:00
|
|
|
} else {
|
|
|
|
return ((-1.0/3.0 * (x-1) + 4.0/5.0) * (x-1) - 7.0/15.0 ) * (x-1);
|
|
|
|
}
|
2012-03-30 23:13:38 +00:00
|
|
|
}
|
|
|
|
|
vo_opengl: separate kernel and window
This makes the core much more elegant, reusable, reconfigurable and also
allows us to more easily add aliases for specific configurations.
Furthermore, this lets us apply a generic blur factor / window function
to arbitrary filters, so we can finally "mix and match" in order to
fine-tune windowing functions.
A few notes are in order:
1. The current system for configuring scalers is ugly and rapidly
getting unwieldy. I modified the man page to make it a bit more
bearable, but long-term we have to do something about it; especially
since..
2. There's currently no way to affect the blur factor or parameters of
the window functions themselves. For example, I can't actually
fine-tune the kaiser window's param1, since there's simply no way to
do so in the current API - even though filter_kernels.c supports it
just fine!
3. This removes some lesser used filters (especially those which are
purely window functions to begin with). If anybody asks, you can get
eg. the old behavior of scale=hanning by using
scale=box:scale-window=hanning:scale-radius=1 (and yes, the result is
just as terrible as that sounds - which is why nobody should have
been using them in the first place).
4. This changes the semantics of the "triangle" scaler slightly - it now
has an arbitrary radius. This can possibly produce weird results for
people who were previously using scale-down=triangle, especially if
in combination with scale-radius (for the usual upscaling). The
correct fix for this is to use scale-down=bilinear_slow instead,
which is an alias for triangle at radius 1.
In regards to the last point, in future I want to make it so that
filters have a filter-specific "preferred radius" (for the ones that
are arbitrarily tunable), once the configuration system for filters has
been redesigned (in particular in a way that will let us separate scale
and scale-down cleanly). That way, "triangle" can simply have the
preferred radius of 1 by default, while still being tunable. (Rather
than the default radius being hard-coded to 3 always)
2015-03-25 03:40:28 +00:00
|
|
|
static double spline36(params *p, double x)
|
2012-03-30 23:13:38 +00:00
|
|
|
{
|
filter_kernels: replace AGG-based code
This commit replaces code based on AGG, taken from this source file:
http://vector-agg.cvs.sourceforge.net/viewvc/vector-agg/agg-2.5/include/agg_image_filters.h
The intention is that filter_kernels.c can be relicensed to LGPL or BSD.
Because the AGG author died, full replacement is the only way to achieve
it.
This affects only some filter functions. These are exclusively
mathematical functions for computing filter coefficients. (Other parts
in filter_kernel.c were originally written by me, with heavy additions
and refactoring done by other mpv contributors.) While the code is
mostly just well-known mathematical formulas written down in C form,
AGG copyright could perhaps be claimed anyway.
To remove the AGG code, I replaced it with the filter functions from:
https://github.com/glumpy/glumpy/blob/master/glumpy/library/build-spatial-filters.py
These functions conveniently compute exactly the same thing in mpv,
Glumpy, AGG (and about anything that will filter images using the same
mathematical principles).
First I ported the Python code in the file to C. Then I replaced all
functions in filter_kernels.c with this code that could be replaced.
Then I investigated whether the remaining functions were based on AGG
code and took appropriate action:
hanning(), hamming(), quadric(), bicubic(), kaiser(), blackman(),
spline16(), spline36(), gaussian(), sinc() were taken straight from
Glumpy.
For sinc(), re-add the "fabs(x) < 1e-8" check, which was added in commit
586dc557 for unknown reasons.
gaussian() loses its filter parameter for some reason. (Well, who cares,
not my problem.)
The really awkward thing is that the text for hanning() and hamming()
does not change. In theory these functions are now based on Glumpy code,
but it seems like this can be neither proven nor denied. (The same
happened in some other cases with at least a few lines of code.)
sphinx() was added in commit 586dc557, and looks suspiciously like
sinc() as well. Replace the first 3 lines of the body with the ported
function (of which 2 lines do not change; the first uses code only in
mpv, and the second is just "return 1.0;"). The 4th line is only similar
on an abstract level (and that because of the mathematical relation
between these functions). Although the original sinc() was probably used
as template for it, with the other lines replaced, I don't think you
could make the claim that it falls under AGG copyright.
jinc() was added in commit 26baf5b9, but the code for it might be based
on sinc(). Rewrite it based on the "new" sinc(). Some of the same
remarks as with sphinx() apply.
cubic_bc() was ported from Glumpy's Mitchell(). (As far as I'm aware,
with the default parameters it's called "the" Mitchell-Netravali filter,
but in mpv this function is used to generate a whole group of filters.)
spline64() was added in commit a8b67c66, and was probably derived from
spline36(). Re-derive it from the "new" spline36().
triangle() could be considered derived from the original bilinear().
This is this in the original commit:
static double bilinear(kernel *k, double x)
{
return 1.0 - x;
}
This _might_ be based on AGG's image_filter_bilinear:
struct image_filter_bilinear
{
static double radius() { return 1.0; }
static double calc_weight(double x)
{
return 1.0 - x;
}
};
Considering that the "framework" was written by me, and the only part
from AGG taken is "return 1.0 - x;", and this part is trivial and was
later thoroughly replaced, this is probably not under the AGG copyright.
I'm hoping this doesn't introduce regressions. But the main focus is not
being productive anyway, and I didn't rigorously check unintended
changes in functionality.
2016-01-06 17:35:01 +00:00
|
|
|
if (x < 1.0) {
|
2012-03-30 23:13:38 +00:00
|
|
|
return ((13.0/11.0 * x - 453.0/209.0) * x - 3.0/209.0) * x + 1.0;
|
filter_kernels: replace AGG-based code
This commit replaces code based on AGG, taken from this source file:
http://vector-agg.cvs.sourceforge.net/viewvc/vector-agg/agg-2.5/include/agg_image_filters.h
The intention is that filter_kernels.c can be relicensed to LGPL or BSD.
Because the AGG author died, full replacement is the only way to achieve
it.
This affects only some filter functions. These are exclusively
mathematical functions for computing filter coefficients. (Other parts
in filter_kernel.c were originally written by me, with heavy additions
and refactoring done by other mpv contributors.) While the code is
mostly just well-known mathematical formulas written down in C form,
AGG copyright could perhaps be claimed anyway.
To remove the AGG code, I replaced it with the filter functions from:
https://github.com/glumpy/glumpy/blob/master/glumpy/library/build-spatial-filters.py
These functions conveniently compute exactly the same thing in mpv,
Glumpy, AGG (and about anything that will filter images using the same
mathematical principles).
First I ported the Python code in the file to C. Then I replaced all
functions in filter_kernels.c with this code that could be replaced.
Then I investigated whether the remaining functions were based on AGG
code and took appropriate action:
hanning(), hamming(), quadric(), bicubic(), kaiser(), blackman(),
spline16(), spline36(), gaussian(), sinc() were taken straight from
Glumpy.
For sinc(), re-add the "fabs(x) < 1e-8" check, which was added in commit
586dc557 for unknown reasons.
gaussian() loses its filter parameter for some reason. (Well, who cares,
not my problem.)
The really awkward thing is that the text for hanning() and hamming()
does not change. In theory these functions are now based on Glumpy code,
but it seems like this can be neither proven nor denied. (The same
happened in some other cases with at least a few lines of code.)
sphinx() was added in commit 586dc557, and looks suspiciously like
sinc() as well. Replace the first 3 lines of the body with the ported
function (of which 2 lines do not change; the first uses code only in
mpv, and the second is just "return 1.0;"). The 4th line is only similar
on an abstract level (and that because of the mathematical relation
between these functions). Although the original sinc() was probably used
as template for it, with the other lines replaced, I don't think you
could make the claim that it falls under AGG copyright.
jinc() was added in commit 26baf5b9, but the code for it might be based
on sinc(). Rewrite it based on the "new" sinc(). Some of the same
remarks as with sphinx() apply.
cubic_bc() was ported from Glumpy's Mitchell(). (As far as I'm aware,
with the default parameters it's called "the" Mitchell-Netravali filter,
but in mpv this function is used to generate a whole group of filters.)
spline64() was added in commit a8b67c66, and was probably derived from
spline36(). Re-derive it from the "new" spline36().
triangle() could be considered derived from the original bilinear().
This is this in the original commit:
static double bilinear(kernel *k, double x)
{
return 1.0 - x;
}
This _might_ be based on AGG's image_filter_bilinear:
struct image_filter_bilinear
{
static double radius() { return 1.0; }
static double calc_weight(double x)
{
return 1.0 - x;
}
};
Considering that the "framework" was written by me, and the only part
from AGG taken is "return 1.0 - x;", and this part is trivial and was
later thoroughly replaced, this is probably not under the AGG copyright.
I'm hoping this doesn't introduce regressions. But the main focus is not
being productive anyway, and I didn't rigorously check unintended
changes in functionality.
2016-01-06 17:35:01 +00:00
|
|
|
} else if (x < 2.0) {
|
|
|
|
return ((-6.0/11.0 * (x-1) + 270.0/209.0) * (x-1) - 156.0/ 209.0) * (x-1);
|
|
|
|
} else {
|
|
|
|
return ((1.0/11.0 * (x-2) - 45.0/209.0) * (x-2) + 26.0/209.0) * (x-2);
|
|
|
|
}
|
2012-03-30 23:13:38 +00:00
|
|
|
}
|
|
|
|
|
vo_opengl: separate kernel and window
This makes the core much more elegant, reusable, reconfigurable and also
allows us to more easily add aliases for specific configurations.
Furthermore, this lets us apply a generic blur factor / window function
to arbitrary filters, so we can finally "mix and match" in order to
fine-tune windowing functions.
A few notes are in order:
1. The current system for configuring scalers is ugly and rapidly
getting unwieldy. I modified the man page to make it a bit more
bearable, but long-term we have to do something about it; especially
since..
2. There's currently no way to affect the blur factor or parameters of
the window functions themselves. For example, I can't actually
fine-tune the kaiser window's param1, since there's simply no way to
do so in the current API - even though filter_kernels.c supports it
just fine!
3. This removes some lesser used filters (especially those which are
purely window functions to begin with). If anybody asks, you can get
eg. the old behavior of scale=hanning by using
scale=box:scale-window=hanning:scale-radius=1 (and yes, the result is
just as terrible as that sounds - which is why nobody should have
been using them in the first place).
4. This changes the semantics of the "triangle" scaler slightly - it now
has an arbitrary radius. This can possibly produce weird results for
people who were previously using scale-down=triangle, especially if
in combination with scale-radius (for the usual upscaling). The
correct fix for this is to use scale-down=bilinear_slow instead,
which is an alias for triangle at radius 1.
In regards to the last point, in future I want to make it so that
filters have a filter-specific "preferred radius" (for the ones that
are arbitrarily tunable), once the configuration system for filters has
been redesigned (in particular in a way that will let us separate scale
and scale-down cleanly). That way, "triangle" can simply have the
preferred radius of 1 by default, while still being tunable. (Rather
than the default radius being hard-coded to 3 always)
2015-03-25 03:40:28 +00:00
|
|
|
static double spline64(params *p, double x)
|
2014-08-25 20:15:42 +00:00
|
|
|
{
|
filter_kernels: replace AGG-based code
This commit replaces code based on AGG, taken from this source file:
http://vector-agg.cvs.sourceforge.net/viewvc/vector-agg/agg-2.5/include/agg_image_filters.h
The intention is that filter_kernels.c can be relicensed to LGPL or BSD.
Because the AGG author died, full replacement is the only way to achieve
it.
This affects only some filter functions. These are exclusively
mathematical functions for computing filter coefficients. (Other parts
in filter_kernel.c were originally written by me, with heavy additions
and refactoring done by other mpv contributors.) While the code is
mostly just well-known mathematical formulas written down in C form,
AGG copyright could perhaps be claimed anyway.
To remove the AGG code, I replaced it with the filter functions from:
https://github.com/glumpy/glumpy/blob/master/glumpy/library/build-spatial-filters.py
These functions conveniently compute exactly the same thing in mpv,
Glumpy, AGG (and about anything that will filter images using the same
mathematical principles).
First I ported the Python code in the file to C. Then I replaced all
functions in filter_kernels.c with this code that could be replaced.
Then I investigated whether the remaining functions were based on AGG
code and took appropriate action:
hanning(), hamming(), quadric(), bicubic(), kaiser(), blackman(),
spline16(), spline36(), gaussian(), sinc() were taken straight from
Glumpy.
For sinc(), re-add the "fabs(x) < 1e-8" check, which was added in commit
586dc557 for unknown reasons.
gaussian() loses its filter parameter for some reason. (Well, who cares,
not my problem.)
The really awkward thing is that the text for hanning() and hamming()
does not change. In theory these functions are now based on Glumpy code,
but it seems like this can be neither proven nor denied. (The same
happened in some other cases with at least a few lines of code.)
sphinx() was added in commit 586dc557, and looks suspiciously like
sinc() as well. Replace the first 3 lines of the body with the ported
function (of which 2 lines do not change; the first uses code only in
mpv, and the second is just "return 1.0;"). The 4th line is only similar
on an abstract level (and that because of the mathematical relation
between these functions). Although the original sinc() was probably used
as template for it, with the other lines replaced, I don't think you
could make the claim that it falls under AGG copyright.
jinc() was added in commit 26baf5b9, but the code for it might be based
on sinc(). Rewrite it based on the "new" sinc(). Some of the same
remarks as with sphinx() apply.
cubic_bc() was ported from Glumpy's Mitchell(). (As far as I'm aware,
with the default parameters it's called "the" Mitchell-Netravali filter,
but in mpv this function is used to generate a whole group of filters.)
spline64() was added in commit a8b67c66, and was probably derived from
spline36(). Re-derive it from the "new" spline36().
triangle() could be considered derived from the original bilinear().
This is this in the original commit:
static double bilinear(kernel *k, double x)
{
return 1.0 - x;
}
This _might_ be based on AGG's image_filter_bilinear:
struct image_filter_bilinear
{
static double radius() { return 1.0; }
static double calc_weight(double x)
{
return 1.0 - x;
}
};
Considering that the "framework" was written by me, and the only part
from AGG taken is "return 1.0 - x;", and this part is trivial and was
later thoroughly replaced, this is probably not under the AGG copyright.
I'm hoping this doesn't introduce regressions. But the main focus is not
being productive anyway, and I didn't rigorously check unintended
changes in functionality.
2016-01-06 17:35:01 +00:00
|
|
|
if (x < 1.0) {
|
2017-08-29 08:38:50 +00:00
|
|
|
return ((49.0/41.0 * x - 6387.0/2911.0) * x - 3.0/2911.0) * x + 1.0;
|
filter_kernels: replace AGG-based code
This commit replaces code based on AGG, taken from this source file:
http://vector-agg.cvs.sourceforge.net/viewvc/vector-agg/agg-2.5/include/agg_image_filters.h
The intention is that filter_kernels.c can be relicensed to LGPL or BSD.
Because the AGG author died, full replacement is the only way to achieve
it.
This affects only some filter functions. These are exclusively
mathematical functions for computing filter coefficients. (Other parts
in filter_kernel.c were originally written by me, with heavy additions
and refactoring done by other mpv contributors.) While the code is
mostly just well-known mathematical formulas written down in C form,
AGG copyright could perhaps be claimed anyway.
To remove the AGG code, I replaced it with the filter functions from:
https://github.com/glumpy/glumpy/blob/master/glumpy/library/build-spatial-filters.py
These functions conveniently compute exactly the same thing in mpv,
Glumpy, AGG (and about anything that will filter images using the same
mathematical principles).
First I ported the Python code in the file to C. Then I replaced all
functions in filter_kernels.c with this code that could be replaced.
Then I investigated whether the remaining functions were based on AGG
code and took appropriate action:
hanning(), hamming(), quadric(), bicubic(), kaiser(), blackman(),
spline16(), spline36(), gaussian(), sinc() were taken straight from
Glumpy.
For sinc(), re-add the "fabs(x) < 1e-8" check, which was added in commit
586dc557 for unknown reasons.
gaussian() loses its filter parameter for some reason. (Well, who cares,
not my problem.)
The really awkward thing is that the text for hanning() and hamming()
does not change. In theory these functions are now based on Glumpy code,
but it seems like this can be neither proven nor denied. (The same
happened in some other cases with at least a few lines of code.)
sphinx() was added in commit 586dc557, and looks suspiciously like
sinc() as well. Replace the first 3 lines of the body with the ported
function (of which 2 lines do not change; the first uses code only in
mpv, and the second is just "return 1.0;"). The 4th line is only similar
on an abstract level (and that because of the mathematical relation
between these functions). Although the original sinc() was probably used
as template for it, with the other lines replaced, I don't think you
could make the claim that it falls under AGG copyright.
jinc() was added in commit 26baf5b9, but the code for it might be based
on sinc(). Rewrite it based on the "new" sinc(). Some of the same
remarks as with sphinx() apply.
cubic_bc() was ported from Glumpy's Mitchell(). (As far as I'm aware,
with the default parameters it's called "the" Mitchell-Netravali filter,
but in mpv this function is used to generate a whole group of filters.)
spline64() was added in commit a8b67c66, and was probably derived from
spline36(). Re-derive it from the "new" spline36().
triangle() could be considered derived from the original bilinear().
This is this in the original commit:
static double bilinear(kernel *k, double x)
{
return 1.0 - x;
}
This _might_ be based on AGG's image_filter_bilinear:
struct image_filter_bilinear
{
static double radius() { return 1.0; }
static double calc_weight(double x)
{
return 1.0 - x;
}
};
Considering that the "framework" was written by me, and the only part
from AGG taken is "return 1.0 - x;", and this part is trivial and was
later thoroughly replaced, this is probably not under the AGG copyright.
I'm hoping this doesn't introduce regressions. But the main focus is not
being productive anyway, and I didn't rigorously check unintended
changes in functionality.
2016-01-06 17:35:01 +00:00
|
|
|
} else if (x < 2.0) {
|
2017-08-29 08:38:50 +00:00
|
|
|
return ((-24.0/41.0 * (x-1) + 4032.0/2911.0) * (x-1) - 2328.0/2911.0) * (x-1);
|
filter_kernels: replace AGG-based code
This commit replaces code based on AGG, taken from this source file:
http://vector-agg.cvs.sourceforge.net/viewvc/vector-agg/agg-2.5/include/agg_image_filters.h
The intention is that filter_kernels.c can be relicensed to LGPL or BSD.
Because the AGG author died, full replacement is the only way to achieve
it.
This affects only some filter functions. These are exclusively
mathematical functions for computing filter coefficients. (Other parts
in filter_kernel.c were originally written by me, with heavy additions
and refactoring done by other mpv contributors.) While the code is
mostly just well-known mathematical formulas written down in C form,
AGG copyright could perhaps be claimed anyway.
To remove the AGG code, I replaced it with the filter functions from:
https://github.com/glumpy/glumpy/blob/master/glumpy/library/build-spatial-filters.py
These functions conveniently compute exactly the same thing in mpv,
Glumpy, AGG (and about anything that will filter images using the same
mathematical principles).
First I ported the Python code in the file to C. Then I replaced all
functions in filter_kernels.c with this code that could be replaced.
Then I investigated whether the remaining functions were based on AGG
code and took appropriate action:
hanning(), hamming(), quadric(), bicubic(), kaiser(), blackman(),
spline16(), spline36(), gaussian(), sinc() were taken straight from
Glumpy.
For sinc(), re-add the "fabs(x) < 1e-8" check, which was added in commit
586dc557 for unknown reasons.
gaussian() loses its filter parameter for some reason. (Well, who cares,
not my problem.)
The really awkward thing is that the text for hanning() and hamming()
does not change. In theory these functions are now based on Glumpy code,
but it seems like this can be neither proven nor denied. (The same
happened in some other cases with at least a few lines of code.)
sphinx() was added in commit 586dc557, and looks suspiciously like
sinc() as well. Replace the first 3 lines of the body with the ported
function (of which 2 lines do not change; the first uses code only in
mpv, and the second is just "return 1.0;"). The 4th line is only similar
on an abstract level (and that because of the mathematical relation
between these functions). Although the original sinc() was probably used
as template for it, with the other lines replaced, I don't think you
could make the claim that it falls under AGG copyright.
jinc() was added in commit 26baf5b9, but the code for it might be based
on sinc(). Rewrite it based on the "new" sinc(). Some of the same
remarks as with sphinx() apply.
cubic_bc() was ported from Glumpy's Mitchell(). (As far as I'm aware,
with the default parameters it's called "the" Mitchell-Netravali filter,
but in mpv this function is used to generate a whole group of filters.)
spline64() was added in commit a8b67c66, and was probably derived from
spline36(). Re-derive it from the "new" spline36().
triangle() could be considered derived from the original bilinear().
This is this in the original commit:
static double bilinear(kernel *k, double x)
{
return 1.0 - x;
}
This _might_ be based on AGG's image_filter_bilinear:
struct image_filter_bilinear
{
static double radius() { return 1.0; }
static double calc_weight(double x)
{
return 1.0 - x;
}
};
Considering that the "framework" was written by me, and the only part
from AGG taken is "return 1.0 - x;", and this part is trivial and was
later thoroughly replaced, this is probably not under the AGG copyright.
I'm hoping this doesn't introduce regressions. But the main focus is not
being productive anyway, and I didn't rigorously check unintended
changes in functionality.
2016-01-06 17:35:01 +00:00
|
|
|
} else if (x < 3.0) {
|
2017-08-29 08:38:50 +00:00
|
|
|
return ((6.0/41.0 * (x-2) - 1008.0/2911.0) * (x-2) + 582.0/2911.0) * (x-2);
|
filter_kernels: replace AGG-based code
This commit replaces code based on AGG, taken from this source file:
http://vector-agg.cvs.sourceforge.net/viewvc/vector-agg/agg-2.5/include/agg_image_filters.h
The intention is that filter_kernels.c can be relicensed to LGPL or BSD.
Because the AGG author died, full replacement is the only way to achieve
it.
This affects only some filter functions. These are exclusively
mathematical functions for computing filter coefficients. (Other parts
in filter_kernel.c were originally written by me, with heavy additions
and refactoring done by other mpv contributors.) While the code is
mostly just well-known mathematical formulas written down in C form,
AGG copyright could perhaps be claimed anyway.
To remove the AGG code, I replaced it with the filter functions from:
https://github.com/glumpy/glumpy/blob/master/glumpy/library/build-spatial-filters.py
These functions conveniently compute exactly the same thing in mpv,
Glumpy, AGG (and about anything that will filter images using the same
mathematical principles).
First I ported the Python code in the file to C. Then I replaced all
functions in filter_kernels.c with this code that could be replaced.
Then I investigated whether the remaining functions were based on AGG
code and took appropriate action:
hanning(), hamming(), quadric(), bicubic(), kaiser(), blackman(),
spline16(), spline36(), gaussian(), sinc() were taken straight from
Glumpy.
For sinc(), re-add the "fabs(x) < 1e-8" check, which was added in commit
586dc557 for unknown reasons.
gaussian() loses its filter parameter for some reason. (Well, who cares,
not my problem.)
The really awkward thing is that the text for hanning() and hamming()
does not change. In theory these functions are now based on Glumpy code,
but it seems like this can be neither proven nor denied. (The same
happened in some other cases with at least a few lines of code.)
sphinx() was added in commit 586dc557, and looks suspiciously like
sinc() as well. Replace the first 3 lines of the body with the ported
function (of which 2 lines do not change; the first uses code only in
mpv, and the second is just "return 1.0;"). The 4th line is only similar
on an abstract level (and that because of the mathematical relation
between these functions). Although the original sinc() was probably used
as template for it, with the other lines replaced, I don't think you
could make the claim that it falls under AGG copyright.
jinc() was added in commit 26baf5b9, but the code for it might be based
on sinc(). Rewrite it based on the "new" sinc(). Some of the same
remarks as with sphinx() apply.
cubic_bc() was ported from Glumpy's Mitchell(). (As far as I'm aware,
with the default parameters it's called "the" Mitchell-Netravali filter,
but in mpv this function is used to generate a whole group of filters.)
spline64() was added in commit a8b67c66, and was probably derived from
spline36(). Re-derive it from the "new" spline36().
triangle() could be considered derived from the original bilinear().
This is this in the original commit:
static double bilinear(kernel *k, double x)
{
return 1.0 - x;
}
This _might_ be based on AGG's image_filter_bilinear:
struct image_filter_bilinear
{
static double radius() { return 1.0; }
static double calc_weight(double x)
{
return 1.0 - x;
}
};
Considering that the "framework" was written by me, and the only part
from AGG taken is "return 1.0 - x;", and this part is trivial and was
later thoroughly replaced, this is probably not under the AGG copyright.
I'm hoping this doesn't introduce regressions. But the main focus is not
being productive anyway, and I didn't rigorously check unintended
changes in functionality.
2016-01-06 17:35:01 +00:00
|
|
|
} else {
|
2017-08-29 08:38:50 +00:00
|
|
|
return ((-1.0/41.0 * (x-3) + 168.0/2911.0) * (x-3) - 97.0/2911.0) * (x-3);
|
filter_kernels: replace AGG-based code
This commit replaces code based on AGG, taken from this source file:
http://vector-agg.cvs.sourceforge.net/viewvc/vector-agg/agg-2.5/include/agg_image_filters.h
The intention is that filter_kernels.c can be relicensed to LGPL or BSD.
Because the AGG author died, full replacement is the only way to achieve
it.
This affects only some filter functions. These are exclusively
mathematical functions for computing filter coefficients. (Other parts
in filter_kernel.c were originally written by me, with heavy additions
and refactoring done by other mpv contributors.) While the code is
mostly just well-known mathematical formulas written down in C form,
AGG copyright could perhaps be claimed anyway.
To remove the AGG code, I replaced it with the filter functions from:
https://github.com/glumpy/glumpy/blob/master/glumpy/library/build-spatial-filters.py
These functions conveniently compute exactly the same thing in mpv,
Glumpy, AGG (and about anything that will filter images using the same
mathematical principles).
First I ported the Python code in the file to C. Then I replaced all
functions in filter_kernels.c with this code that could be replaced.
Then I investigated whether the remaining functions were based on AGG
code and took appropriate action:
hanning(), hamming(), quadric(), bicubic(), kaiser(), blackman(),
spline16(), spline36(), gaussian(), sinc() were taken straight from
Glumpy.
For sinc(), re-add the "fabs(x) < 1e-8" check, which was added in commit
586dc557 for unknown reasons.
gaussian() loses its filter parameter for some reason. (Well, who cares,
not my problem.)
The really awkward thing is that the text for hanning() and hamming()
does not change. In theory these functions are now based on Glumpy code,
but it seems like this can be neither proven nor denied. (The same
happened in some other cases with at least a few lines of code.)
sphinx() was added in commit 586dc557, and looks suspiciously like
sinc() as well. Replace the first 3 lines of the body with the ported
function (of which 2 lines do not change; the first uses code only in
mpv, and the second is just "return 1.0;"). The 4th line is only similar
on an abstract level (and that because of the mathematical relation
between these functions). Although the original sinc() was probably used
as template for it, with the other lines replaced, I don't think you
could make the claim that it falls under AGG copyright.
jinc() was added in commit 26baf5b9, but the code for it might be based
on sinc(). Rewrite it based on the "new" sinc(). Some of the same
remarks as with sphinx() apply.
cubic_bc() was ported from Glumpy's Mitchell(). (As far as I'm aware,
with the default parameters it's called "the" Mitchell-Netravali filter,
but in mpv this function is used to generate a whole group of filters.)
spline64() was added in commit a8b67c66, and was probably derived from
spline36(). Re-derive it from the "new" spline36().
triangle() could be considered derived from the original bilinear().
This is this in the original commit:
static double bilinear(kernel *k, double x)
{
return 1.0 - x;
}
This _might_ be based on AGG's image_filter_bilinear:
struct image_filter_bilinear
{
static double radius() { return 1.0; }
static double calc_weight(double x)
{
return 1.0 - x;
}
};
Considering that the "framework" was written by me, and the only part
from AGG taken is "return 1.0 - x;", and this part is trivial and was
later thoroughly replaced, this is probably not under the AGG copyright.
I'm hoping this doesn't introduce regressions. But the main focus is not
being productive anyway, and I didn't rigorously check unintended
changes in functionality.
2016-01-06 17:35:01 +00:00
|
|
|
}
|
2014-08-25 20:15:42 +00:00
|
|
|
}
|
|
|
|
|
vo_opengl: separate kernel and window
This makes the core much more elegant, reusable, reconfigurable and also
allows us to more easily add aliases for specific configurations.
Furthermore, this lets us apply a generic blur factor / window function
to arbitrary filters, so we can finally "mix and match" in order to
fine-tune windowing functions.
A few notes are in order:
1. The current system for configuring scalers is ugly and rapidly
getting unwieldy. I modified the man page to make it a bit more
bearable, but long-term we have to do something about it; especially
since..
2. There's currently no way to affect the blur factor or parameters of
the window functions themselves. For example, I can't actually
fine-tune the kaiser window's param1, since there's simply no way to
do so in the current API - even though filter_kernels.c supports it
just fine!
3. This removes some lesser used filters (especially those which are
purely window functions to begin with). If anybody asks, you can get
eg. the old behavior of scale=hanning by using
scale=box:scale-window=hanning:scale-radius=1 (and yes, the result is
just as terrible as that sounds - which is why nobody should have
been using them in the first place).
4. This changes the semantics of the "triangle" scaler slightly - it now
has an arbitrary radius. This can possibly produce weird results for
people who were previously using scale-down=triangle, especially if
in combination with scale-radius (for the usual upscaling). The
correct fix for this is to use scale-down=bilinear_slow instead,
which is an alias for triangle at radius 1.
In regards to the last point, in future I want to make it so that
filters have a filter-specific "preferred radius" (for the ones that
are arbitrarily tunable), once the configuration system for filters has
been redesigned (in particular in a way that will let us separate scale
and scale-down cleanly). That way, "triangle" can simply have the
preferred radius of 1 by default, while still being tunable. (Rather
than the default radius being hard-coded to 3 always)
2015-03-25 03:40:28 +00:00
|
|
|
static double gaussian(params *p, double x)
|
2012-03-30 23:13:38 +00:00
|
|
|
{
|
2016-01-07 10:43:14 +00:00
|
|
|
return exp(-2.0 * x * x / p->params[0]);
|
2012-03-30 23:13:38 +00:00
|
|
|
}
|
|
|
|
|
vo_opengl: separate kernel and window
This makes the core much more elegant, reusable, reconfigurable and also
allows us to more easily add aliases for specific configurations.
Furthermore, this lets us apply a generic blur factor / window function
to arbitrary filters, so we can finally "mix and match" in order to
fine-tune windowing functions.
A few notes are in order:
1. The current system for configuring scalers is ugly and rapidly
getting unwieldy. I modified the man page to make it a bit more
bearable, but long-term we have to do something about it; especially
since..
2. There's currently no way to affect the blur factor or parameters of
the window functions themselves. For example, I can't actually
fine-tune the kaiser window's param1, since there's simply no way to
do so in the current API - even though filter_kernels.c supports it
just fine!
3. This removes some lesser used filters (especially those which are
purely window functions to begin with). If anybody asks, you can get
eg. the old behavior of scale=hanning by using
scale=box:scale-window=hanning:scale-radius=1 (and yes, the result is
just as terrible as that sounds - which is why nobody should have
been using them in the first place).
4. This changes the semantics of the "triangle" scaler slightly - it now
has an arbitrary radius. This can possibly produce weird results for
people who were previously using scale-down=triangle, especially if
in combination with scale-radius (for the usual upscaling). The
correct fix for this is to use scale-down=bilinear_slow instead,
which is an alias for triangle at radius 1.
In regards to the last point, in future I want to make it so that
filters have a filter-specific "preferred radius" (for the ones that
are arbitrarily tunable), once the configuration system for filters has
been redesigned (in particular in a way that will let us separate scale
and scale-down cleanly). That way, "triangle" can simply have the
preferred radius of 1 by default, while still being tunable. (Rather
than the default radius being hard-coded to 3 always)
2015-03-25 03:40:28 +00:00
|
|
|
static double sinc(params *p, double x)
|
2012-03-30 23:13:38 +00:00
|
|
|
{
|
vo_opengl: separate kernel and window
This makes the core much more elegant, reusable, reconfigurable and also
allows us to more easily add aliases for specific configurations.
Furthermore, this lets us apply a generic blur factor / window function
to arbitrary filters, so we can finally "mix and match" in order to
fine-tune windowing functions.
A few notes are in order:
1. The current system for configuring scalers is ugly and rapidly
getting unwieldy. I modified the man page to make it a bit more
bearable, but long-term we have to do something about it; especially
since..
2. There's currently no way to affect the blur factor or parameters of
the window functions themselves. For example, I can't actually
fine-tune the kaiser window's param1, since there's simply no way to
do so in the current API - even though filter_kernels.c supports it
just fine!
3. This removes some lesser used filters (especially those which are
purely window functions to begin with). If anybody asks, you can get
eg. the old behavior of scale=hanning by using
scale=box:scale-window=hanning:scale-radius=1 (and yes, the result is
just as terrible as that sounds - which is why nobody should have
been using them in the first place).
4. This changes the semantics of the "triangle" scaler slightly - it now
has an arbitrary radius. This can possibly produce weird results for
people who were previously using scale-down=triangle, especially if
in combination with scale-radius (for the usual upscaling). The
correct fix for this is to use scale-down=bilinear_slow instead,
which is an alias for triangle at radius 1.
In regards to the last point, in future I want to make it so that
filters have a filter-specific "preferred radius" (for the ones that
are arbitrarily tunable), once the configuration system for filters has
been redesigned (in particular in a way that will let us separate scale
and scale-down cleanly). That way, "triangle" can simply have the
preferred radius of 1 by default, while still being tunable. (Rather
than the default radius being hard-coded to 3 always)
2015-03-25 03:40:28 +00:00
|
|
|
if (fabs(x) < 1e-8)
|
2012-03-30 23:13:38 +00:00
|
|
|
return 1.0;
|
filter_kernels: replace AGG-based code
This commit replaces code based on AGG, taken from this source file:
http://vector-agg.cvs.sourceforge.net/viewvc/vector-agg/agg-2.5/include/agg_image_filters.h
The intention is that filter_kernels.c can be relicensed to LGPL or BSD.
Because the AGG author died, full replacement is the only way to achieve
it.
This affects only some filter functions. These are exclusively
mathematical functions for computing filter coefficients. (Other parts
in filter_kernel.c were originally written by me, with heavy additions
and refactoring done by other mpv contributors.) While the code is
mostly just well-known mathematical formulas written down in C form,
AGG copyright could perhaps be claimed anyway.
To remove the AGG code, I replaced it with the filter functions from:
https://github.com/glumpy/glumpy/blob/master/glumpy/library/build-spatial-filters.py
These functions conveniently compute exactly the same thing in mpv,
Glumpy, AGG (and about anything that will filter images using the same
mathematical principles).
First I ported the Python code in the file to C. Then I replaced all
functions in filter_kernels.c with this code that could be replaced.
Then I investigated whether the remaining functions were based on AGG
code and took appropriate action:
hanning(), hamming(), quadric(), bicubic(), kaiser(), blackman(),
spline16(), spline36(), gaussian(), sinc() were taken straight from
Glumpy.
For sinc(), re-add the "fabs(x) < 1e-8" check, which was added in commit
586dc557 for unknown reasons.
gaussian() loses its filter parameter for some reason. (Well, who cares,
not my problem.)
The really awkward thing is that the text for hanning() and hamming()
does not change. In theory these functions are now based on Glumpy code,
but it seems like this can be neither proven nor denied. (The same
happened in some other cases with at least a few lines of code.)
sphinx() was added in commit 586dc557, and looks suspiciously like
sinc() as well. Replace the first 3 lines of the body with the ported
function (of which 2 lines do not change; the first uses code only in
mpv, and the second is just "return 1.0;"). The 4th line is only similar
on an abstract level (and that because of the mathematical relation
between these functions). Although the original sinc() was probably used
as template for it, with the other lines replaced, I don't think you
could make the claim that it falls under AGG copyright.
jinc() was added in commit 26baf5b9, but the code for it might be based
on sinc(). Rewrite it based on the "new" sinc(). Some of the same
remarks as with sphinx() apply.
cubic_bc() was ported from Glumpy's Mitchell(). (As far as I'm aware,
with the default parameters it's called "the" Mitchell-Netravali filter,
but in mpv this function is used to generate a whole group of filters.)
spline64() was added in commit a8b67c66, and was probably derived from
spline36(). Re-derive it from the "new" spline36().
triangle() could be considered derived from the original bilinear().
This is this in the original commit:
static double bilinear(kernel *k, double x)
{
return 1.0 - x;
}
This _might_ be based on AGG's image_filter_bilinear:
struct image_filter_bilinear
{
static double radius() { return 1.0; }
static double calc_weight(double x)
{
return 1.0 - x;
}
};
Considering that the "framework" was written by me, and the only part
from AGG taken is "return 1.0 - x;", and this part is trivial and was
later thoroughly replaced, this is probably not under the AGG copyright.
I'm hoping this doesn't introduce regressions. But the main focus is not
being productive anyway, and I didn't rigorously check unintended
changes in functionality.
2016-01-06 17:35:01 +00:00
|
|
|
x *= M_PI;
|
|
|
|
return sin(x) / x;
|
2012-03-30 23:13:38 +00:00
|
|
|
}
|
|
|
|
|
vo_opengl: separate kernel and window
This makes the core much more elegant, reusable, reconfigurable and also
allows us to more easily add aliases for specific configurations.
Furthermore, this lets us apply a generic blur factor / window function
to arbitrary filters, so we can finally "mix and match" in order to
fine-tune windowing functions.
A few notes are in order:
1. The current system for configuring scalers is ugly and rapidly
getting unwieldy. I modified the man page to make it a bit more
bearable, but long-term we have to do something about it; especially
since..
2. There's currently no way to affect the blur factor or parameters of
the window functions themselves. For example, I can't actually
fine-tune the kaiser window's param1, since there's simply no way to
do so in the current API - even though filter_kernels.c supports it
just fine!
3. This removes some lesser used filters (especially those which are
purely window functions to begin with). If anybody asks, you can get
eg. the old behavior of scale=hanning by using
scale=box:scale-window=hanning:scale-radius=1 (and yes, the result is
just as terrible as that sounds - which is why nobody should have
been using them in the first place).
4. This changes the semantics of the "triangle" scaler slightly - it now
has an arbitrary radius. This can possibly produce weird results for
people who were previously using scale-down=triangle, especially if
in combination with scale-radius (for the usual upscaling). The
correct fix for this is to use scale-down=bilinear_slow instead,
which is an alias for triangle at radius 1.
In regards to the last point, in future I want to make it so that
filters have a filter-specific "preferred radius" (for the ones that
are arbitrarily tunable), once the configuration system for filters has
been redesigned (in particular in a way that will let us separate scale
and scale-down cleanly). That way, "triangle" can simply have the
preferred radius of 1 by default, while still being tunable. (Rather
than the default radius being hard-coded to 3 always)
2015-03-25 03:40:28 +00:00
|
|
|
static double jinc(params *p, double x)
|
2015-01-04 22:11:27 +00:00
|
|
|
{
|
2015-02-23 15:20:13 +00:00
|
|
|
if (fabs(x) < 1e-8)
|
2015-01-04 22:11:27 +00:00
|
|
|
return 1.0;
|
filter_kernels: replace AGG-based code
This commit replaces code based on AGG, taken from this source file:
http://vector-agg.cvs.sourceforge.net/viewvc/vector-agg/agg-2.5/include/agg_image_filters.h
The intention is that filter_kernels.c can be relicensed to LGPL or BSD.
Because the AGG author died, full replacement is the only way to achieve
it.
This affects only some filter functions. These are exclusively
mathematical functions for computing filter coefficients. (Other parts
in filter_kernel.c were originally written by me, with heavy additions
and refactoring done by other mpv contributors.) While the code is
mostly just well-known mathematical formulas written down in C form,
AGG copyright could perhaps be claimed anyway.
To remove the AGG code, I replaced it with the filter functions from:
https://github.com/glumpy/glumpy/blob/master/glumpy/library/build-spatial-filters.py
These functions conveniently compute exactly the same thing in mpv,
Glumpy, AGG (and about anything that will filter images using the same
mathematical principles).
First I ported the Python code in the file to C. Then I replaced all
functions in filter_kernels.c with this code that could be replaced.
Then I investigated whether the remaining functions were based on AGG
code and took appropriate action:
hanning(), hamming(), quadric(), bicubic(), kaiser(), blackman(),
spline16(), spline36(), gaussian(), sinc() were taken straight from
Glumpy.
For sinc(), re-add the "fabs(x) < 1e-8" check, which was added in commit
586dc557 for unknown reasons.
gaussian() loses its filter parameter for some reason. (Well, who cares,
not my problem.)
The really awkward thing is that the text for hanning() and hamming()
does not change. In theory these functions are now based on Glumpy code,
but it seems like this can be neither proven nor denied. (The same
happened in some other cases with at least a few lines of code.)
sphinx() was added in commit 586dc557, and looks suspiciously like
sinc() as well. Replace the first 3 lines of the body with the ported
function (of which 2 lines do not change; the first uses code only in
mpv, and the second is just "return 1.0;"). The 4th line is only similar
on an abstract level (and that because of the mathematical relation
between these functions). Although the original sinc() was probably used
as template for it, with the other lines replaced, I don't think you
could make the claim that it falls under AGG copyright.
jinc() was added in commit 26baf5b9, but the code for it might be based
on sinc(). Rewrite it based on the "new" sinc(). Some of the same
remarks as with sphinx() apply.
cubic_bc() was ported from Glumpy's Mitchell(). (As far as I'm aware,
with the default parameters it's called "the" Mitchell-Netravali filter,
but in mpv this function is used to generate a whole group of filters.)
spline64() was added in commit a8b67c66, and was probably derived from
spline36(). Re-derive it from the "new" spline36().
triangle() could be considered derived from the original bilinear().
This is this in the original commit:
static double bilinear(kernel *k, double x)
{
return 1.0 - x;
}
This _might_ be based on AGG's image_filter_bilinear:
struct image_filter_bilinear
{
static double radius() { return 1.0; }
static double calc_weight(double x)
{
return 1.0 - x;
}
};
Considering that the "framework" was written by me, and the only part
from AGG taken is "return 1.0 - x;", and this part is trivial and was
later thoroughly replaced, this is probably not under the AGG copyright.
I'm hoping this doesn't introduce regressions. But the main focus is not
being productive anyway, and I didn't rigorously check unintended
changes in functionality.
2016-01-06 17:35:01 +00:00
|
|
|
x *= M_PI;
|
|
|
|
return 2.0 * j1(x) / x;
|
2015-02-23 15:30:22 +00:00
|
|
|
}
|
|
|
|
|
vo_opengl: separate kernel and window
This makes the core much more elegant, reusable, reconfigurable and also
allows us to more easily add aliases for specific configurations.
Furthermore, this lets us apply a generic blur factor / window function
to arbitrary filters, so we can finally "mix and match" in order to
fine-tune windowing functions.
A few notes are in order:
1. The current system for configuring scalers is ugly and rapidly
getting unwieldy. I modified the man page to make it a bit more
bearable, but long-term we have to do something about it; especially
since..
2. There's currently no way to affect the blur factor or parameters of
the window functions themselves. For example, I can't actually
fine-tune the kaiser window's param1, since there's simply no way to
do so in the current API - even though filter_kernels.c supports it
just fine!
3. This removes some lesser used filters (especially those which are
purely window functions to begin with). If anybody asks, you can get
eg. the old behavior of scale=hanning by using
scale=box:scale-window=hanning:scale-radius=1 (and yes, the result is
just as terrible as that sounds - which is why nobody should have
been using them in the first place).
4. This changes the semantics of the "triangle" scaler slightly - it now
has an arbitrary radius. This can possibly produce weird results for
people who were previously using scale-down=triangle, especially if
in combination with scale-radius (for the usual upscaling). The
correct fix for this is to use scale-down=bilinear_slow instead,
which is an alias for triangle at radius 1.
In regards to the last point, in future I want to make it so that
filters have a filter-specific "preferred radius" (for the ones that
are arbitrarily tunable), once the configuration system for filters has
been redesigned (in particular in a way that will let us separate scale
and scale-down cleanly). That way, "triangle" can simply have the
preferred radius of 1 by default, while still being tunable. (Rather
than the default radius being hard-coded to 3 always)
2015-03-25 03:40:28 +00:00
|
|
|
static double sphinx(params *p, double x)
|
2012-03-30 23:13:38 +00:00
|
|
|
{
|
vo_opengl: separate kernel and window
This makes the core much more elegant, reusable, reconfigurable and also
allows us to more easily add aliases for specific configurations.
Furthermore, this lets us apply a generic blur factor / window function
to arbitrary filters, so we can finally "mix and match" in order to
fine-tune windowing functions.
A few notes are in order:
1. The current system for configuring scalers is ugly and rapidly
getting unwieldy. I modified the man page to make it a bit more
bearable, but long-term we have to do something about it; especially
since..
2. There's currently no way to affect the blur factor or parameters of
the window functions themselves. For example, I can't actually
fine-tune the kaiser window's param1, since there's simply no way to
do so in the current API - even though filter_kernels.c supports it
just fine!
3. This removes some lesser used filters (especially those which are
purely window functions to begin with). If anybody asks, you can get
eg. the old behavior of scale=hanning by using
scale=box:scale-window=hanning:scale-radius=1 (and yes, the result is
just as terrible as that sounds - which is why nobody should have
been using them in the first place).
4. This changes the semantics of the "triangle" scaler slightly - it now
has an arbitrary radius. This can possibly produce weird results for
people who were previously using scale-down=triangle, especially if
in combination with scale-radius (for the usual upscaling). The
correct fix for this is to use scale-down=bilinear_slow instead,
which is an alias for triangle at radius 1.
In regards to the last point, in future I want to make it so that
filters have a filter-specific "preferred radius" (for the ones that
are arbitrarily tunable), once the configuration system for filters has
been redesigned (in particular in a way that will let us separate scale
and scale-down cleanly). That way, "triangle" can simply have the
preferred radius of 1 by default, while still being tunable. (Rather
than the default radius being hard-coded to 3 always)
2015-03-25 03:40:28 +00:00
|
|
|
if (fabs(x) < 1e-8)
|
2012-03-30 23:13:38 +00:00
|
|
|
return 1.0;
|
filter_kernels: replace AGG-based code
This commit replaces code based on AGG, taken from this source file:
http://vector-agg.cvs.sourceforge.net/viewvc/vector-agg/agg-2.5/include/agg_image_filters.h
The intention is that filter_kernels.c can be relicensed to LGPL or BSD.
Because the AGG author died, full replacement is the only way to achieve
it.
This affects only some filter functions. These are exclusively
mathematical functions for computing filter coefficients. (Other parts
in filter_kernel.c were originally written by me, with heavy additions
and refactoring done by other mpv contributors.) While the code is
mostly just well-known mathematical formulas written down in C form,
AGG copyright could perhaps be claimed anyway.
To remove the AGG code, I replaced it with the filter functions from:
https://github.com/glumpy/glumpy/blob/master/glumpy/library/build-spatial-filters.py
These functions conveniently compute exactly the same thing in mpv,
Glumpy, AGG (and about anything that will filter images using the same
mathematical principles).
First I ported the Python code in the file to C. Then I replaced all
functions in filter_kernels.c with this code that could be replaced.
Then I investigated whether the remaining functions were based on AGG
code and took appropriate action:
hanning(), hamming(), quadric(), bicubic(), kaiser(), blackman(),
spline16(), spline36(), gaussian(), sinc() were taken straight from
Glumpy.
For sinc(), re-add the "fabs(x) < 1e-8" check, which was added in commit
586dc557 for unknown reasons.
gaussian() loses its filter parameter for some reason. (Well, who cares,
not my problem.)
The really awkward thing is that the text for hanning() and hamming()
does not change. In theory these functions are now based on Glumpy code,
but it seems like this can be neither proven nor denied. (The same
happened in some other cases with at least a few lines of code.)
sphinx() was added in commit 586dc557, and looks suspiciously like
sinc() as well. Replace the first 3 lines of the body with the ported
function (of which 2 lines do not change; the first uses code only in
mpv, and the second is just "return 1.0;"). The 4th line is only similar
on an abstract level (and that because of the mathematical relation
between these functions). Although the original sinc() was probably used
as template for it, with the other lines replaced, I don't think you
could make the claim that it falls under AGG copyright.
jinc() was added in commit 26baf5b9, but the code for it might be based
on sinc(). Rewrite it based on the "new" sinc(). Some of the same
remarks as with sphinx() apply.
cubic_bc() was ported from Glumpy's Mitchell(). (As far as I'm aware,
with the default parameters it's called "the" Mitchell-Netravali filter,
but in mpv this function is used to generate a whole group of filters.)
spline64() was added in commit a8b67c66, and was probably derived from
spline36(). Re-derive it from the "new" spline36().
triangle() could be considered derived from the original bilinear().
This is this in the original commit:
static double bilinear(kernel *k, double x)
{
return 1.0 - x;
}
This _might_ be based on AGG's image_filter_bilinear:
struct image_filter_bilinear
{
static double radius() { return 1.0; }
static double calc_weight(double x)
{
return 1.0 - x;
}
};
Considering that the "framework" was written by me, and the only part
from AGG taken is "return 1.0 - x;", and this part is trivial and was
later thoroughly replaced, this is probably not under the AGG copyright.
I'm hoping this doesn't introduce regressions. But the main focus is not
being productive anyway, and I didn't rigorously check unintended
changes in functionality.
2016-01-06 17:35:01 +00:00
|
|
|
x *= M_PI;
|
|
|
|
return 3.0 * (sin(x) - x * cos(x)) / (x * x * x);
|
2012-03-30 23:13:38 +00:00
|
|
|
}
|
|
|
|
|
vo_opengl: separate kernel and window
This makes the core much more elegant, reusable, reconfigurable and also
allows us to more easily add aliases for specific configurations.
Furthermore, this lets us apply a generic blur factor / window function
to arbitrary filters, so we can finally "mix and match" in order to
fine-tune windowing functions.
A few notes are in order:
1. The current system for configuring scalers is ugly and rapidly
getting unwieldy. I modified the man page to make it a bit more
bearable, but long-term we have to do something about it; especially
since..
2. There's currently no way to affect the blur factor or parameters of
the window functions themselves. For example, I can't actually
fine-tune the kaiser window's param1, since there's simply no way to
do so in the current API - even though filter_kernels.c supports it
just fine!
3. This removes some lesser used filters (especially those which are
purely window functions to begin with). If anybody asks, you can get
eg. the old behavior of scale=hanning by using
scale=box:scale-window=hanning:scale-radius=1 (and yes, the result is
just as terrible as that sounds - which is why nobody should have
been using them in the first place).
4. This changes the semantics of the "triangle" scaler slightly - it now
has an arbitrary radius. This can possibly produce weird results for
people who were previously using scale-down=triangle, especially if
in combination with scale-radius (for the usual upscaling). The
correct fix for this is to use scale-down=bilinear_slow instead,
which is an alias for triangle at radius 1.
In regards to the last point, in future I want to make it so that
filters have a filter-specific "preferred radius" (for the ones that
are arbitrarily tunable), once the configuration system for filters has
been redesigned (in particular in a way that will let us separate scale
and scale-down cleanly). That way, "triangle" can simply have the
preferred radius of 1 by default, while still being tunable. (Rather
than the default radius being hard-coded to 3 always)
2015-03-25 03:40:28 +00:00
|
|
|
const struct filter_window mp_filter_windows[] = {
|
|
|
|
{"box", 1, box},
|
2015-02-24 02:13:37 +00:00
|
|
|
{"triangle", 1, triangle},
|
2015-03-27 05:36:27 +00:00
|
|
|
{"bartlett", 1, triangle},
|
2012-03-30 23:13:38 +00:00
|
|
|
{"hanning", 1, hanning},
|
2016-10-26 14:32:57 +00:00
|
|
|
{"tukey", 1, hanning, .taper = 0.5},
|
2012-03-30 23:13:38 +00:00
|
|
|
{"hamming", 1, hamming},
|
|
|
|
{"quadric", 1.5, quadric},
|
2015-03-27 05:36:27 +00:00
|
|
|
{"welch", 1, welch},
|
2015-02-24 00:32:45 +00:00
|
|
|
{"kaiser", 1, kaiser, .params = {6.33, NAN} },
|
2015-03-27 05:36:27 +00:00
|
|
|
{"blackman", 1, blackman, .params = {0.16, NAN} },
|
2016-01-07 10:43:14 +00:00
|
|
|
{"gaussian", 2, gaussian, .params = {1.00, NAN} },
|
vo_opengl: separate kernel and window
This makes the core much more elegant, reusable, reconfigurable and also
allows us to more easily add aliases for specific configurations.
Furthermore, this lets us apply a generic blur factor / window function
to arbitrary filters, so we can finally "mix and match" in order to
fine-tune windowing functions.
A few notes are in order:
1. The current system for configuring scalers is ugly and rapidly
getting unwieldy. I modified the man page to make it a bit more
bearable, but long-term we have to do something about it; especially
since..
2. There's currently no way to affect the blur factor or parameters of
the window functions themselves. For example, I can't actually
fine-tune the kaiser window's param1, since there's simply no way to
do so in the current API - even though filter_kernels.c supports it
just fine!
3. This removes some lesser used filters (especially those which are
purely window functions to begin with). If anybody asks, you can get
eg. the old behavior of scale=hanning by using
scale=box:scale-window=hanning:scale-radius=1 (and yes, the result is
just as terrible as that sounds - which is why nobody should have
been using them in the first place).
4. This changes the semantics of the "triangle" scaler slightly - it now
has an arbitrary radius. This can possibly produce weird results for
people who were previously using scale-down=triangle, especially if
in combination with scale-radius (for the usual upscaling). The
correct fix for this is to use scale-down=bilinear_slow instead,
which is an alias for triangle at radius 1.
In regards to the last point, in future I want to make it so that
filters have a filter-specific "preferred radius" (for the ones that
are arbitrarily tunable), once the configuration system for filters has
been redesigned (in particular in a way that will let us separate scale
and scale-down cleanly). That way, "triangle" can simply have the
preferred radius of 1 by default, while still being tunable. (Rather
than the default radius being hard-coded to 3 always)
2015-03-25 03:40:28 +00:00
|
|
|
{"sinc", 1, sinc},
|
|
|
|
{"jinc", 1.2196698912665045, jinc},
|
|
|
|
{"sphinx", 1.4302966531242027, sphinx},
|
|
|
|
{0}
|
|
|
|
};
|
|
|
|
|
|
|
|
const struct filter_kernel mp_filter_kernels[] = {
|
|
|
|
// Spline filters
|
|
|
|
{{"spline16", 2, spline16}},
|
|
|
|
{{"spline36", 3, spline36}},
|
|
|
|
{{"spline64", 4, spline64}},
|
|
|
|
// Sinc filters
|
vo_opengl: refactor scaler configuration
This merges all of the scaler-related options into a single
configuration struct, and also cleans up the way they're passed through
the code. (For example, the scaler index is no longer threaded through
pass_sample, just the scaler configuration itself, and there's no longer
duplication of the params etc.)
In addition, this commit makes scale-down more principled, and turns it
into a scaler in its own right - so there's no longer an ugly separation
between scale and scale-down in the code.
Finally, the radius stuff has been made more proper - filters always
have a radius now (there's no more radius -1), and get a new .resizable
attribute instead for when it's tunable.
User-visible changes:
1. scale-down has been renamed dscale and now has its own set of config
options (dscale-param1, dscale-radius) etc., instead of reusing
scale-param1 (which was arguably a bug).
2. The default radius is no longer fixed at 3, but instead uses that
filter's preferred radius by default. (Scalers with a default radius
other than 3 include sinc, gaussian, box and triangle)
3. scale-radius etc. now goes down to 0.5, rather than 1.0. 0.5 is the
smallest radius that theoretically makes sense, and indeed it's used
by at least one filter (nearest).
Apart from that, it should just be internal changes only.
Note that this sets up for the refactor discussed in #1720, which would
be to merge scaler and window configurations (include parameters etc.)
into a single, simplified string. In the code, this would now basically
just mean getting rid of all the OPT_FLOATRANGE etc. lines related to
scalers and replacing them by a single function that parses a string and
updates the struct scaler_config as appropriate.
2015-03-26 00:55:32 +00:00
|
|
|
{{"sinc", 2, sinc, .resizable = true}},
|
|
|
|
{{"lanczos", 3, sinc, .resizable = true}, .window = "sinc"},
|
|
|
|
{{"ginseng", 3, sinc, .resizable = true}, .window = "jinc"},
|
vo_opengl: separate kernel and window
This makes the core much more elegant, reusable, reconfigurable and also
allows us to more easily add aliases for specific configurations.
Furthermore, this lets us apply a generic blur factor / window function
to arbitrary filters, so we can finally "mix and match" in order to
fine-tune windowing functions.
A few notes are in order:
1. The current system for configuring scalers is ugly and rapidly
getting unwieldy. I modified the man page to make it a bit more
bearable, but long-term we have to do something about it; especially
since..
2. There's currently no way to affect the blur factor or parameters of
the window functions themselves. For example, I can't actually
fine-tune the kaiser window's param1, since there's simply no way to
do so in the current API - even though filter_kernels.c supports it
just fine!
3. This removes some lesser used filters (especially those which are
purely window functions to begin with). If anybody asks, you can get
eg. the old behavior of scale=hanning by using
scale=box:scale-window=hanning:scale-radius=1 (and yes, the result is
just as terrible as that sounds - which is why nobody should have
been using them in the first place).
4. This changes the semantics of the "triangle" scaler slightly - it now
has an arbitrary radius. This can possibly produce weird results for
people who were previously using scale-down=triangle, especially if
in combination with scale-radius (for the usual upscaling). The
correct fix for this is to use scale-down=bilinear_slow instead,
which is an alias for triangle at radius 1.
In regards to the last point, in future I want to make it so that
filters have a filter-specific "preferred radius" (for the ones that
are arbitrarily tunable), once the configuration system for filters has
been redesigned (in particular in a way that will let us separate scale
and scale-down cleanly). That way, "triangle" can simply have the
preferred radius of 1 by default, while still being tunable. (Rather
than the default radius being hard-coded to 3 always)
2015-03-25 03:40:28 +00:00
|
|
|
// Jinc filters
|
vo_opengl: refactor scaler configuration
This merges all of the scaler-related options into a single
configuration struct, and also cleans up the way they're passed through
the code. (For example, the scaler index is no longer threaded through
pass_sample, just the scaler configuration itself, and there's no longer
duplication of the params etc.)
In addition, this commit makes scale-down more principled, and turns it
into a scaler in its own right - so there's no longer an ugly separation
between scale and scale-down in the code.
Finally, the radius stuff has been made more proper - filters always
have a radius now (there's no more radius -1), and get a new .resizable
attribute instead for when it's tunable.
User-visible changes:
1. scale-down has been renamed dscale and now has its own set of config
options (dscale-param1, dscale-radius) etc., instead of reusing
scale-param1 (which was arguably a bug).
2. The default radius is no longer fixed at 3, but instead uses that
filter's preferred radius by default. (Scalers with a default radius
other than 3 include sinc, gaussian, box and triangle)
3. scale-radius etc. now goes down to 0.5, rather than 1.0. 0.5 is the
smallest radius that theoretically makes sense, and indeed it's used
by at least one filter (nearest).
Apart from that, it should just be internal changes only.
Note that this sets up for the refactor discussed in #1720, which would
be to merge scaler and window configurations (include parameters etc.)
into a single, simplified string. In the code, this would now basically
just mean getting rid of all the OPT_FLOATRANGE etc. lines related to
scalers and replacing them by a single function that parses a string and
updates the struct scaler_config as appropriate.
2015-03-26 00:55:32 +00:00
|
|
|
{{"jinc", 3, jinc, .resizable = true}, .polar = true},
|
|
|
|
{{"ewa_lanczos", 3, jinc, .resizable = true}, .polar = true, .window = "jinc"},
|
|
|
|
{{"ewa_hanning", 3, jinc, .resizable = true}, .polar = true, .window = "hanning" },
|
|
|
|
{{"ewa_ginseng", 3, jinc, .resizable = true}, .polar = true, .window = "sinc"},
|
2015-02-23 23:52:17 +00:00
|
|
|
// Radius is based on the true jinc radius, slightly sharpened as per
|
|
|
|
// calculations by Nicolas Robidoux. Source: Imagemagick's magick/resize.c
|
2015-03-30 04:38:49 +00:00
|
|
|
{{"ewa_lanczossharp", 3.2383154841662362, jinc, .blur = 0.9812505644269356,
|
|
|
|
.resizable = true}, .polar = true, .window = "jinc"},
|
vo_opengl: separate kernel and window
This makes the core much more elegant, reusable, reconfigurable and also
allows us to more easily add aliases for specific configurations.
Furthermore, this lets us apply a generic blur factor / window function
to arbitrary filters, so we can finally "mix and match" in order to
fine-tune windowing functions.
A few notes are in order:
1. The current system for configuring scalers is ugly and rapidly
getting unwieldy. I modified the man page to make it a bit more
bearable, but long-term we have to do something about it; especially
since..
2. There's currently no way to affect the blur factor or parameters of
the window functions themselves. For example, I can't actually
fine-tune the kaiser window's param1, since there's simply no way to
do so in the current API - even though filter_kernels.c supports it
just fine!
3. This removes some lesser used filters (especially those which are
purely window functions to begin with). If anybody asks, you can get
eg. the old behavior of scale=hanning by using
scale=box:scale-window=hanning:scale-radius=1 (and yes, the result is
just as terrible as that sounds - which is why nobody should have
been using them in the first place).
4. This changes the semantics of the "triangle" scaler slightly - it now
has an arbitrary radius. This can possibly produce weird results for
people who were previously using scale-down=triangle, especially if
in combination with scale-radius (for the usual upscaling). The
correct fix for this is to use scale-down=bilinear_slow instead,
which is an alias for triangle at radius 1.
In regards to the last point, in future I want to make it so that
filters have a filter-specific "preferred radius" (for the ones that
are arbitrarily tunable), once the configuration system for filters has
been redesigned (in particular in a way that will let us separate scale
and scale-down cleanly). That way, "triangle" can simply have the
preferred radius of 1 by default, while still being tunable. (Rather
than the default radius being hard-coded to 3 always)
2015-03-25 03:40:28 +00:00
|
|
|
// Similar to the above, but softened instead. This one makes hash patterns
|
|
|
|
// disappear completely. Blur determined by trial and error.
|
2015-03-30 04:38:49 +00:00
|
|
|
{{"ewa_lanczossoft", 3.2383154841662362, jinc, .blur = 1.015,
|
|
|
|
.resizable = true}, .polar = true, .window = "jinc"},
|
2015-03-27 06:22:36 +00:00
|
|
|
// Very soft (blurred) hanning-windowed jinc; removes almost all aliasing.
|
|
|
|
// Blur paramater picked to match orthogonal and diagonal contributions
|
2015-03-30 04:38:49 +00:00
|
|
|
{{"haasnsoft", 3.2383154841662362, jinc, .blur = 1.11, .resizable = true},
|
|
|
|
.polar = true, .window = "hanning"},
|
vo_opengl: separate kernel and window
This makes the core much more elegant, reusable, reconfigurable and also
allows us to more easily add aliases for specific configurations.
Furthermore, this lets us apply a generic blur factor / window function
to arbitrary filters, so we can finally "mix and match" in order to
fine-tune windowing functions.
A few notes are in order:
1. The current system for configuring scalers is ugly and rapidly
getting unwieldy. I modified the man page to make it a bit more
bearable, but long-term we have to do something about it; especially
since..
2. There's currently no way to affect the blur factor or parameters of
the window functions themselves. For example, I can't actually
fine-tune the kaiser window's param1, since there's simply no way to
do so in the current API - even though filter_kernels.c supports it
just fine!
3. This removes some lesser used filters (especially those which are
purely window functions to begin with). If anybody asks, you can get
eg. the old behavior of scale=hanning by using
scale=box:scale-window=hanning:scale-radius=1 (and yes, the result is
just as terrible as that sounds - which is why nobody should have
been using them in the first place).
4. This changes the semantics of the "triangle" scaler slightly - it now
has an arbitrary radius. This can possibly produce weird results for
people who were previously using scale-down=triangle, especially if
in combination with scale-radius (for the usual upscaling). The
correct fix for this is to use scale-down=bilinear_slow instead,
which is an alias for triangle at radius 1.
In regards to the last point, in future I want to make it so that
filters have a filter-specific "preferred radius" (for the ones that
are arbitrarily tunable), once the configuration system for filters has
been redesigned (in particular in a way that will let us separate scale
and scale-down cleanly). That way, "triangle" can simply have the
preferred radius of 1 by default, while still being tunable. (Rather
than the default radius being hard-coded to 3 always)
2015-03-25 03:40:28 +00:00
|
|
|
// Cubic filters
|
|
|
|
{{"bicubic", 2, bicubic}},
|
|
|
|
{{"bcspline", 2, cubic_bc, .params = {0.5, 0.5} }},
|
|
|
|
{{"catmull_rom", 2, cubic_bc, .params = {0.0, 0.5} }},
|
|
|
|
{{"mitchell", 2, cubic_bc, .params = {1.0/3.0, 1.0/3.0} }},
|
2015-12-26 17:37:03 +00:00
|
|
|
{{"robidoux", 2, cubic_bc, .params = {12 / (19 + 9 * M_SQRT2),
|
|
|
|
113 / (58 + 216 * M_SQRT2)} }},
|
|
|
|
{{"robidouxsharp", 2, cubic_bc, .params = {6 / (13 + 7 * M_SQRT2),
|
|
|
|
7 / (2 + 12 * M_SQRT2)} }},
|
|
|
|
{{"ewa_robidoux", 2, cubic_bc, .params = {12 / (19 + 9 * M_SQRT2),
|
|
|
|
113 / (58 + 216 * M_SQRT2)}},
|
|
|
|
.polar = true},
|
|
|
|
{{"ewa_robidouxsharp", 2,cubic_bc, .params = {6 / (13 + 7 * M_SQRT2),
|
|
|
|
7 / (2 + 12 * M_SQRT2)}},
|
|
|
|
.polar = true},
|
2015-06-17 20:23:08 +00:00
|
|
|
// Miscellaneous filters
|
vo_opengl: refactor scaler configuration
This merges all of the scaler-related options into a single
configuration struct, and also cleans up the way they're passed through
the code. (For example, the scaler index is no longer threaded through
pass_sample, just the scaler configuration itself, and there's no longer
duplication of the params etc.)
In addition, this commit makes scale-down more principled, and turns it
into a scaler in its own right - so there's no longer an ugly separation
between scale and scale-down in the code.
Finally, the radius stuff has been made more proper - filters always
have a radius now (there's no more radius -1), and get a new .resizable
attribute instead for when it's tunable.
User-visible changes:
1. scale-down has been renamed dscale and now has its own set of config
options (dscale-param1, dscale-radius) etc., instead of reusing
scale-param1 (which was arguably a bug).
2. The default radius is no longer fixed at 3, but instead uses that
filter's preferred radius by default. (Scalers with a default radius
other than 3 include sinc, gaussian, box and triangle)
3. scale-radius etc. now goes down to 0.5, rather than 1.0. 0.5 is the
smallest radius that theoretically makes sense, and indeed it's used
by at least one filter (nearest).
Apart from that, it should just be internal changes only.
Note that this sets up for the refactor discussed in #1720, which would
be to merge scaler and window configurations (include parameters etc.)
into a single, simplified string. In the code, this would now basically
just mean getting rid of all the OPT_FLOATRANGE etc. lines related to
scalers and replacing them by a single function that parses a string and
updates the struct scaler_config as appropriate.
2015-03-26 00:55:32 +00:00
|
|
|
{{"box", 1, box, .resizable = true}},
|
vo_opengl: separate kernel and window
This makes the core much more elegant, reusable, reconfigurable and also
allows us to more easily add aliases for specific configurations.
Furthermore, this lets us apply a generic blur factor / window function
to arbitrary filters, so we can finally "mix and match" in order to
fine-tune windowing functions.
A few notes are in order:
1. The current system for configuring scalers is ugly and rapidly
getting unwieldy. I modified the man page to make it a bit more
bearable, but long-term we have to do something about it; especially
since..
2. There's currently no way to affect the blur factor or parameters of
the window functions themselves. For example, I can't actually
fine-tune the kaiser window's param1, since there's simply no way to
do so in the current API - even though filter_kernels.c supports it
just fine!
3. This removes some lesser used filters (especially those which are
purely window functions to begin with). If anybody asks, you can get
eg. the old behavior of scale=hanning by using
scale=box:scale-window=hanning:scale-radius=1 (and yes, the result is
just as terrible as that sounds - which is why nobody should have
been using them in the first place).
4. This changes the semantics of the "triangle" scaler slightly - it now
has an arbitrary radius. This can possibly produce weird results for
people who were previously using scale-down=triangle, especially if
in combination with scale-radius (for the usual upscaling). The
correct fix for this is to use scale-down=bilinear_slow instead,
which is an alias for triangle at radius 1.
In regards to the last point, in future I want to make it so that
filters have a filter-specific "preferred radius" (for the ones that
are arbitrarily tunable), once the configuration system for filters has
been redesigned (in particular in a way that will let us separate scale
and scale-down cleanly). That way, "triangle" can simply have the
preferred radius of 1 by default, while still being tunable. (Rather
than the default radius being hard-coded to 3 always)
2015-03-25 03:40:28 +00:00
|
|
|
{{"nearest", 0.5, box}},
|
vo_opengl: refactor scaler configuration
This merges all of the scaler-related options into a single
configuration struct, and also cleans up the way they're passed through
the code. (For example, the scaler index is no longer threaded through
pass_sample, just the scaler configuration itself, and there's no longer
duplication of the params etc.)
In addition, this commit makes scale-down more principled, and turns it
into a scaler in its own right - so there's no longer an ugly separation
between scale and scale-down in the code.
Finally, the radius stuff has been made more proper - filters always
have a radius now (there's no more radius -1), and get a new .resizable
attribute instead for when it's tunable.
User-visible changes:
1. scale-down has been renamed dscale and now has its own set of config
options (dscale-param1, dscale-radius) etc., instead of reusing
scale-param1 (which was arguably a bug).
2. The default radius is no longer fixed at 3, but instead uses that
filter's preferred radius by default. (Scalers with a default radius
other than 3 include sinc, gaussian, box and triangle)
3. scale-radius etc. now goes down to 0.5, rather than 1.0. 0.5 is the
smallest radius that theoretically makes sense, and indeed it's used
by at least one filter (nearest).
Apart from that, it should just be internal changes only.
Note that this sets up for the refactor discussed in #1720, which would
be to merge scaler and window configurations (include parameters etc.)
into a single, simplified string. In the code, this would now basically
just mean getting rid of all the OPT_FLOATRANGE etc. lines related to
scalers and replacing them by a single function that parses a string and
updates the struct scaler_config as appropriate.
2015-03-26 00:55:32 +00:00
|
|
|
{{"triangle", 1, triangle, .resizable = true}},
|
|
|
|
{{"gaussian", 2, gaussian, .params = {1.0, NAN}, .resizable = true}},
|
vo_opengl: separate kernel and window
This makes the core much more elegant, reusable, reconfigurable and also
allows us to more easily add aliases for specific configurations.
Furthermore, this lets us apply a generic blur factor / window function
to arbitrary filters, so we can finally "mix and match" in order to
fine-tune windowing functions.
A few notes are in order:
1. The current system for configuring scalers is ugly and rapidly
getting unwieldy. I modified the man page to make it a bit more
bearable, but long-term we have to do something about it; especially
since..
2. There's currently no way to affect the blur factor or parameters of
the window functions themselves. For example, I can't actually
fine-tune the kaiser window's param1, since there's simply no way to
do so in the current API - even though filter_kernels.c supports it
just fine!
3. This removes some lesser used filters (especially those which are
purely window functions to begin with). If anybody asks, you can get
eg. the old behavior of scale=hanning by using
scale=box:scale-window=hanning:scale-radius=1 (and yes, the result is
just as terrible as that sounds - which is why nobody should have
been using them in the first place).
4. This changes the semantics of the "triangle" scaler slightly - it now
has an arbitrary radius. This can possibly produce weird results for
people who were previously using scale-down=triangle, especially if
in combination with scale-radius (for the usual upscaling). The
correct fix for this is to use scale-down=bilinear_slow instead,
which is an alias for triangle at radius 1.
In regards to the last point, in future I want to make it so that
filters have a filter-specific "preferred radius" (for the ones that
are arbitrarily tunable), once the configuration system for filters has
been redesigned (in particular in a way that will let us separate scale
and scale-down cleanly). That way, "triangle" can simply have the
preferred radius of 1 by default, while still being tunable. (Rather
than the default radius being hard-coded to 3 always)
2015-03-25 03:40:28 +00:00
|
|
|
{{0}}
|
2012-03-30 23:13:38 +00:00
|
|
|
};
|