MaskTools 2.0a48

[foxyshadis]

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.

[Gavino]

Originally Posted by foxyshadis

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.

[Manao]

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).

[jpsdr]

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...

[hydra3333]

yes, please reconsider. just this once, maybe.

[kemuri-_9]

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.

[Gavino]

Originally Posted by kemuri-_9

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.

[Manao]

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.

[Guest]

People that do not use named parameters deserve what they get, IMHO.

[hydra3333]

Oh ? They do ?

[Didée]

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.

[Bi11]

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.

[IanB]

Originally Posted by Gavino

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.

Originally Posted by Manao

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.

[Manao]

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.

[Gavino]

Originally Posted by Manao

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.

[jpsdr]

Originally Posted by kemuri-_9

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.

[Bi11]

Originally Posted by IanB

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.

Originally Posted by Manao

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 ...

Originally Posted by Manao

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.

Originally Posted by Manao

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.

[Bi11]

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.

[JEEB]

Excuse me as a MaskTools beginner, but I happened to come upon something that begs me to question if this is intended behavior:

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.

[foxyshadis]

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.