@FranceBB, update on 420->native 444

[feisty2]

Following https://forum.doom9.org/showthread.php?p=1917562#post1917562, I will probably release a new version of chroma reconstructor soon. it is still based on a naïve kernel predicting network but produces better results than previous versions. I did some tests with the prototype and the quality of the results seems to be on par with a small neural network, and therefore I decide to release it.

you should now start learning vaporsynth if you wanna toy with the new chroma reconstructor, I no longer develop filters/scripts for avisynth.

a glimpse of the power of the prototype:

420 chroma (with severe aliasing due to field-based downsampling from 422)
https://i.imgur.com/PJBVIrM.png

420 chroma upsampled
https://i.imgur.com/mA7EYh5.png

444 chroma recostructed by the prototype
https://i.imgur.com/9vMC4Bf.png

[ChaosKing]

Looks nice, but how slow will it be? :D

[feisty2]

You know me too well :p

[FranceBB]

I will probably release a new version of chroma reconstructor soon. it is still based on a naïve kernel predicting network but produces better results than previous versions. I did some tests with the prototype and the quality of the results seems to be on par with a small neural network, and therefore I decide to release it.

That's an amazing news. :)



you should now start learning vaporsynth if you wanna toy with the new chroma reconstructor, I no longer develop filters/scripts for avisynth.

Hell no. It's not because I don't wanna learn Python or anything, but because I've been using Avisynth ever since June 2006, I have several filters/plugins, template scripts, working bats and entire automatized production workflows in use ever since January 2016 that are ENTIRELY based on Avisynth (well actually Avisynth+ ever since 2017). There's no way I'm gonna have something hybrid in my workflows... (I'm talking about the FFASTrans ones).
Anyway, why did you decide to stop developing for Avisynth? The "new" Avisynth+ allows you to do pretty much everything you can do in VapourSynth and it's way better than the old legacy Avisynth in which you had to use either 16bit stacked or 16bit interleaved for instance. Besides, many developers make filters that can run on both platforms, so I think you should support both if it's not too complicated from a coding point of view. I mean, is the AVS+ SDK so terribly bad to use when coding compared to the VapourSynth SDK?



a glimpse of the power of the prototype:

420 chroma (with severe aliasing due to field-based downsampling from 422)
https://i.imgur.com/PJBVIrM.png

420 chroma upsampled
https://i.imgur.com/mA7EYh5.png

444 chroma recostructed by the prototype
https://i.imgur.com/9vMC4Bf.png

Despite the small neural network, that looks absolutely promising.

Looks nice, but how slow will it be? :D

lol
Considering that he may not develop it for Avisynth and that I might have to test it using VapourSource, it's gonna be slow as hell xD
(one reason more to hope that he changes his mind and starts developing for Avisynth too).

[Cary Knoop]

I will probably release a new version of chroma reconstructor soon. it is still based on a naïve kernel predicting network but produces better results than previous versions. I did some tests with the prototype and the quality of the results seems to be on par with a small neural network, and therefore I decide to release it.

Excellent!
I can't wait!

[feisty2]

Anyway, why did you decide to stop developing for Avisynth?



me as a user (the avisynth language):
the avisynth language is hard to work with for complex scripts. it lacks many basic functionalities that a general purpose programming language should have. I remember earlier versions of the avisynth language didn't even have "if statements" and "loops", maybe these features are now available in the new avisynth+? I'm not sure. I bet a general purpose container (something like a python list) is still not possible in the current avisynth language, let alone more advanced features.

