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. |
27th May 2010, 01:53 | #301 | Link |
Angel of Night
Join Date: Nov 2004
Location: Tangled in the silks
Posts: 9,559
|
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.
|
30th May 2010, 11:17 | #303 | Link |
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).
__________________
|
31st May 2010, 13:43 | #306 | Link |
Compiling Encoder
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. |
31st May 2010, 14:24 | #307 | Link | |
Avisynth language lover
Join Date: Dec 2007
Location: Spain
Posts: 3,431
|
Quote:
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. |
|
31st May 2010, 14:52 | #308 | Link |
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.
__________________
|
31st May 2010, 15:13 | #311 | Link |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,391
|
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!) |
31st May 2010, 15:25 | #312 | Link |
Architect
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. |
31st May 2010, 23:08 | #313 | Link | ||
Avisynth Developer
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,167
|
Quote:
Quote:
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. |
||
1st June 2010, 06:39 | #314 | Link |
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.
__________________
|
1st June 2010, 08:11 | #315 | Link | |
Avisynth language lover
Join Date: Dec 2007
Location: Spain
Posts: 3,431
|
Quote:
I don't think it's too late to make a change. The Deblock_QED fix uses named parameters, so will not be affected. |
|
1st June 2010, 09:06 | #316 | Link | |
Registered User
Join Date: Oct 2002
Location: France
Posts: 2,316
|
Quote:
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. |
|
1st June 2010, 20:04 | #317 | Link | ||||
Architect
Join Date: May 2010
Posts: 57
|
Quote:
Quote:
Quote:
Quote:
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. |
||||
1st June 2010, 23:01 | #318 | Link |
Architect
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. |
13th June 2010, 07:43 | #319 | Link |
もこたんインしたお!
Join Date: Jan 2008
Location: Finland / Japan
Posts: 512
|
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 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]
|
|
|