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 27th May 2010, 01:53   #301  |  Link
foxyshadis
ангел смерти
 
foxyshadis's Avatar
 
Join Date: Nov 2004
Location: Lost
Posts: 9,413
Actually, Deblock_QED and some one-off sharpener testing visualization script seem to be the only scripts on the forum using it without expr. As long as Deblock_QED is updated, it shouldn't be a major problem - and the error message should make it clear when it does happen that it's in Deblock_QED.
__________________
There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order.
foxyshadis is offline   Reply With Quote
Old 27th May 2010, 09:21   #302  |  Link
Gavino
Avisynth language lover
 
Join Date: Dec 2007
Location: Spain
Posts: 3,383
Quote:
Originally Posted by foxyshadis View Post
Actually, Deblock_QED and some one-off sharpener testing visualization script seem to be the only scripts on the forum using it without expr.
Good to know, although the forum isn't the exclusive source for scripts. Some people actually write their own.
Gavino is offline   Reply With Quote
Old 30th May 2010, 11:17   #303  |  Link
Manao
Registered User
 
Join Date: Jan 2002
Location: France
Posts: 2,856
New version available, with a new mode added to mt_luts / mt_lutsx. It will allow very flexible convolution with custom kernels.

Gavino : for mt_lutspa, the "evil" is done, I won't change it back. I'll try to keep backward compatibility in mind for later releases, but if it really matter to you, you can also take care of that on your side, by using named parameters (which I always do, thus why I didn't think adding a parameter in the middle of the parameter list would be a problem).
__________________
Manao is offline   Reply With Quote
Old 31st May 2010, 08:44   #304  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 1,751
I'm agree with Gavino, and i'm thinking of people who use scripts made by others, and may don't know how to debug/correct it, or even how to contact the author of the script...
jpsdr is offline   Reply With Quote
Old 31st May 2010, 11:58   #305  |  Link
hydra3333
Registered User
 
Join Date: Oct 2009
Location: crow-land
Posts: 530
yes, please reconsider. just this once, maybe.
hydra3333 is offline   Reply With Quote
Old 31st May 2010, 13:43   #306  |  Link
kemuri-_9
Compiling Encoder
 
kemuri-_9's Avatar
 
Join Date: Jan 2007
Posts: 1,348
I'm in agreement with Manao, he's already made the change and so it is already propagating.
to change it would cause a re-propagation of changes.

besides if people seriously don't know how to fix the script they're using, then they should take that opportunity to actually learn about what they're doing.
__________________
custom x264 builds & patches | F@H | My Specs
kemuri-_9 is offline   Reply With Quote
Old 31st May 2010, 14:24   #307  |  Link
Gavino
Avisynth language lover
 
Join Date: Dec 2007
Location: Spain
Posts: 3,383
Quote:
Originally Posted by kemuri-_9 View Post
besides if people seriously don't know how to fix the script they're using, then they should take that opportunity to actually learn about what they're doing.
The issue is not whether people know how to fix their scripts, it's the basic software engineering principle that a new version of something should not impose unnecessary changes on existing users. IanB is very careful to adhere to this principle for Avisynth itself.

However, the damage is slight in this case and has already been done. It was probably a design 'mistake' in the first place to make 'relative' the first parameter of mt_lutspa, rather than the more frequently used 'expr'. But this is just nit-picking on what is ultimately a great piece of software.
Gavino is offline   Reply With Quote
Old 31st May 2010, 14:52   #308  |  Link
Manao
Registered User
 
Join Date: Jan 2002
Location: France
Posts: 2,856
Not really a mistake. Both "expr" and "relative" have to be provided. You can assume "relative" to have its default value, but it's a bad habit imho in this case.

Also, the logic behind the original positioning was that "expr" and "relative" should be the first two arguments (because they would be those used the most), and that "expr", "yExpr", "uExpr" and "vExpr" should be consecutive arguments (as they were in all the other filters using luts). Once those two predicates were in action, I didn't have a lot of choice in regard to their relative positioning. When I had to add "biased", once again, I decided it should be one of the first three, and that it shouldn't break the "expr" serie.
__________________
Manao is offline   Reply With Quote
Old 31st May 2010, 15:00   #309  |  Link
Guest
Guest
 
Join Date: Jan 2002
Posts: 21,923
People that do not use named parameters deserve what they get, IMHO.
Guest is offline   Reply With Quote
Old 31st May 2010, 15:11   #310  |  Link
hydra3333
Registered User
 
Join Date: Oct 2009
Location: crow-land
Posts: 530
Oh ? They do ?
hydra3333 is offline   Reply With Quote
Old 31st May 2010, 15:13   #311  |  Link
Didée
Registered User
 
Join Date: Apr 2002
Location: Germany
Posts: 5,394
Well, it was me who "too quickly" fiddled that lutspa into that certain deblocking function ... Guilty! Blame me! Guilty!

(Will I be condemned to prison, or is there hope to get away with suspended sentence?)

A corrected script has been posted already ... but as usual, the problem is that once a malformed script has been spread in the wild, you can't make it disappear anymore.
__________________
- We´re at the beginning of the end of mankind´s childhood -

My little flickr gallery. (Yes indeed, I do have hobbies other than digital video!)
Didée is offline   Reply With Quote
Old 31st May 2010, 15:25   #312  |  Link
Bi11
Architect
 
Bi11's Avatar
 
Join Date: May 2010
Posts: 57
My 2 cents is that consistent relative positioning of the parameters is probably more important in this case (especially since mt_LutSpa is but one function in a much larger piece of software), as Manao pointed out.

I think most "ignorant" users (like me) get their scripts from the AviSynth Wiki. Hence the Wiki should be updated with the corrected version of broken scripts.
Edit: I see the AviSynth Wiki has already been updated with the corrected version of Deblock_QED. I would strongly advise those in charge of editing the Wiki to please link back to the source (post) of those scripts (just like a Wikipedia reference) for the benefit of everyone.

Last edited by Bi11; 31st May 2010 at 15:54.
Bi11 is offline   Reply With Quote
Old 31st May 2010, 23:08   #313  |  Link
IanB
Avisynth Developer
 
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,171
Quote:
Originally Posted by Gavino View Post
Manao, the new biased parameter of mt_lutspa has been introduced between the parameters relative and expr.
This causes problems for existing scripts which have called mt_lutspa with positional parameters (eg see here).

Rather than have everyone affected update their scripts/functions, it would be better to make biased the last parameter in the list. It is generally good practice to do this when introducing new options, to preserve backwards compatibility.
Quote:
Originally Posted by Manao View Post
Gavino : for mt_lutspa, the "evil" is done, I won't change it back. I'll try to keep backward compatibility in mind for later releases, but if it really matter to you, you can also take care of that on your side, by using named parameters (which I always do, thus why I didn't think adding a parameter in the middle of the parameter list would be a problem).
Manao,

I must say I am very disappointed with your "evil is done, I won't change it back" attitude. You could have just said oops, my bad, here is a fixed v2.0a44a version and everybody would have been satisfied.

There are places in Avisynth where you do cannot use argument naming, Animate/ApplyRange being one.

You write excellent software, I hope you put away your black hat and start wearing your white hat again, please reconsider.
IanB is offline   Reply With Quote
Old 1st June 2010, 06:39   #314  |  Link
Manao
Registered User
 
Join Date: Jan 2002
Location: France
Posts: 2,856
IanB: I didn't think of animate/applyrange, well spotted. But, luckily for me, since mt_lutspa's arguments are only bools and strings, it doesn't really apply.

As for my "evil" is done attitude (I should have said the genie is out of the box...), I would probably have made the change if the "problem" had been spotted right after 2.0a43, three weeks ago. Instead, something like that happened in the meantime. Basically, making the change now would imho mess things up even more.
__________________
Manao is offline   Reply With Quote
Old 1st June 2010, 08:11   #315  |  Link
Gavino
Avisynth language lover
 
Join Date: Dec 2007
Location: Spain
Posts: 3,383
Quote:
Originally Posted by Manao View Post
IanB: I didn't think of animate/applyrange, well spotted. But, luckily for me, since mt_lutspa's arguments are only bools and strings, it doesn't really apply.
ApplyRange is not limited to numeric parameters, although in truth it's unlikely one would use it with mt_lutspa.

I don't think it's too late to make a change. The Deblock_QED fix uses named parameters, so will not be affected.
Gavino is offline   Reply With Quote
Old 1st June 2010, 09:06   #316  |  Link
jpsdr
Registered User
 
Join Date: Oct 2002
Location: France
Posts: 1,751
Quote:
Originally Posted by kemuri-_9 View Post
besides if people seriously don't know how to fix the script they're using, then they should take that opportunity to actually learn about what they're doing.
I don't agree. Why should the user of something (script or software) has to be able to fix it ?
A lot of people used a lot of video software, filters, plugins, scripts, they know what they are doing in video edition, but they don't have programming knowledge, or high video processing knowledge to do what they wanted. And they don't have to.
jpsdr is offline   Reply With Quote
Old 1st June 2010, 20:04   #317  |  Link
Bi11
Architect
 
Bi11's Avatar
 
Join Date: May 2010
Posts: 57
Quote:
Originally Posted by IanB View Post
You could have just said oops, my bad, here is a fixed v2.0a44a version and everybody would have been satisfied.
But what about the reasoning given for the positioning of the parameter in the first place.

Quote:
Originally Posted by Manao View Post
I would probably have made the change if the "problem" had been spotted right after 2.0a43, three weeks ago.
It may have been spotted right after 2.0a43, but those who spotted it may have been too "dumb" to figure out the exact cause of the problem, or they may not be Doom9 members, or they didn't known how to submit a bug report, or didn't have time, or waited for someone else to post about it, or ...

Quote:
Originally Posted by Manao View Post
Instead, something like that happened in the meantime.
I can always update my post to state that the old script will continue to work with (the fixed) future versions of MaskTools 2.0.

Quote:
Originally Posted by Manao View Post
Basically, making the change now would imho mess things up even more.
If you can live with slight internal inconsistency in parameter positioning then I see no reason not to apply the fix.

Scripts that worked before and after the change will continue to work after the fix. Scripts that didn't work after the change must be corrected, unless the fix is applied in which case they will continue to work as if the change never happened. Only scripts without named parameters that used the "biased" parameter after the change will no longer work after the fix, but those scripts would be an insignificant minority compared to scripts written before the change.

Thus, preserving backward compatibility is a win-win for everybody (except you, maybe ).

Edit:
I just realized that the new "biased" parameter is a hack for the vagueness of "relative". The argument of consistency cannot be applied to hacks! Therefore, it is a software development error on your part, Manao, to break backward compatibility for a hack (esp. since it's usually done the other way around) in an otherwise flawless piece of software.
So that just leaves either keeping the hack but making sure to preserve backward compatibility, or fixing the hack properly (perhaps by changing bool relative to string mode, with values "absolute", "relative inclusive" and "relative exclusive"), but unavoidably breaking backward compatibility.

Last edited by Bi11; 1st June 2010 at 22:41.
Bi11 is offline   Reply With Quote
Old 1st June 2010, 23:01   #318  |  Link
Bi11
Architect
 
Bi11's Avatar
 
Join Date: May 2010
Posts: 57
You can probably get the best of all worlds by declaring the function as:

mt_lutspa : clip clip, bool relative("true"), string expr("x"), string yexpr("x"), string uexpr("x"), string vexpr("x"), string mode("relative exclusive"), bool biased("true")

Of course, you would have to declare "relative" and "biased" as being deprecated in favour of "mode" in the documentation.

Hence, the hack now serves the purpose of preserving backward compatibility, as it should be.
Bi11 is offline   Reply With Quote
Old 13th June 2010, 07:43   #319  |  Link
JEEB
もこたんインしたお!
 
JEEB's Avatar
 
Join Date: Jan 2008
Location: Finland / Japan
Posts: 514
Excuse me as a MaskTools beginner, but I happened to come upon something that begs me to question if this is intended behavior:

Code:
YourSourceFilter()

mask = last.mt_edge("cartoon",4,32,4,32)
mask
The output. What I would expect.

This piece of script I got by combining rather random knowledge out of another script and my own scribbles, and used it here. Now, since the powerful white is there, and most of the other colors are rather slight, the actual script has worked. It's just that the other day I got asked about MaskTools2 usage on IRC, and got asked if random colors etc. were normal to have in the mask itself. So, as I couldn't give a proper answer to that question, here I am.

Tested on revisions 29, 34, 37, 39, 43 and 44 -- the output is quite identical. 32bit Avisynth 2.5.8 stable, no MT used. Source filter and resolution don't seem to matter, I have so far gotten identical results on several types of sources and several resolutions. Of course, if a source will be needed, I will be glad to provide.
__________________
[I'm human, no debug]
JEEB is offline   Reply With Quote
Old 13th June 2010, 08:07   #320  |  Link
foxyshadis
ангел смерти
 
foxyshadis's Avatar
 
Join Date: Nov 2004
Location: Lost
Posts: 9,413
You forgot chroma="process" (or "copy" or -128). You can also follow it up with a .Greyscale() call.

Same thing tripped me and most others up the first time.
__________________
There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order.
foxyshadis 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 13:05.


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