Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > Avisynth Development

Reply
 
Thread Tools Search this Thread Display Modes
Old 19th June 2007, 16:42   #1  |  Link
tsp
Registered User
 
tsp's Avatar
 
Join Date: Aug 2004
Location: Denmark
Posts: 807
extending IScriptEnvironment->AddFunction function in avisynth 2.6

I think it might be a good idea to extend the parameter string in env->AddFunction to include a valid range for each type to support program like AvsP. Adding a optional valid range inside curly brackets like this
env->AddFunction( "Blur", "cf[]{[-1.0 - 1.5849625]}f[mmx]b", Create_Blur,0);
to indicate the valid range for the float is from -1.0 to 1.5849625
ranges could be specified by using [] as a closed interval and ][ as an open interval. More than one range could be joined by using +.

Any thought about this? Of course some range are defined from the input clip like crop depends on the size of the input clip. It would be more difficult to include this( maybe using something like args[0].width ?)
__________________
Get my avisynth filters @ http://www.avisynth.org/tsp/
tsp is offline   Reply With Quote
Old 19th June 2007, 17:59   #2  |  Link
gzarkadas
Registered User
 
gzarkadas's Avatar
 
Join Date: Sep 2005
Location: 100011110010001000001 10000011111111000001
Posts: 221
It would be better if any range information is positioned at the end of the parameter string, say following a "!" character. This would allow to store it in a separate LocalFunction field and make no changes to the TypeMatch code (which is called on each function name lookup).

Thus, we get added functionality for only those that need it without impact on lookup execution speed. We only pay a small one -time fee during function registration.
__________________
AVSLib, a free extension library for Avisynth. Current version: 1.1.0 (beta), 14/05/2007.
[ Home page | Download page ]
gzarkadas is offline   Reply With Quote
Old 19th June 2007, 19:20   #3  |  Link
tsp
Registered User
 
tsp's Avatar
 
Join Date: Aug 2004
Location: Denmark
Posts: 807
you could extract the range information before storing the param in FunctionTable.AddFunction. Anyway the lockup only occur during filter graph construction(unless conditional functions are used).
I think it is easier to manage when the range comes with the param type at least for the functions with lots of parameters (like fft3dfilter).
__________________
Get my avisynth filters @ http://www.avisynth.org/tsp/
tsp is offline   Reply With Quote
Old 19th June 2007, 21:42   #4  |  Link
Fizick
AviSynth plugger
 
Fizick's Avatar
 
Join Date: Nov 2003
Location: Russia
Posts: 2,183
IMO the range is not important.
for example for ftt3dfilter we probably may use sigma=1000 or more. How useful is it?
And good filter usually can say about parameters out of range.

But default values are important instead IMO. It is useful to know them to adjust.
__________________
My Avisynth plugins are now at http://avisynth.org.ru and mirror at http://avisynth.nl/users/fizick
I usually do not provide a technical support in private messages.
Fizick is offline   Reply With Quote
Old 19th June 2007, 23:16   #5  |  Link
gzarkadas
Registered User
 
gzarkadas's Avatar
 
Join Date: Sep 2005
Location: 100011110010001000001 10000011111111000001
Posts: 221
Quote:
Originally Posted by tsp View Post
you could extract the range information before storing the param in FunctionTable.AddFunction. Anyway the lockup only occur during filter graph construction(unless conditional functions are used).
I think it is easier to manage when the range comes with the param type at least for the functions with lots of parameters (like fft3dfilter).
Alternatives are always possible; the key-point of my post is that their computational overhead should be as low as possible. The lookup time is important when executing large scripts (script functions are also been looked-up); also, even small delays inside runtime filters translate to a considerable delay for processing an entire clip.

The virtue of my proposal is that you don't need to make the standard executing code more complex (apart from scanning for the ! at AddFunction, assigning the location to a pointer and executing an additional strdup). The rest of the complexity can be placed in a separate routine that will be used only by the software that needs this information; users that do not use such software will not need to pay for that.

The management is also easy, using string concatenation; cf. the following two examples, where I propose a format for the string inside [], which can handle nicely multiple ranges (parentheses denote optional components):

(name|)default value|range_low,range_high(|range_low,range_high(|range_low,range_high(...))

first example for short param_types:

Code:
env->AddFunction( "Blur", 
    "cf[]f[mmx]b" "!" "cf[1.0|-1.0,1.5849625]f[mmx]b", 
    Create_Blur,0);
or, for longer param_types:

Code:
env->AddFunction( "Blur", 
    "cf[]f[mmx]b" "!" 
    "cf[1.0|-1.0,1.5849625]f[mmx]b", 
    Create_Blur,0);
BTW, I do agree with the extension; that's why I take the time to discuss about it .
__________________
AVSLib, a free extension library for Avisynth. Current version: 1.1.0 (beta), 14/05/2007.
[ Home page | Download page ]
gzarkadas is offline   Reply With Quote
Old 20th June 2007, 02:13   #6  |  Link
IanB
Avisynth Developer
 
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,167
"cf{-1.0..1.5849625}[]f{-1.0..1.5849625}[mmx]b" might be a more managable syntax, i.e add the {...} after an "f" or an "i", no extra []'s to confuse the poor parser authors.

Example:-
"ci{0,1,2,4,8,16}[plugh]f{-20.5..-10.5,10.5..20.5}"
mandatory 1st arg, a clip.
mandatory 2nd arg, an int with 6 legal values.
optional 3rd arg, name "plugh", a float with 2 ranges.

Also how would you handle ".", "+" and "*"?

Remember the internal functions are not AddFunction'd the compiler builds builtin_functions[] directly, so this will need to parse at script load time.

I don't think range validating arguments is going to break the CPU, lots of other things are already many times slower than this.
IanB is offline   Reply With Quote
Old 20th June 2007, 08:41   #7  |  Link
Leak
ffdshow/AviSynth wrangler
 
Leak's Avatar
 
Join Date: Feb 2003
Location: Austria
Posts: 2,441
Quote:
Originally Posted by IanB View Post
"cf{-1.0..1.5849625}[]f{-1.0..1.5849625}[mmx]b" might be a more managable syntax, i.e add the {...} after an "f" or an "i", no extra []'s to confuse the poor parser authors.
How about throwing a default value for each parameter into the mix so a GUI can start off it's sliders or whatever controls at sensible values? (not to mention that you then won't have to consult the docs to find out any default values)

Of course, all of the above will only work for plugins in DLL form; something similar would also be needed for AVSI script functions like LimitedSharpen et al as far as GUIs are concerned...
__________________
now playing: [artist] - [track] ([album])
Leak is offline   Reply With Quote
Old 20th June 2007, 09:40   #8  |  Link
IanB
Avisynth Developer
 
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,167
Default values handling would be a bit further out of left field.

Default value processing is currently done in the filter creator from ...AsFloat(default); like statements. Moving default value processing up into the parser would be a significant cultural change, but could have benefits.

Supporting these concept for .AVSI function declarations would need a change to the function syntax.

Perhaps the 3.0 people have some thoughts, especially as they are working up a completely new syntax.
IanB is offline   Reply With Quote
Old 20th June 2007, 12:14   #9  |  Link
Bidoche
Avisynth 3.0 Developer
 
Join Date: Jan 2002
Location: France
Posts: 639
That's how it works in 3.0.
The parser resolves the defaults himself and always calls functions with all the args.

I think it's cleaner that way, defaults really belong to Filters (Script functions) and not to Filters (Clip subclasses).
Bidoche is offline   Reply With Quote
Old 20th June 2007, 14:42   #10  |  Link
IanB
Avisynth Developer
 
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,167
So what does your proposed script function definition syntax look like?
IanB is offline   Reply With Quote
Old 21st June 2007, 09:14   #11  |  Link
Bidoche
Avisynth 3.0 Developer
 
Join Date: Jan 2002
Location: France
Posts: 639
Pretty much the same than the old one, but adding the return type of the function.
Code:
function clip Foo(Clip c, int i = 0)
Eventually I may support expressions in defaults too, as in
Code:
function clip Bar(clip c, int i, int j = i + 1)
Bidoche is offline   Reply With Quote
Old 23rd June 2007, 07:34   #12  |  Link
CAFxX
Stray Developer
 
CAFxX's Avatar
 
Join Date: Mar 2003
Location: Italy
Posts: 82
What about passing a pointer to a parameter validation function?
For example, to allow more complex rules like (assume param0 is a clip, and the others are floats)
Code:
switch (param0.colorSpace) {
  case CS_YUY2:
    if (width % 4)
      throw avisynthValidationError("with YUY2, width should be mod 4");
    break;
  case CS_YV12:
    if (width % 8)
      throw avisynthValidationError("with YV12, width should be mod 8");
    break;
  default:
    throw avisynthValidationError("input colorspace should be YUV");
}
if (param1 > 0) {
  if (param2 > param1) {
    throw avisynthValidationError("param2 should not be greater than param1");
  }
} else {
  if (param2 < 0 || param2 > 1) {
    throw avisynthValidationError("param2 should be between 0 and 1");
  }
}
and so on.

Eventually, avisynthValidationError could be used to carry some kind of machine/GUI-readable information... C++ (via boost, maybe?) should allow something like
Code:
throw avisynthValidationError< paramBetween<0, 1, "param2"> >("param2 should be between 0 and 1");
or something similar, so that e.g. GUIs have a clue of what parameter(s) are wrong.
__________________
CAFxXcrossway, a collection of my projects
CAFxX@strayorange, my blog

Last edited by CAFxX; 23rd June 2007 at 07:42.
CAFxX is offline   Reply With Quote
Old 23rd June 2007, 22:00   #13  |  Link
tsp
Registered User
 
tsp's Avatar
 
Join Date: Aug 2004
Location: Denmark
Posts: 807
CAFxX: that doesn't solve the problem of providing the range of the parameters to a GUI. Also it should support gui's written in other languages than c++ as it does now by saving the filter parameter string in an script environment variable.
__________________
Get my avisynth filters @ http://www.avisynth.org/tsp/
tsp is offline   Reply With Quote
Old 24th June 2007, 08:52   #14  |  Link
CAFxX
Stray Developer
 
CAFxX's Avatar
 
Join Date: Mar 2003
Location: Italy
Posts: 82
The first issue can be overcome somehow, but I have to admit that the second is rather difficult. My fault: everything I coded for avisynth in the past has always been written in C++.

Nevertheless, the actual proposed solution can't handle complex validation rules (although it's way easier to implement). Maybe someone else will be able to come up with something better...
__________________
CAFxXcrossway, a collection of my projects
CAFxX@strayorange, my blog
CAFxX is offline   Reply With Quote
Old 24th June 2007, 22:23   #15  |  Link
stickboy
AviSynth Enthusiast
 
