RepoMirrors
/
mpv
mirror of https://github.com/mpv-player/mpv
1
0
Fork 0
Code Issues Releases Wiki Activity
mpv/video/out/filter_kernels.c

404 lines
13 KiB
C
Raw Normal View History

libvo: add vo_gl3 This new vo is heavily based on vo_gl.c. It provides better scale filters, dithering, and optional color management with LittleCMS2. It requires OpenGL 3. Many features are enabled by default, so it will be slower than vo_gl. However, it can be tuned to behave almost as vo_gl.
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)
vo_opengl: add spline64 filter kernel The coefficients are taken from fmtconv plugin for vapoursynth: https://github.com/vapoursynth/fmtconv/blob/master/src/fmtc/ContFirSpline64.cpp The package is licensed under WTFPL, and it's from the same author of Dither plugin for avisynth.
2014-08-25 20:15:42 +00:00
*
Update license headers Signed-off-by: wm4 <wm4@nowhere>
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
Update license headers Signed-off-by: wm4 <wm4@nowhere>
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.
libvo: add vo_gl3 This new vo is heavily based on vo_gl.c. It provides better scale filters, dithering, and optional color management with LittleCMS2. It requires OpenGL 3. Many features are enabled by default, so it will be slower than vo_gl. However, it can be tuned to behave almost as vo_gl.
2012-03-30 23:13:38 +00:00
*
Update license headers Signed-off-by: wm4 <wm4@nowhere>
2015-04-13 07:36:54 +00:00
* This file is part of mpv.
libvo: add vo_gl3 This new vo is heavily based on vo_gl.c. It provides better scale filters, dithering, and optional color management with LittleCMS2. It requires OpenGL 3. Many features are enabled by default, so it will be slower than vo_gl. However, it can be tuned to behave almost as vo_gl.
2012-03-30 23:13:38 +00:00
*
filter_kernels: relicense under BSD To get a uniform license for this file, relicense the mpv parts to BSD as well. But leave the door open for a later change to LGPL. (All non-Glumpy code was written within mpv, and all mpv authors have agreed to LGPL relicensing.) Closes #2688.
2016-01-07 10:27:18 +00:00
* This file can be distributed under the 3-clause license ("New BSD License").
libvo: add vo_gl3 This new vo is heavily based on vo_gl.c. It provides better scale filters, dithering, and optional color management with LittleCMS2. It requires OpenGL 3. Many features are enabled by default, so it will be slower than vo_gl. However, it can be tuned to behave almost as vo_gl.
2012-03-30 23:13:38 +00:00
*
filter_kernels: relicense under BSD To get a uniform license for this file, relicense the mpv parts to BSD as well. But leave the door open for a later change to LGPL. (All non-Glumpy code was written within mpv, and all mpv authors have agreed to LGPL relicensing.) Closes #2688.
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.
libvo: add vo_gl3 This new vo is heavily based on vo_gl.c. It provides better scale filters, dithering, and optional color management with LittleCMS2. It requires OpenGL 3. Many features are enabled by default, so it will be slower than vo_gl. However, it can be tuned to behave almost as vo_gl.
2012-03-30 23:13:38 +00:00
*/
#include <stddef.h>
#include <string.h>
#include <math.h>
#include <assert.h>
#include "filter_kernels.h"
filter_kernels: Keep f.radius in terms of dest/filter coords. The existing code modifies f.radius so that it is in terms of the filter sample radius (in the source coordinate space) and has some small errors because of this behavior. This commit changes f.radius so that it is always in terms of the filter function radius (in the destination coordinate space). The sample radius can always be derived by multiplying f.radius by filter_scale, which is the new, more descriptive name for the previous inv_scale.
2017-03-05 01:13:18 +00:00
#include "common/common.h"
libvo: add vo_gl3 This new vo is heavily based on vo_gl.c. It provides better scale filters, dithering, and optional color management with LittleCMS2. It requires OpenGL 3. Many features are enabled by default, so it will be slower than vo_gl. However, it can be tuned to behave almost as vo_gl.
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;
}
libvo: add vo_gl3 This new vo is heavily based on vo_gl.c. It provides better scale filters, dithering, and optional color management with LittleCMS2. It requires OpenGL 3. Many features are enabled by default, so it will be slower than vo_gl. However, it can be tuned to behave almost as vo_gl.
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)
libvo: add vo_gl3 This new vo is heavily based on vo_gl.c. It provides better scale filters, dithering, and optional color management with LittleCMS2. It requires OpenGL 3. Many features are enabled by default, so it will be slower than vo_gl. However, it can be tuned to behave almost as vo_gl.
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
filter_kernels: Keep f.radius in terms of dest/filter coords. The existing code modifies f.radius so that it is in terms of the filter sample radius (in the source coordinate space) and has some small errors because of this behavior. This commit changes f.radius so that it is always in terms of the filter function radius (in the destination coordinate space). The sample radius can always be derived by multiplying f.radius by filter_scale, which is the new, more descriptive name for the previous inv_scale.
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
vo_opengl: add ewa_lanczos upscaler (aka jinc) This is the polar (elliptic weighted average) version of lanczos. This introduces a general new form of polar filters.
2015-01-04 22:11:27 +00:00
if (filter->polar) {
filter_kernels: Keep f.radius in terms of dest/filter coords. The existing code modifies f.radius so that it is in terms of the filter sample radius (in the source coordinate space) and has some small errors because of this behavior. This commit changes f.radius so that it is always in terms of the filter function radius (in the destination coordinate space). The sample radius can always be derived by multiplying f.radius by filter_scale, which is the new, more descriptive name for the previous inv_scale.
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
filter_kernels: Keep f.radius in terms of dest/filter coords. The existing code modifies f.radius so that it is in terms of the filter sample radius (in the source coordinate space) and has some small errors because of this behavior. This commit changes f.radius so that it is always in terms of the filter function radius (in the destination coordinate space). The sample radius can always be derived by multiplying f.radius by filter_scale, which is the new, more descriptive name for the previous inv_scale.
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;
}
vo_opengl: add ewa_lanczos upscaler (aka jinc) This is the polar (elliptic weighted average) version of lanczos. This introduces a general new form of polar filters.
2015-01-04 22:11:27 +00:00
return true;
}
filter_kernels: Keep f.radius in terms of dest/filter coords. The existing code modifies f.radius so that it is in terms of the filter sample radius (in the source coordinate space) and has some small errors because of this behavior. This commit changes f.radius so that it is always in terms of the filter function radius (in the destination coordinate space). The sample radius can always be derived by multiplying f.radius by filter_scale, which is the new, more descriptive name for the previous inv_scale.
2017-03-05 01:13:18 +00:00
int size = ceil(2.0 * src_radius);
libvo: add vo_gl3 This new vo is heavily based on vo_gl.c. It provides better scale filters, dithering, and optional color management with LittleCMS2. It requires OpenGL 3. Many features are enabled by default, so it will be slower than vo_gl. However, it can be tuned to behave almost as vo_gl.
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];
filter_kernels: Keep f.radius in terms of dest/filter coords. The existing code modifies f.radius so that it is in terms of the filter sample radius (in the source coordinate space) and has some small errors because of this behavior. This commit changes f.radius so that it is always in terms of the filter function radius (in the destination coordinate space). The sample radius can always be derived by multiplying f.radius by filter_scale, which is the new, more descriptive name for the previous inv_scale.
2017-03-05 01:13:18 +00:00
filter->filter_scale = (filter->size/2.0) / filter->f.radius;
libvo: add vo_gl3 This new vo is heavily based on vo_gl.c. It provides better scale filters, dithering, and optional color management with LittleCMS2. It requires OpenGL 3. Many features are enabled by default, so it will be slower than vo_gl. However, it can be tuned to behave almost as vo_gl.
2012-03-30 23:13:38 +00:00
return false;
}
}
filter_kernels: add ability to taper kernels/windows This allows us to define the tukey window (and other tapered windows). Also add a missing option definition for `wblur` while we're at it, to make testing out window-related stuff easier.
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
{
filter_kernels: add ability to taper kernels/windows This allows us to define the tukey window (and other tapered windows). Also add a missing option definition for `wblur` while we're at it, to make testing out window-related stuff easier.
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);
filter_kernels: Apply blur/taper before culling radius. Modifications to the input coordinates should all be performed before the final range check against the filter boundaries. However, in the existing code, the blur/taper is applied after the filter radius check is performed. Thus, effectively the filter radius cutoff is applied to only-downscaling-metric-modified coordinates, not the final coordinates. Correct this issue and restructure the returns a bit to make it more obvious what is being done.
2017-03-04 04:35:22 +00:00
if (x < kernel->radius)
return kernel->weight(kernel, x);
return 0.0;
filter_kernels: add ability to taper kernels/windows This allows us to define the tukey window (and other tapered windows). Also add a missing option definition for `wblur` while we're at it, to make testing out window-related stuff easier.
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);
vo_opengl: generalize --scale-clamp etc. This can help fight ringing without completely killing it, thus providing a middle-ground between ringing and aliasing.
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
}
libvo: add vo_gl3 This new vo is heavily based on vo_gl.c. It provides better scale filters, dithering, and optional color management with LittleCMS2. It requires OpenGL 3. Many features are enabled by default, so it will be slower than vo_gl. However, it can be tuned to behave almost as vo_gl.
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].
filter_kernels: add ability to taper kernels/windows This allows us to define the tukey window (and other tapered windows). Also add a missing option definition for `wblur` while we're at it, to make testing out window-related stuff easier.
2016-10-26 14:32:57 +00:00
static void mp_compute_weights(struct filter_kernel *filter, double f,
float *out_w)
libvo: add vo_gl3 This new vo is heavily based on vo_gl.c. It provides better scale filters, dithering, and optional color management with LittleCMS2. It requires OpenGL 3. Many features are enabled by default, so it will be slower than vo_gl. However, it can be tuned to behave almost as vo_gl.
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);
filter_kernels: Keep f.radius in terms of dest/filter coords. The existing code modifies f.radius so that it is in terms of the filter sample radius (in the source coordinate space) and has some small errors because of this behavior. This commit changes f.radius so that it is always in terms of the filter function radius (in the destination coordinate space). The sample radius can always be derived by multiplying f.radius by filter_scale, which is the new, more descriptive name for the previous inv_scale.
2017-03-05 01:13:18 +00:00
double w = sample_filter(filter, x / filter->filter_scale);
libvo: add vo_gl3 This new vo is heavily based on vo_gl.c. It provides better scale filters, dithering, and optional color management with LittleCMS2. It requires OpenGL 3. Many features are enabled by default, so it will be slower than vo_gl. However, it can be tuned to behave almost as vo_gl.
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
libvo: add vo_gl3 This new vo is heavily based on vo_gl.c. It provides better scale filters, dithering, and optional color management with LittleCMS2. It requires OpenGL 3. Many features are enabled by default, so it will be slower than vo_gl. However, it can be tuned to behave almost as vo_gl.
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
vo_opengl: refactor scaler LUT weight packing/loading This is mostly done so we can support using textures with more components than the scaler LUTs have entries. But while we're at it, also change the way the weights are packed so that they're always sequential with no gaps. This allows us to simplify pass_sample_separated_get_weights as well.
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)
filter_kernels: add warnings for potential LUT sampling error
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].
vo_opengl: refactor scaler LUT weight packing/loading This is mostly done so we can support using textures with more components than the scaler LUTs have entries. But while we're at it, also change the way the weights are packed so that they're always sequential with no gaps. This allows us to simplify pass_sample_separated_get_weights as well.
2017-08-27 07:15:50 +00:00
void mp_compute_lut(struct filter_kernel *filter, int count, int stride,
float *out_array)
libvo: add vo_gl3 This new vo is heavily based on vo_gl.c. It provides better scale filters, dithering, and optional color management with LittleCMS2. It requires OpenGL 3. Many features are enabled by default, so it will be slower than vo_gl. However, it can be tuned to behave almost as vo_gl.
2012-03-30 23:13:38 +00:00
{
vo_opengl: remove 1D texture usage Broke operation with GLSL. Since 1D texture usage was apparently (and mysteriously) good for speed, it might be added back, but it's unknown how to do so in a clean way.
2015-01-18 15:28:41 +00:00
if (filter->polar) {
filter_kernels: add radius cutoff functionality This allows filter functions to be prematurely cut off once their contributions start becoming insignificant. This effectively prevents wasted GPU time sampling from parts of the function that are essentially reduced to zero by the window function, providing anywhere from a 10% to 20% speedup. (5700μs -> 4700μs for me)
2017-07-03 09:23:48 +00:00
filter->radius_cutoff = 0.0;
vo_opengl: clean up ewa_lanczos code This fixes compatibility with GLES 2.0 and makes the code a bit neater in general. It also properly forces indirect scaling for subsampled video regardless of the lscale setting.
2015-01-17 16:28:47 +00:00
// Compute a 1D array indexed by radius
vo_opengl: remove 1D texture usage Broke operation with GLSL. Since 1D texture usage was apparently (and mysteriously) good for speed, it might be added back, but it's unknown how to do so in a clean way.
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);
filter_kernels: add ability to taper kernels/windows This allows us to define the tukey window (and other tapered windows). Also add a missing option definition for `wblur` while we're at it, to make testing out window-related stuff easier.
2016-10-26 14:32:57 +00:00
out_array[x] = sample_filter(filter, r);
filter_kernels: add radius cutoff functionality This allows filter functions to be prematurely cut off once their contributions start becoming insignificant. This effectively prevents wasted GPU time sampling from parts of the function that are essentially reduced to zero by the window function, providing anywhere from a 10% to 20% speedup. (5700μs -> 4700μs for me)
2017-07-03 09:23:48 +00:00
if (fabs(out_array[x]) > filter->value_cutoff)
filter->radius_cutoff = r;
vo_opengl: remove 1D texture usage Broke operation with GLSL. Since 1D texture usage was apparently (and mysteriously) good for speed, it might be added back, but it's unknown how to do so in a clean way.
2015-01-18 15:28:41 +00:00
}
} else {
vo_opengl: clean up ewa_lanczos code This fixes compatibility with GLES 2.0 and makes the code a bit neater in general. It also properly forces indirect scaling for subsampled video regardless of the lscale setting.
2015-01-17 16:28:47 +00:00
// Compute a 2D array indexed by subpixel position
vo_opengl: remove 1D texture usage Broke operation with GLSL. Since 1D texture usage was apparently (and mysteriously) good for speed, it might be added back, but it's unknown how to do so in a clean way.
2015-01-18 15:28:41 +00:00
for (int n = 0; n < count; n++) {
filter_kernels: add ability to taper kernels/windows This allows us to define the tukey window (and other tapered windows). Also add a missing option definition for `wblur` while we're at it, to make testing out window-related stuff easier.
2016-10-26 14:32:57 +00:00
mp_compute_weights(filter, n / (double)(count - 1),
vo_opengl: refactor scaler LUT weight packing/loading This is mostly done so we can support using textures with more components than the scaler LUTs have entries. But while we're at it, also change the way the weights are packed so that they're always sequential with no gaps. This allows us to simplify pass_sample_separated_get_weights as well.
2017-08-27 07:15:50 +00:00
out_array + stride * n);
vo_opengl: remove 1D texture usage Broke operation with GLSL. Since 1D texture usage was apparently (and mysteriously) good for speed, it might be added back, but it's unknown how to do so in a clean way.
2015-01-18 15:28:41 +00:00
}
vo_opengl: add ewa_lanczos upscaler (aka jinc) This is the polar (elliptic weighted average) version of lanczos. This introduces a general new form of polar filters.
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;
libvo: add vo_gl3 This new vo is heavily based on vo_gl.c. It provides better scale filters, dithering, and optional color management with LittleCMS2. It requires OpenGL 3. Many features are enabled by default, so it will be slower than vo_gl. However, it can be tuned to behave almost as vo_gl.
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)
filter_kernels: add nearest neighbour scaling This is useful for playing content containing pixel art that hasn't been pre-scaled, such as TASVideos' high quality encodes. The implementation is lifted from <https://code.google.com/p/glumpy/source/browse/glumpy/image/filter.py#413>.
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;
filter_kernels: add nearest neighbour scaling This is useful for playing content containing pixel art that hasn't been pre-scaled, such as TASVideos' high quality encodes. The implementation is lifted from <https://code.google.com/p/glumpy/source/browse/glumpy/image/filter.py#413>.
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)
libvo: add vo_gl3 This new vo is heavily based on vo_gl.c. It provides better scale filters, dithering, and optional color management with LittleCMS2. It requires OpenGL 3. Many features are enabled by default, so it will be slower than vo_gl. However, it can be tuned to behave almost as vo_gl.
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));
libvo: add vo_gl3 This new vo is heavily based on vo_gl.c. It provides better scale filters, dithering, and optional color management with LittleCMS2. It requires OpenGL 3. Many features are enabled by default, so it will be slower than vo_gl. However, it can be tuned to behave almost as vo_gl.
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)
libvo: add vo_gl3 This new vo is heavily based on vo_gl.c. It provides better scale filters, dithering, and optional color management with LittleCMS2. It requires OpenGL 3. Many features are enabled by default, so it will be slower than vo_gl. However, it can be tuned to behave almost as vo_gl.
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)
libvo: add vo_gl3 This new vo is heavily based on vo_gl.c. It provides better scale filters, dithering, and optional color management with LittleCMS2. It requires OpenGL 3. Many features are enabled by default, so it will be slower than vo_gl. However, it can be tuned to behave almost as vo_gl.
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)
libvo: add vo_gl3 This new vo is heavily based on vo_gl.c. It provides better scale filters, dithering, and optional color management with LittleCMS2. It requires OpenGL 3. Many features are enabled by default, so it will be slower than vo_gl. However, it can be tuned to behave almost as vo_gl.
2012-03-30 23:13:38 +00:00
{
filter_kernels: fix quadric window 3909e4cdfcb9 seems to have replaced this 0.5 constant by 0.75, using its presence in glumpy as justification. 0.75 is clearly a bug in glumpy, as its own source code doesn't even match the comment immediately above it. Every other implementation of this window I could find uses 0.5, including e.g. ImageMagick.
2021-05-04 11:12:58 +00:00
if (x < 0.5) {
libvo: add vo_gl3 This new vo is heavily based on vo_gl.c. It provides better scale filters, dithering, and optional color management with LittleCMS2. It requires OpenGL 3. Many features are enabled by default, so it will be slower than vo_gl. However, it can be tuned to behave almost as vo_gl.
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;
libvo: add vo_gl3 This new vo is heavily based on vo_gl.c. It provides better scale filters, dithering, and optional color management with LittleCMS2. It requires OpenGL 3. Many features are enabled by default, so it will be slower than vo_gl. However, it can be tuned to behave almost as vo_gl.
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)
libvo: add vo_gl3 This new vo is heavily based on vo_gl.c. It provides better scale filters, dithering, and optional color management with LittleCMS2. It requires OpenGL 3. Many features are enabled by default, so it will be slower than vo_gl. However, it can be tuned to behave almost as vo_gl.
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));
libvo: add vo_gl3 This new vo is heavily based on vo_gl.c. It provides better scale filters, dithering, and optional color management with LittleCMS2. It requires OpenGL 3. Many features are enabled by default, so it will be slower than vo_gl. However, it can be tuned to behave almost as vo_gl.
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)
libvo: add vo_gl3 This new vo is heavily based on vo_gl.c. It provides better scale filters, dithering, and optional color management with LittleCMS2. It requires OpenGL 3. Many features are enabled by default, so it will be slower than vo_gl. However, it can be tuned to behave almost as vo_gl.
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;
libvo: add vo_gl3 This new vo is heavily based on vo_gl.c. It provides better scale filters, dithering, and optional color management with LittleCMS2. It requires OpenGL 3. Many features are enabled by default, so it will be slower than vo_gl. However, it can be tuned to behave almost as vo_gl.
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;
libvo: add vo_gl3 This new vo is heavily based on vo_gl.c. It provides better scale filters, dithering, and optional color management with LittleCMS2. It requires OpenGL 3. Many features are enabled by default, so it will be slower than vo_gl. However, it can be tuned to behave almost as vo_gl.
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;
libvo: add vo_gl3 This new vo is heavily based on vo_gl.c. It provides better scale filters, dithering, and optional color management with LittleCMS2. It requires OpenGL 3. Many features are enabled by default, so it will be slower than vo_gl. However, it can be tuned to behave almost as vo_gl.
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;
libvo: add vo_gl3 This new vo is heavily based on vo_gl.c. It provides better scale filters, dithering, and optional color management with LittleCMS2. It requires OpenGL 3. Many features are enabled by default, so it will be slower than vo_gl. However, it can be tuned to behave almost as vo_gl.
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)
libvo: add vo_gl3 This new vo is heavily based on vo_gl.c. It provides better scale filters, dithering, and optional color management with LittleCMS2. It requires OpenGL 3. Many features are enabled by default, so it will be slower than vo_gl. However, it can be tuned to behave almost as vo_gl.
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;
libvo: add vo_gl3 This new vo is heavily based on vo_gl.c. It provides better scale filters, dithering, and optional color management with LittleCMS2. It requires OpenGL 3. Many features are enabled by default, so it will be slower than vo_gl. However, it can be tuned to behave almost as vo_gl.
2012-03-30 23:13:38 +00:00
}
filter_kernels: add bartlett, blackman and welch windows
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;
}
filter_kernels: redefine redundant filters mitchell, hermite and catmull_rom are all B/C splines and can share the code which was already written for mitchell. This just redefines them in terms of that.
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)
libvo: add vo_gl3 This new vo is heavily based on vo_gl.c. It provides better scale filters, dithering, and optional color management with LittleCMS2. It requires OpenGL 3. Many features are enabled by default, so it will be slower than vo_gl. However, it can be tuned to behave almost as vo_gl.
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) {
libvo: add vo_gl3 This new vo is heavily based on vo_gl.c. It provides better scale filters, dithering, and optional color management with LittleCMS2. It requires OpenGL 3. Many features are enabled by default, so it will be slower than vo_gl. However, it can be tuned to behave almost as vo_gl.
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) {
libvo: add vo_gl3 This new vo is heavily based on vo_gl.c. It provides better scale filters, dithering, and optional color management with LittleCMS2. It requires OpenGL 3. Many features are enabled by default, so it will be slower than vo_gl. However, it can be tuned to behave almost as vo_gl.
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;
libvo: add vo_gl3 This new vo is heavily based on vo_gl.c. It provides better scale filters, dithering, and optional color management with LittleCMS2. It requires OpenGL 3. Many features are enabled by default, so it will be slower than vo_gl. However, it can be tuned to behave almost as vo_gl.
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)
libvo: add vo_gl3 This new vo is heavily based on vo_gl.c. It provides better scale filters, dithering, and optional color management with LittleCMS2. It requires OpenGL 3. Many features are enabled by default, so it will be slower than vo_gl. However, it can be tuned to behave almost as vo_gl.
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) {
libvo: add vo_gl3 This new vo is heavily based on vo_gl.c. It provides better scale filters, dithering, and optional color management with LittleCMS2. It requires OpenGL 3. Many features are enabled by default, so it will be slower than vo_gl. However, it can be tuned to behave almost as vo_gl.
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);
}
libvo: add vo_gl3 This new vo is heavily based on vo_gl.c. It provides better scale filters, dithering, and optional color management with LittleCMS2. It requires OpenGL 3. Many features are enabled by default, so it will be slower than vo_gl. However, it can be tuned to behave almost as vo_gl.
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)
libvo: add vo_gl3 This new vo is heavily based on vo_gl.c. It provides better scale filters, dithering, and optional color management with LittleCMS2. It requires OpenGL 3. Many features are enabled by default, so it will be slower than vo_gl. However, it can be tuned to behave almost as vo_gl.
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) {
libvo: add vo_gl3 This new vo is heavily based on vo_gl.c. It provides better scale filters, dithering, and optional color management with LittleCMS2. It requires OpenGL 3. Many features are enabled by default, so it will be slower than vo_gl. However, it can be tuned to behave almost as vo_gl.
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);
}
libvo: add vo_gl3 This new vo is heavily based on vo_gl.c. It provides better scale filters, dithering, and optional color management with LittleCMS2. It requires OpenGL 3. Many features are enabled by default, so it will be slower than vo_gl. However, it can be tuned to behave almost as vo_gl.
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)
vo_opengl: add spline64 filter kernel The coefficients are taken from fmtconv plugin for vapoursynth: https://github.com/vapoursynth/fmtconv/blob/master/src/fmtc/ContFirSpline64.cpp The package is licensed under WTFPL, and it's from the same author of Dither plugin for avisynth.
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) {
filter_kernels: correct spline64 kernel This seems to have had some copy/paste errors. It should now match the implementation in fmtconv: https://github.com/EleonoreMizo/fmtconv/blob/00453a86dd73/src/fmtcl/ContFirSpline64.cpp#L58-L76
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) {
filter_kernels: correct spline64 kernel This seems to have had some copy/paste errors. It should now match the implementation in fmtconv: https://github.com/EleonoreMizo/fmtconv/blob/00453a86dd73/src/fmtcl/ContFirSpline64.cpp#L58-L76
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) {
filter_kernels: correct spline64 kernel This seems to have had some copy/paste errors. It should now match the implementation in fmtconv: https://github.com/EleonoreMizo/fmtconv/blob/00453a86dd73/src/fmtcl/ContFirSpline64.cpp#L58-L76
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 {
filter_kernels: correct spline64 kernel This seems to have had some copy/paste errors. It should now match the implementation in fmtconv: https://github.com/EleonoreMizo/fmtconv/blob/00453a86dd73/src/fmtcl/ContFirSpline64.cpp#L58-L76
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
}
vo_opengl: add spline64 filter kernel The coefficients are taken from fmtconv plugin for vapoursynth: https://github.com/vapoursynth/fmtconv/blob/master/src/fmtc/ContFirSpline64.cpp The package is licensed under WTFPL, and it's from the same author of Dither plugin for avisynth.
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)
libvo: add vo_gl3 This new vo is heavily based on vo_gl.c. It provides better scale filters, dithering, and optional color management with LittleCMS2. It requires OpenGL 3. Many features are enabled by default, so it will be slower than vo_gl. However, it can be tuned to behave almost as vo_gl.
2012-03-30 23:13:38 +00:00
{
filter_kernels: improve the gaussian function Commit 3909e4cd ended up losing the ability to tune the gaussian window, which this commit trivially reintroduces. The constant scaling factor (present in the code copied from glumpy) also goes against filter_kernels.c conventions, which is that f(0.0) = 1 (and the invoking code takes care of normalization), and has been removed. The values of this new gaussian function corresponds to different functions when compared against the old version. To translate the old values p1 to the new values p2 requires solving 2^(e/p1) = e^(2/p2) or p2 = p1 * 2/(e * ln(2)) ≈ p1 * 1.0615 In other words, to get the old default in the new function requires setting scale-param1 to 1.0615. (The new function is *slightly* sharper by default) (Though most users should probably not notice the change)
2016-01-07 10:43:14 +00:00
return exp(-2.0 * x * x / p->params[0]);
libvo: add vo_gl3 This new vo is heavily based on vo_gl.c. It provides better scale filters, dithering, and optional color management with LittleCMS2. It requires OpenGL 3. Many features are enabled by default, so it will be slower than vo_gl. However, it can be tuned to behave almost as vo_gl.
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)
libvo: add vo_gl3 This new vo is heavily based on vo_gl.c. It provides better scale filters, dithering, and optional color management with LittleCMS2. It requires OpenGL 3. Many features are enabled by default, so it will be slower than vo_gl. However, it can be tuned to behave almost as vo_gl.
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)
libvo: add vo_gl3 This new vo is heavily based on vo_gl.c. It provides better scale filters, dithering, and optional color management with LittleCMS2. It requires OpenGL 3. Many features are enabled by default, so it will be slower than vo_gl. However, it can be tuned to behave almost as vo_gl.
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;
libvo: add vo_gl3 This new vo is heavily based on vo_gl.c. It provides better scale filters, dithering, and optional color management with LittleCMS2. It requires OpenGL 3. Many features are enabled by default, so it will be slower than vo_gl. However, it can be tuned to behave almost as vo_gl.
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)
vo_opengl: add ewa_lanczos upscaler (aka jinc) This is the polar (elliptic weighted average) version of lanczos. This introduces a general new form of polar filters.
2015-01-04 22:11:27 +00:00
{
filter_kernels: minor code cleanup of jinc stuff No point in duplicating this check all over the place. No point in really having it in the first place, to be perfectly honest, j1 should not be THAT badly behaved.
2015-02-23 15:20:13 +00:00
if (fabs(x) < 1e-8)
vo_opengl: add ewa_lanczos upscaler (aka jinc) This is the polar (elliptic weighted average) version of lanczos. This introduces a general new form of polar filters.
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;
filter_kernels: add ewa_hanning This is suggested in a thesis by Andreas Gustafsson, and seems to produce very a bit less ringing than lanczos at high radius.
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)
libvo: add vo_gl3 This new vo is heavily based on vo_gl.c. It provides better scale filters, dithering, and optional color management with LittleCMS2. It requires OpenGL 3. Many features are enabled by default, so it will be slower than vo_gl. However, it can be tuned to behave almost as vo_gl.
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)
libvo: add vo_gl3 This new vo is heavily based on vo_gl.c. It provides better scale filters, dithering, and optional color management with LittleCMS2. It requires OpenGL 3. Many features are enabled by default, so it will be slower than vo_gl. However, it can be tuned to behave almost as vo_gl.
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);
libvo: add vo_gl3 This new vo is heavily based on vo_gl.c. It provides better scale filters, dithering, and optional color management with LittleCMS2. It requires OpenGL 3. Many features are enabled by default, so it will be slower than vo_gl. However, it can be tuned to behave almost as vo_gl.
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},
filter_kernels: rename bilinear_slow to triangle This is essentially what it is, and it's a useful for windowing or downscaling. For upscaling we already have bilinear, no need to cause extra confusion between biliner and bilinear_slow. Also made it a bit more well-behaved.
2015-02-24 02:13:37 +00:00
{"triangle", 1, triangle},
filter_kernels: add bartlett, blackman and welch windows
2015-03-27 05:36:27 +00:00
{"bartlett", 1, triangle},
libvo: add vo_gl3 This new vo is heavily based on vo_gl.c. It provides better scale filters, dithering, and optional color management with LittleCMS2. It requires OpenGL 3. Many features are enabled by default, so it will be slower than vo_gl. However, it can be tuned to behave almost as vo_gl.
2012-03-30 23:13:38 +00:00
{"hanning", 1, hanning},
filter_kernels: add ability to taper kernels/windows This allows us to define the tukey window (and other tapered windows). Also add a missing option definition for `wblur` while we're at it, to make testing out window-related stuff easier.
2016-10-26 14:32:57 +00:00
{"tukey", 1, hanning, .taper = 0.5},
libvo: add vo_gl3 This new vo is heavily based on vo_gl.c. It provides better scale filters, dithering, and optional color management with LittleCMS2. It requires OpenGL 3. Many features are enabled by default, so it will be slower than vo_gl. However, it can be tuned to behave almost as vo_gl.
2012-03-30 23:13:38 +00:00
{"hamming", 1, hamming},
{"quadric", 1.5, quadric},
filter_kernels: add bartlett, blackman and welch windows
2015-03-27 05:36:27 +00:00
{"welch", 1, welch},
filter_kernels: redefine redundant filters mitchell, hermite and catmull_rom are all B/C splines and can share the code which was already written for mitchell. This just redefines them in terms of that.
2015-02-24 00:32:45 +00:00
{"kaiser", 1, kaiser, .params = {6.33, NAN} },
filter_kernels: add bartlett, blackman and welch windows
2015-03-27 05:36:27 +00:00
{"blackman", 1, blackman, .params = {0.16, NAN} },
filter_kernels: improve the gaussian function Commit 3909e4cd ended up losing the ability to tune the gaussian window, which this commit trivially reintroduces. The constant scaling factor (present in the code copied from glumpy) also goes against filter_kernels.c conventions, which is that f(0.0) = 1 (and the invoking code takes care of normalization), and has been removed. The values of this new gaussian function corresponds to different functions when compared against the old version. To translate the old values p1 to the new values p2 requires solving 2^(e/p1) = e^(2/p2) or p2 = p1 * 2/(e * ln(2)) ≈ p1 * 1.0615 In other words, to get the old default in the new function requires setting scale-param1 to 1.0615. (The new function is *slightly* sharper by default) (Though most users should probably not notice the change)
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"},
filter_kernels: add ewa_lanczossharp alias This is essentially a preconfigured version of ewa_lanczos, with the "best" parameters for general purpose usage.
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
vo_opengl: make jinc presets resizable No real reason this is disabled with the new configuration API.
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.
vo_opengl: make jinc presets resizable No real reason this is disabled with the new configuration API.
2015-03-30 04:38:49 +00:00
{{"ewa_lanczossoft", 3.2383154841662362, jinc, .blur = 1.015,
.resizable = true}, .polar = true, .window = "jinc"},
filter_kernels: add haasnsoft This is a peculiar filter I stumbled upon while playing around with windows, it removes aliasing almost completely while not ringing at all. The downside is that it's quite blurry, but at high resolutions it's not so noticeable.
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
vo_opengl: make jinc presets resizable No real reason this is disabled with the new configuration API.
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} }},
filter_kernels: use more precise parameters for robidoux filters See #2637.
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},
Various spelling fixes Signed-off-by: wm4 <wm4@nowhere>
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}}
libvo: add vo_gl3 This new vo is heavily based on vo_gl.c. It provides better scale filters, dithering, and optional color management with LittleCMS2. It requires OpenGL 3. Many features are enabled by default, so it will be slower than vo_gl. However, it can be tuned to behave almost as vo_gl.
2012-03-30 23:13:38 +00:00
};