R39 is finally done after far too long. It has the optimizations and bug fixes and nothing really interesting beyond that. Hopefully I’ll have enough time to start experimenting with bigger changes soon…
- Optimized Sobel, Prewitt and Levels
- Added float support to BoxBlur
- Added swapN and dupN operators to Expr
- AVX-512 support (as in proper memory alignment when AVX-512 is preset, no actual optimizations)
- Fixed a pile of value range clamping issues for 9-15 output in internal filters
- Sobel and Prewitt functions had their min and max arguments removed since they’re just a bad idea inherited from MaskTools.
- Reverted the horrible per plane argument system in Levels to the way it previously worked. Fortunately nobody seemed to even notice this change.
- Now uses Nasm instead of Yasm in the build system.
- CropRel is now simply know as Crop since that’s the crop function most people usually want anyway. CropRel is still kept as an alias for compatibility.
Development has continued and I’ve started posting test builds for R39. You can find it in the doom9 thread as usual. It should be RC quality but there are still a few small additional improvements I want to make before it’s released.
This release is mostly kind of a bug fix with minor enhancements as well. Nothing exciting but the restrictions of several filters were re-examined and relaxed a bit to match what the actual code can handle. As a result Transpose doesn’t care about subsampling anymore, horizontal and vertical convolutions have a larger element limit and AverageFrames can average over even more frames. Not very exciting at all for most people.
The other part is the addition of a box blur filter. The main attraction is that it can be used to approximate large radius Gaussian blurs very quickly. Or simply a large area average.
This release dragged on for far too long.
Possibly breaking changes:
- ImageMagick7 is now required for the imwri plugin
- Visual Studio 2017 is now officially required to build on windows
R37 has been released. It’s mostly just a collection of bug fixes. Ironically the Avisynth 2.6 API was the cause of several of them in AVFS. Expect a long rant about this later.
Note: Both the installer and portable archives were updated to fix various compilation issues so if you experience crashes on resizing/missing dll errors you should re-download.
I fixed some bugs. Other people who understand Python improved things a bit. This is yet another maintenance release. See the changelog for the full list of fixes.
I uploaded a new FFMS2 compile using the latest FFmpeg. This fixes many SWScale issues, for example planar RGB can now always be used as output, and also some other decoding issues. Especially VapourSynth users should update.
This is a quick bugfix release. It fixes an incorrect output bug in 3×3 (and smaller) convolutions and several AVFS output issues that were carried over from the original code. You should update.
I actually did test this release. I mean it. Not like the previous one where only the core parts got tested. Anyway, this release fixes all known regressions that appeared in R33 and optimizes several internal functions. It also adds support for handling pre-multiplied alpha in MaskedMerge and a PreMultiply filter to apply it.
VSFS was removed and replaced with AVFS, importing all improvements such as faster mount speed and other fixes. The codebase was also unified for both Avisynth and VapourSynth to make maintaining it less annoying in the future. But wait! There’s more! When using recent Avisynth+ builds it can now output exactly the same high bitdepth formats as VapourSynth! Interestingly this makes AVFS considerably better than the current VFW output of Avisynth+.
Possibly breaking changes:
- Temporalsoften plugin no longer included because it’s horrible, use FrameAverage from miscfilter instead
- AVFS doesn’t have shell integration unlike the older VSFS
Some Avisynth filters are really, really popular and show up many scripts. Some of them like RemoveGrain and TemporalSoften have even been ported because they’re useful and used in so many scripts.
…But what is TemporalSoften really used for?
TemporalSoften is the definition of cargo cult programming, its code and concept gets copied over and over again and nobody knows exactly why. Let’s start with a few facts:
- TemporalSoften is a horribly bad temporal smoother even compared to its competition over 10 years ago
- TemporalSoften has never been used to unironically denoise anything the past 10 years
With these facts in mind you have to wonder why anyone’d ever put it in a script from the past decade. The answer is simple, if you set the denoising thresholds to their max values you get a filter that averages an odd number of frames. If you’re creative you can blend several frames with different weights. That’s actually kinda useful sometimes. So useful someone already wrote an Avisynth plugin for it. It’s a shame that it was fairly quickly forgotten. Unfortunately nobody who ported TemporalSoften to VapourSynth stopped to think about what it was actually used for and instead a very optimized version of TemporalSoften was created. And rewritten. And optimized a bit more. Because why not?
To try to counter this madness I’ve made a collection of small useful and experimental functions available. The first version can be found in this thread. Go try it and stop blending frames with TemporalSoften.
RemoveGrain is kind of an abomination as a filter. Mostly because it has over 20 different modes that effectively are different filters. These are probably just numbered in the order the author came up with them and this can be very confusing. Having that many modes also leads to the big question of what these modes actually do and which ones are actually used. A quick check showed that modes 2, 4, 11, 12, 19 and 20 are the most common (most other modes are useless and/or pointless in case you’re wondering).
Mode 2: 3×3 clipping operation with no nice name
Mode 4: 3×3 median
Mode 11&12: 3×3 convolution using [1 2 1, 2 4 2, 1 2 1]
Mode 19: 3×3 convolution using [1 1 1, 1 0 1, 1 1 1]
Mode 20: 3×3 convolution using [1 1 1, 1 1 1, 1 1 1]
If you’re paying attention you can easily see that all except mode 2 are easily replaceable by easier to read functions that support more input formats. Go do that!