me as a developer (the avisynth API):
I strongly dislike the Java style OOP (interface/base class + inheritance + type erasure) and the avisynth API is exactly like that. my programming mindset is highly dynamic, when I write a piece of code, I do not think about the type of each entity in that code snippet and all I care about is that if the code correctly expresses the logic in my head. I cannot code in a language that requires me to declare the type for everything, to me the type is completely unknown (ignored) until the program is complete. Thus, I can only code duck typed programs. this "pseudo dynamic typing" coding style requires very recent versions of the C++ language (C++20 at least) [1]. and it is not compatible with avisynth. iirc, avisynth relies on certain versions of MSVC and even the latest version of MSVC hasn't yet supported all the C++20 core language features that I use all the time.
besides, I'd rather just have a clean and simple C API like vaporsynth's API and code my own C++20 wrapper on top of that (https://forum.doom9.org/showthread.php?t=181027).
I will probably take a look at avisynth again when:
a) avisynth becomes portable like vaporsynth and no longer relies on a specific compiler and operating system
b) avisynth provides a clean C API with 0% of that Java style OOP bullshit.



footnote:
[1] well theoretically speaking the "pseudo dynamic typing" style is also possible in C++98 but the syntax would be highly esoteric and A LOT of black magic stuff like SFINAE would be involved, which is a total disaster, this was better known as template metaprogramming in C++98.

[FranceBB]

I remember earlier versions of the avisynth language didn't even have "if statements" and "loops", maybe these features are now available in the new avisynth+?

Yes, if statements are now a thing in Avisynth. :)



when I write a piece of code, I do not think about the type of each entity in that code snippet and all I care about is that if the code correctly expresses the logic in my head. I cannot code in a language that requires me to declare the type for everything, to me the type is completely unknown (ignored) until the program is complete.

Well, this was true not only for C++ but also for older version of C#, I think before .NET 4 was introduced with "var". So just to get this straight: you don't declare anything and treat everything as var, thus letting the compiler take care of it depending on what you assigned? Like if you assigned an integer, the var becomes an integer and so on? Isn't it confusing when you have to "interact" with different variables since you don't know what they are and implicit conversion may occur? I mean, you may know, but what if someone else is reading it?

