View Full Version : Core Algorithms needed
jmac698
19th March 2011, 22:23
After reading dozens of development threads, I came to the conclusion that there's a few basic needs for a lot of different plugins. You definitely need a core basis of higher bit depth, high quality interpolation, dithering, and gamma processing. If we had these as a core, a lot of plugins would be high quality and also have bonus features.
For example colorspace conversion, rotation, resizers, and some others need this core.
Most authors just use bilinear interpolation because it's simple, but ideally every plugiin could reference some core or external method.
Not that I'm gonna submit a patch anytime soon, but wanted to note it and put the idea out.
pbristow
21st March 2011, 17:44
I agree, this would be a good way to save folks re-inventing the wheel, and might speed up/simplify the development of high-quality plug-ins.
OTOH, there is also the push for AviSynth itself to have more colourspaces/bit depths to work in as part of the scripting environment. If it had explicitly non-gamma versions of RGB48, YUY32 and YV24 (not sure those are all correct terms, but basically, colourspaces with 16-bit depth), with the application/removal of gamma being handled by the ConvertTo... filters, then it would be easy to create gamma-aware processing chains without the individual filters having to convert gamma back-and-forth. Filter writers would then just need ensure that their filters handle the 16-bit-deep versions of whatever colourspaces they accept, and that they do their internal arithmetic with at least 16 bit precision (at least when working on those particular colourspaces - I'm aware that some things are done using 8-bit or even 7-bit operations because they're faster / directly implemented in hardware, through MMX, SSE etc.). That being the case, creating a core set of well-optimised 16 bit operations that act as direct replacements for the commonly used 8-bit SSE operations might be a good place to start.
(All this coming from a guy who hasn't even written his first filter yet, and finds the whole C/C++/x86/x64 landscape utterly bewildering... Come back PASCAL, all is forgiven! Ignore me, I'm just burbling now... [APOLOGETIC SMILE] )
StainlessS
18th April 2011, 02:22
There should also be a core repository of peculiar methods of eg pulldown,
etc, both the script methods of producing such... stuff, and the reverseal
of that, where possible. If this could be achieved it would warrent a sticky.
@Pbristow "Come back PASCAL, all is forgiven",
I'm guessing that basic is not beyond you, C, C++ is just a weeny bit
more, demanding.
pbristow
25th April 2011, 12:35
To avoid the risk of taking this thread *way* off topic...
I'm guessing that basic is not beyond you, C, C++ is just a weeny bit
more, demanding.
... I made a public post about that: http://pbristow.livejournal.com/655191.html :)
(Comments over there, folks, not here!)
TheFluff
25th April 2011, 15:39
There should also be a core repository of peculiar methods of eg pulldown,
etc, both the script methods of producing such... stuff, and the reverseal
of that, where possible. If this could be achieved it would warrent a sticky.
It already exists, it's called the Avisynth documentation and the Avisynth builtin functions.
I'm also wondering why someone who has clearly never done any development of anything Avisynth related is posting a thread about what is needed in Avisynth development.
jmac698
25th April 2011, 20:13
That's just funny. Have you looked under new plugins and utilities? I'd say I'm one of the more prolific developers.
TheFluff
26th April 2011, 01:57
That's just funny. Have you looked under new plugins and utilities? I'd say I'm one of the more prolific developers.
You develop Avisynth scripts, not Avisynth plugins, let alone Avisynth internals. In other words, you use Avisynth, you do not develop things related to it. If you did, you'd know that a plugin can invoke any installed Avisynth filter, obviously including the builtins, and since the builtins already do pretty much all the useful "core algorithm" stuff (colorspace conversion, etc) there's not really any need for what you are proposing.
In case you're talking about more basic stuff like generic interpolation functions or generic matrix maths ops, good implementations of those are most likely already available via Boost and other big, well tested libraries. Boost even has a generic image manipulation library that seems to be able to do quite a bit of odd stuff as long as you stick to its own data formats.
jmac698
26th April 2011, 05:19
higher bit depth, high quality interpolation, dithering, and gamma processing
Only one of those is built in.
pbristow
26th April 2011, 11:11
@TheFluff: It seems you're unaware of the background to this thread - i.e. recent discussions about the advantages of working in linear brightness, which requires higher bit depths than the existing AviSynth core, etc. - and thus have missed the point.
I too have so far only developed scripts, although I've done minor modifications to a couple of plugins to suit my own scripts; but that doesn't mean I can't have an insight into what would be useful in the future core of AviSynth. Sometimes it's useful for people who aren't up to their elbows in the guts of the software to be able to stand back and say, "Hey, do you three guys realise you're all trying to solve basically the same problem? Why not use a common solution?" If it's not a useful comment, people can always ignore us. :)
TheFluff
26th April 2011, 15:59
Only one of those is built in.
Higher bit depths will be supported in Avisynth 2.6 and backporting that support to 2.5 is both nontrivial and unnecessary.
I don't know what you mean by "higher quality interpolation"; certainly Avisynth's image resizers are high enough quality for most needs so I assume that's not it. If you want generic interpolation algorithms there is not exactly a shortage of those out there, just use your favorite search engine.
I'm not sure what exactly you mean by high quality dithering either but again there are several Avisynth filters that do that kinda stuff already.
As for gamma curve manipulation, it can easily be done with levels(). What exactly are you looking for here, really? To me it looks like both you and pbristow are very confused about the entire thing (add and remove gamma? what?) and don't really know what you want, you just like your buzzwords.
pbristow
26th April 2011, 17:20
Higher bit depths will be supported in Avisynth 2.6 and backporting that support to 2.5 is both nontrivial and unnecessary.
No one is suggesting back-porting it to 2.5.
I don't know what you mean by "higher quality interpolation"; ...
I'm not sure what exactly you mean by high quality dithering either ...
Example of both in one thread: http://forum.doom9.org/showthread.php?t=160038
jmac's suggestion is about saving the need for lots of developers to individually workaround bit-depth limitations, as they are currently doing, by providing them with a common core of higher bit-depth functions for use *within* new plug-ins, and a common dithering implementation to allow that quality to be preserved as far as possible when outputting 8-bit formats.
I replied with the point that you yourself are now making, that there are already moves afoot for Avisynth to support higher bit-depth clips in future, which would obviate the need for such workarounds.... Although from what I've seen, the new formats in 2.6 don't go far enough for true linear-brightness work, which needs full 16-bit depth to keep the required precision at low levels.
pbristow
26th April 2011, 21:05
Note also IanB's contributions in this thread: http://forum.doom9.org/showthread.php?p=1383004#post1383004
jmac698
26th April 2011, 22:33
If these were in the core and used by plugins, upgrades to the core would suddenly give new features to the plugins. I'm dreaming of a system where, when a new deinterlacing method comes out, all scripts and plugins previously released would suddenly have much better performance, for example. (I'm just using deint as an example here). The things I mention are standard in many other image processing libraries, in fact it might be useful to build them in somewhere (intel image processing primitives for example).
Plugins to do arbitrary rotation for example, need an interpolator, but aren't using a high quality one. I'd like to see a single call to interpolate but let the user control the parameters beyond the plugin to improve quality, for example.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.