Join Date: Jul 2002
Location: California, U.S.
Posts: 1,267
What's the real need for this? Why complicate the code and that part of the grammar for little gain?

I think functions should just assert that their inputs are in range themselves. Then their validation rules can be however complex they need them to be, and the functions can provide more specific error messages.
stickboy is offline   Reply With Quote
Old 24th June 2007, 22:45   #16  |  Link
CAFxX
Stray Developer
 
CAFxX's Avatar
 
Join Date: Mar 2003
Location: Italy
Posts: 82
Quote:
Originally Posted by stickboy View Post
What's the real need for this? Why complicate the code and that part of the grammar for little gain?

I think functions should just assert that their inputs are in range themselves. Then their validation rules can be however complex they need them to be, and the functions can provide more specific error messages.
IIRC all of this is being done to let GUIs do their job better. I was just thinking that, since the parameter validation has to be done, and therefore its code has to be written anyway, it may be a Good Thing™ to make GUIs aware of those rules (simply move the parameter validation from the filter constructor to a separate function and then call it).
Mind: I'm not saying that my proposal is the way to go, but simply that it may be a good idea to carefully think about it in the planning stage (to avoid whining GUI authors afterwards).
__________________
CAFxXcrossway, a collection of my projects
CAFxX@strayorange, my blog

Last edited by CAFxX; 24th June 2007 at 22:47.
CAFxX is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 21:14.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.