summaryrefslogtreecommitdiffstats
path: root/video/out/filter_kernels.c
Commit message (Collapse)AuthorAgeFilesLines
* vo_opengl: refactor scaler LUT weight packing/loadingNiklas Haas2017-09-041-3/+6
| | | | | | | | 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.
* filter_kernels: correct spline64 kernelJames Ross-Gowan2017-09-031-4/+4
| | | | | | 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
* vo_opengl: generalize --scale-clamp etc.Niklas Haas2017-07-121-2/+2
| | | | | This can help fight ringing without completely killing it, thus providing a middle-ground between ringing and aliasing.
* filter_kernels: add radius cutoff functionalityNiklas Haas2017-07-031-0/+4
| | | | | | | | 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)
* filter_kernels: Keep f.radius in terms of dest/filter coords.Nicholas J. Kain2017-03-061-9/+11
| | | | | | | | | | | | | 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.
* filter_kernels: Apply blur/taper before culling radius.Nicholas J. Kain2017-03-061-3/+3
| | | | | | | | | | | | | 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.
* filter_kernels: add ability to taper kernels/windowsNiklas Haas2016-11-011-19/+30
| | | | | | | 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.
* filter_kernels: improve the gaussian functionNiklas Haas2016-01-071-2/+2
| | | | | | | | | | | | | | | | | | | | | 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)
* filter_kernels: relicense under BSDwm42016-01-071-11/+5
| | | | | | | | | | | 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.
* filter_kernels: replace AGG-based codewm42016-01-061-71/+69
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* filter_kernels: use more precise parameters for robidoux filterswm42015-12-261-4/+10
| | | | See #2637.
* filter_kernels: add warnings for potential LUT sampling errorBin Jin2015-12-071-0/+6
|
* filter_kernels: remove redundant corner case checkBin Jin2015-12-041-1/+0
| | | | Actually, the original code would bypass some code path below.
* vo_opengl: add tscale-clamp optionNiklas Haas2015-08-201-1/+2
| | | | | | | | | | This significantly reduces the amount of noticeable flashing when using tscale kernels with negative lobes, by cutting them off completely. I'm not sure if this has any negative effects. It needs a bit of subjective testing over a period of time, so I just made it an option. Fixes #2155.
* Various spelling fixesMarcin Kurczewski2015-06-181-1/+1
| | | | Signed-off-by: wm4 <wm4@nowhere>
* filter_kernels: distinguish between regular/EWA robidouxNiklas Haas2015-06-051-2/+4
| | | | | This is because it turns out the regular robidoux is pretty useful for tscale etc.
* Update license headersMarcin Kurczewski2015-04-131-15/+14
| | | | Signed-off-by: wm4 <wm4@nowhere>
* vo_opengl: make jinc presets resizableNiklas Haas2015-04-041-6/+6
| | | | No real reason this is disabled with the new configuration API.
* filter_kernels: add haasnsoftNiklas Haas2015-04-041-0/+4
| | | | | | | 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.
* filter_kernels: remove hermite windowNiklas Haas2015-04-041-1/+0
| | | | Will have to find a source before re-adding.
* filter_kernels: add bartlett, blackman and welch windowsNiklas Haas2015-04-041-1/+17
|
* vo_opengl: refactor scaler configurationNiklas Haas2015-04-041-13/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* vo_opengl: separate kernel and windowNiklas Haas2015-04-041-113/+122
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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)
* filter_kernels: add comment to prevent confusionNiklas Haas2015-03-151-0/+2
| | | | There are conflicting definitons of Ginseng.
* filter_kernels: rename bilinear_slow to triangleNiklas Haas2015-02-241-3/+5
| | | | | | | | 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.
* filter_kernels: add robidoux and robidouxsharpNiklas Haas2015-02-241-0/+2
| | | | | | | | These are EWA-based versions of the keys B/C splines, of which mitchell is already a member. They are slightly softer and slightly sharper than mitchell, respectively. Very easy to define in terms of things we already have.
* filter_kernels: redefine redundant filtersNiklas Haas2015-02-241-20/+6
| | | | | | 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.
* filter_kernels: add ewa_lanczossharp aliasNiklas Haas2015-02-241-0/+4
| | | | | This is essentially a preconfigured version of ewa_lanczos, with the "best" parameters for general purpose usage.
* filter_kernels: add blur parameter to jincNiklas Haas2015-02-231-4/+4
| | | | | This affects all filters that use it, eg. ewa_lanczos. Setting it to something like 0.95 can be done to make the filter a bit less blurry.
* filter_kernels: gaussian: redefine the parameterNiklas Haas2015-02-231-6/+2
| | | | | | | | | Previously, this was based on some arbitrary range 1-100, cut off for no particular reason, and also defined in such a way that higher values = *less* smoothness. Since it wasn't multiplied by e in the code, the default had to be 10*e = 28.8539... Now, it's sane: 1.0 = default, higher = blurrier.
* filter_kernels: remove second parameter from kaiserNiklas Haas2015-02-231-3/+2
| | | | | | | | This filter isn't supposed to have a second parameter in the first place, all literature only uses a single parameter alpha in both places. The second parameter doesn't even do anything other than adding a constant factor, which is normalized by the LUT calculation either way.
* filter_kernels: rename ginseng to ewa_ginsengNiklas Haas2015-02-231-2/+2
| | | | | | This is done mainly for consistency, since all of the EWA filters share similar properties and it's important to distinguish them for documentation purposes.
* filter_kernels: add ewa_hanningNiklas Haas2015-02-231-0/+10
| | | | | This is suggested in a thesis by Andreas Gustafsson, and seems to produce very a bit less ringing than lanczos at high radius.
* filter_kernels: minor code cleanup of jinc stuffNiklas Haas2015-02-231-5/+1
| | | | | | 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.
* vo_opengl: slightly improve ewa_lanczos windowingNiklas Haas2015-02-231-33/+4
| | | | | | | | | | | The original filter window was design for a radius based on the true zero, but we always cut it off at our selection of radius either way (by necessity, due to the square matrix we sample from). This window is tweaked from the original (true radius) to our actual cut-off radius, and hence improves the result in a few edge cases. The main win is the reduction of code complexity, since we no longer need to know what the true radius actually is.
* vo_opengl: add ginseng upscalerNiklas Haas2015-02-201-0/+11
| | | | | | | | | This is a variation of ewa_lanczos that is sinc-windowed instead of jinc-windowed. Results are pretty similar, but the logic is simpler. This could potentially replace the ugly ewa_lanczos code. It's hard to tell, but from comparing stills I think this one has slightly less ringing than regular ewa_lanczos.
* vo_opengl: simplify radius initializationwm42015-01-261-2/+1
| | | | | | | | | | | | | | | Somehow, the default radius for filters with variable radius was set in mp_init_filter(). gl_video.c used NAN as default value for the radius, which would make the filter use the default radius. Simplify this, and set the default radius directly in the gl_video options. It also makes the options easier to understand, because the default value listed in --vo=opengl:help actually shows the default value. Remove the function can_use_filter_kernel(), because it doesn't set a radius if none is set. The function is worthless anyway (something about making filter_kernels.c reusable to other VOs, and trying to deal with the possibility that it could provide filters not supported by vo_opengl.)
* filter_kernels: get rid of sinc/lanczos aliasesNiklas Haas2015-01-221-12/+0
| | | | Just set the radius with scale-radius if it's really needed
* vo_opengl: clean up ewa_lanczos codeNiklas Haas2015-01-221-6/+5
| | | | | | 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.
* vo_opengl: make the default radius 3.0 and simplify scaler documentationNiklas Haas2015-01-211-1/+1
| | | | | | | This also fixes the maximum range to 16.0, which was previously set to 32.0 and incorrectly documented as 8.0. 16 taps should be more than anybody will ever need, but it's the highest radius that's supported by all affected filters.
* vo_opengl: remove 1D texture usagewm42015-01-181-16/+15
| | | | | | | 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.
* vo_opengl: add ewa_lanczos upscaler (aka jinc)Niklas Haas2015-01-151-0/+71
| | | | | This is the polar (elliptic weighted average) version of lanczos. This introduces a general new form of polar filters.
* vo_opengl: clamp filters to their sizewm42014-12-061-1/+2
| | | | | | | | | | | This gives better results with fancy-downscaling. The issue here is that fancy-downscalign "extends" the filter radius by some amount, which requires using a larger filter size and shader. Then most of the filter is "unused", but some filters still return non-0 coefficients, which create heavy artifacts. Just clamp them off. I'm not sure if this is the right solution, but at least it's better than before.
* vo_opengl: add parameter to gaussian filterBin Jin2014-08-261-2/+7
| | | | | | | | | | Add a new parameter 'p' to gaussian filter. The new formula used a different base taken from fmtconv plugin, so that the new parameter is exactly same as the one used in Avisynth and Vapoursynth. The new default value is 2 / log(2) * 10, with the default value it conforms to the original kernel taken from vector-agg.
* vo_opengl: add radius options for filtersBin Jin2014-08-261-0/+5
| | | | | | | Add two new options, make it possible for user to set the radius for some of the filters with no fixed radius. Also add three new filters with the new radius parameter supported.
* vo_opengl: add spline64 filter kernelBin Jin2014-08-261-0/+19
| | | | | | | | 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.
* filter_kernels: fix nearest scalerwm42014-06-041-1/+1
| | | | | | | | | | The previous commit assumed the filter would be 1x1 (then constant weight is correct) - but our code in fact uses at least a 2x2 filter. A 1x1 filter would generally be useless, except for nearest scaling - so it didn't exist. Insteasd of adding such a 1x1 filter, just turn the nearest weight function into a scare function, which should take care of the issue.
* filter_kernels: add nearest neighbour scalinglucy2014-06-031-0/+6
| | | | | | 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>.
* Rename directories, move files (step 1 of 2) (does not compile)wm42012-11-121-0/+279
Tis drops the silly lib prefixes, and attempts to organize the tree in a more logical way. Make the top-level directory less cluttered as well. Renames the following directories: libaf -> audio/filter libao2 -> audio/out libvo -> video/out libmpdemux -> demux Split libmpcodecs: vf* -> video/filter vd*, dec_video.* -> video/decode mp_image*, img_format*, ... -> video/ ad*, dec_audio.* -> audio/decode libaf/format.* is moved to audio/ - this is similar to how mp_image.* is located in video/. Move most top-level .c/.h files to core. (talloc.c/.h is left on top- level, because it's external.) Park some of the more annoying files in compat/. Some of these are relicts from the time mplayer used ffmpeg internals. sub/ is not split, because it's too much of a mess (subtitle code is mixed with OSD display and rendering). Maybe the organization of core is not ideal: it mixes playback core (like mplayer.c) and utility helpers (like bstr.c/h). Should the need arise, the playback core will be moved somewhere else, while core contains all helper and common code.
generated by cgit v1.2.3 (git 2.25.1) at 2024-04-27 11:33:00 +0000