(side note: It's just a genuine question, I'm in no position whatsoever to criticize or anything 'cause the few programs I wrote in the past are an undocumented mess)




I will probably take a look at avisynth again when avisynth becomes portable like vaporsynth and no longer relies on a specific compiler and operating system


I think we're making a step in the right direction with the merging of AVXSynth into Avisynth+ as now it can be compiled to also run on Linux and Mac OSX. So... it's no longer OS specific, however I don't know if the MSVC / GCC thing on Windows will ever be solved. (I'm talking about the fact that if you compile it with GCC you can't use MSVC plugins and vice versa).

[feisty2]

Well, this was true not only for C++ but also for older version of C#, I think before .NET 4 was introduced with "var". So just to get this straight: you don't declare anything and treat everything as var, thus letting the compiler take care of it depending on what you assigned? Like if you assigned an integer, the var becomes an integer and so on? Isn't it confusing when you have to "interact" with different variables since you don't know what they are and implicit conversion may occur? I mean, you may know, but what if someone else is reading it?

(side note: It's just a genuine question, I'm in no position whatsoever to criticize or anything 'cause the few programs I wrote in the past are an undocumented mess)



when you deal with an entity (variable, function, etc.) it doesnt matter what it is, it matters what it can do.

for instance, int, float and string all share the same behavior operator+ but you cannot erase them to a common base type[1]. if you have to know what something is, you're thinking in nouns while I think in verbs. when you think in verbs, you don't think about what something is, you expect what something is capable of, for instance, when I write something like this

auto x = SomeFunction(...);
x.f();

I expect x can do f(), if it turns out x cannot do f(), the compiler would give me an error. it shouldn't be my burden to figure out what x is since all I care about is that x can do f(), the concrete type of x is not part of the logic in my head and therefore I simply don't know the type of x. more about verb based programming (https://en.wikipedia.org/wiki/Duck_typing)

regarding the readability and maintainability stuff, it shouldn't be a problem as long as the entities are properly named, I'll give you this example (https://github.com/IFeelBloated/vsFilterScript/blob/master/Examples/GaussBlur.hxx) which I have posted many times before, there's zero type declaration and do you think the code is hard to understand?









footnote:
[1] In C++20, int, float and string could be unified by an "Addable" concept

template<typename AddableType>
concept Addable = requires(AddableType x) { x + x; };

auto f(Addable auto x) {
return x + x;
}

auto x = f(1); // ok, x =2
auto y = f(3.14); // ok, y = 6.28
auto z = f("aa"s); // ok, z = "aaaa"
auto w = f(std::array{ 1, 2, 3 }); // error, std::array<T> does not have operator+ and thus fails to satisfy Addable

however concept is based on a completely different mechanism than subtyping (interface/base class + inheritance + type erasure) and is a very new feature that has just been introduced in C++20, let's pretend that it does not exist ;)

[ChaosKing]

Well, this was true not only for C++ but also for older version of C#, I think before .NET 4 was introduced with "var". So just to get this straight: you don't declare anything and treat everything as var, thus letting the compiler take care of it depending on what you assigned? Like if you assigned an integer, the var becomes an integer and so on? Isn't it confusing when you have to "interact" with different variables since you don't know what they are and implicit conversion may occur? I mean, you may know, but what if someone else is reading it?



auto in C++ is much more powerful than a "simple" var in c#.
https://stackoverflow.com/a/40781969/8444552
https://softwareengineering.stackexchange.com/a/180616

[FranceBB]

auto in C++ is much more powerful than a "simple" var in c#.
https://stackoverflow.com/a/40781969/8444552
https://softwareengineering.stackexchange.com/a/180616

I see... I didn't know that.

you're thinking in nouns while I think in verbs.

I think that sums up pretty much everything... :P

I'll give you this example which I have posted many times before, there's zero type declaration and do you think the code is hard to understand?

Well, I get what it does, but it definitely feels... kinda... weird to see all those "auto".

[feisty2]

auto in C++ is much more powerful than a "simple" var in c#.
https://stackoverflow.com/a/40781969/8444552
https://softwareengineering.stackexchange.com/a/180616

it's not just that, these answers are now outdated, basically auto can replace any type declaration in C++20.

it could deduce the type of local variables

auto main()->int {
auto x = ... // x is a local variable
}


it could deduce the type of global/static/thread_local variables

auto x = ... // x is a global variable

struct Test {
static inline auto y = ... // y is a static member variable
};

auto main()->int {
static auto z = ... // z is a static variable
thread_local auto w = ... // w is a thread_local variable
}


it also makes the template syntax a lot "sweeter"

auto f(auto x) {
return x + x;
}

auto g(SomeConcept auto x) {
return x.DoSomething(...);
}

// above is equivalent to

template<typename T1, typename T2>
T2 f(T1 x) {
return x + x;
}

template<SomeConcept T1, typename T2>
T2 g(T1 x) {
return x.DoSomething(...);
}


it could even deduce the type of non-type template parameters

template<auto N>
consteval auto fac() {
if constexpr (N == 0)
return 1;
else
return N * fac<N - 1>();
}

constexpr auto x = fac<4>(); // N is deduced as int


finally, "auto" is required to capture lambda expressions (the type of lambdas is only known to the compiler) and the results of functions that return multiple values.

auto f() {
return std::tuple{ 123, 3.14, "aaa"s };
}

auto Print = [](auto&& x) { std::cout << x << std::endl; };
auto [x, y, z] = f(); // x = 123, y = 3.14, z = "aaa"


there are probably other cases of "auto" which I haven't covered, but you get the idea :)

[wonkey_monkey]

I don't hold with this new-fangled template stuff but I like auto because it means I don't have to specify the type of a vector iterator.

[feisty2]

Well, I get what it does, but it definitely feels... kinda... weird to see all those "auto".

but verb based programming is much more powerful and expressive and flexible once you get the hang of it, don't you agree? your code becomes automatically polymorphic, you no longer waste your time thinking about and typing out long cumbersome types, and the code is just as readable with proper naming.

[StainlessS]

Your chroma reconstructor whotsit looks kinda nifty feisty, nice. :)