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 23rd February 2006, 16:42   #181  |  Link
Richard Berg
developer wannabe
 
Richard Berg's Avatar
 
Join Date: Nov 2001
Location: Brooklyn, NY
Posts: 1,211
Ok. The version of LimitedSharpen I have works ok on that script.
Richard Berg is offline   Reply With Quote
Old 12th March 2006, 04:02   #182  |  Link
foxyshadis
ангел смерти
 
foxyshadis's Avatar
 
Join Date: Nov 2004
Location: Lost
Posts: 9,564
Manao, would you mind putting masktools html docs on your site as well, so it could be more easily linked to?
foxyshadis is offline   Reply With Quote
Old 12th March 2006, 07:43   #183  |  Link
Manao
Registered User
 
Join Date: Jan 2002
Location: France
Posts: 2,855
Done : http://manao4.free.fr/mt_masktools.html
__________________
Manao is offline   Reply With Quote
Old 19th March 2006, 11:55   #184  |  Link
foxyshadis
ангел смерти
 
foxyshadis's Avatar
 
Join Date: Nov 2004
Location: Lost
Posts: 9,564
Posting again, you probably know why by now... Thanks for the docs though!

Looks like vmtoon shows a bug in some sources; I'd seen it reported before but now that I could repro it, I have a nice simple test case.

http://rapidshare.de/files/15864704/...muxed.m2v.html

Code:
mpeg2source("Inuyasha_Macroblocking.demuxed.d2v")
mt_Expand()
greyscale
It causes sliding diagonal lines on every frame, looks like some kind of off-by-8 error. Occurs with at least expand and inpand.

Last edited by foxyshadis; 19th March 2006 at 14:00.
foxyshadis is offline   Reply With Quote
Old 19th March 2006, 12:53   #185  |  Link
Manao
Registered User
 
Join Date: Jan 2002
Location: France
Posts: 2,855
I still can't reproduce it .

Two things to try on your side : add a greyscale() in order the chroma not to trouble what you're seeing ( since with your script, chroma is completely randomized ), and try to add "mmx=false, isse=false, d3now=false" in mt_expand(), to see if results are still the same. If not, screenshots would be welcomed ( with them, with some luck, i might be able to find the possible bug ).
__________________
Manao is offline   Reply With Quote
Old 19th March 2006, 13:15   #186  |  Link
foxyshadis
ангел смерти
 
foxyshadis's Avatar
 
Join Date: Nov 2004
Location: Lost
Posts: 9,564
I was using greyscale, so it wasn't chroma. isse=false fixes it. Oh, and the lutxy had nothing to do with it, just: mt_Expand() does it for me. Hm. (But not on all sources, especially smaller ones.)



This is a core duo, I don't recall it ever happening on the Pentium M, or the AXP. (Testing now.) Hope it's not a processor bug. >_<

Edit: Tested both, no error on AXP, same error on P-M. Main difference is P-M is SSE2 and AXP is not.

Edit2: Tested with 2.5.6a and it does not show. The AXP uses it, which also explains that. I normally use 2.5.7-cvs from tritical, versions at least since january show this. So now I guess I should take the report over to tritical and IanB?

It only shows on all 720x480 sources, not 320x240 or 704x480 so far.

Last edited by foxyshadis; 19th March 2006 at 14:04.
foxyshadis is offline   Reply With Quote
Old 19th March 2006, 19:34   #187  |  Link
foxyshadis
ангел смерти
 
foxyshadis's Avatar
 
Join Date: Nov 2004
Location: Lost
Posts: 9,564
From PM:
Quote:
Originally Posted by tritical
I'll look, but I'm guessing off hand that it is a pitch/width problem. In 2.5.6 planar frames by default get 16 byte aligned pitch on Y and 8 on chroma, but in 2.5.7 chroma gets 16 and Y gets 32 which on a 720 width frame means the pitch no longer equals the width (736 vs 720). Whereas on a 704 or 320 width frame pitch will still equal width since both are divisible by 32.
foxyshadis is offline   Reply With Quote
Old 19th March 2006, 21:03   #188  |  Link
Manao
Registered User
 
Join Date: Jan 2002
Location: France
Posts: 2,855
Ok, thanks again for that nice report, I found the bug as soon as I installed avs 2.5.7.

http://manao4.free.fr/masktools-v2.0a28.zip

Changelog :
Quote:
Fixed : asm optimizations for mt_inpand/mt_expand/mt_edge ( mostly )
__________________
Manao is offline   Reply With Quote
Old 19th March 2006, 23:23   #189  |  Link
IanB
Avisynth Developer
 
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,173
As noted by Tritical, 2.5.7 defaults to mod 16 alignment (SSE2 ready) for the chroma planes and mod 32 (chroma * 2) for the luma planes. This feature was introduced in 2.5.6 but is not enabled by default.

This feature is controlled by the SetPlanarLegacyAlignment(clip, bool) control function, bool==True -> Legacy mod 8 chroma, bool==False -> Advanced mod 16 chroma.

2.5.6 developers should test their plugins for future compatibility with the feature by putting a SetPlanarLegacyAlignment(False) at the end of their script.

In 2.5.7 for non-conformant old pluggins the feature may be restored to legacy mode by putting a SetPlanarLegacyAlignment(True) after the call to the problem pluggin.

In 2.6.0 the default alignment for all planes is 16. The alignment of each plane is independant of the other planes. i.e. your code must get the pitch for each plane independantly, pitch>>=1 will not work! SetPlanarLegacyAlignment only effect YV12 chroma plane alignment, forcing it to be half that of the luma plane.
IanB is offline   Reply With Quote
Old 10th May 2006, 15:12   #190  |  Link
redfordxx
Registered User
 
Join Date: Jan 2005
Location: Praha (not that one in Texas)
Posts: 863
@Manao

Is the speed of
mt_convolution("1 1 1 1 1 1 1 1 0 0 0 0 0 0 0","1 1 1 1 1 1 1 1 0 0 0 0 0 0 0")
and
mt_convolution("1 1 1 1 1 1 1 1 0","1 1 1 1 1 1 1 1 0")
same?

Tnx

Last edited by redfordxx; 10th May 2006 at 15:15.
redfordxx is offline   Reply With Quote
Old 10th May 2006, 15:27   #191  |  Link
Manao
Registered User
 
Join Date: Jan 2002
Location: France
Posts: 2,855
No, the filter isn't smart enough to see that zeroes are useless ( and won't, ever ).
__________________
Manao is offline   Reply With Quote
Old 31st May 2006, 21:07   #192  |  Link
Manao
Registered User
 
Join Date: Jan 2002
Location: France
Posts: 2,855
Ok, I fixed the bug described here

Changelog :
Code:
 * fixed : intern float to integer conversion that were badly rounding negative number.
That resulted in -1.0 been rounded into 0 (!). Most notably affected was mt_convolution.
Thanks redfordxx for pointing that out.
__________________
Manao is offline   Reply With Quote
Old 5th June 2006, 21:02   #193  |  Link
redfordxx
Registered User
 
Join Date: Jan 2005
Location: Praha (not that one in Texas)
Posts: 863
New problem

Code:
a=mt_luts(o1,o1, mode = "avg", pixels = "-1 0 1 0", expr = "y" )
b=mt_luts(o1,o1, mode = "avg", pixels = "0 -1 0 1", expr = "y" )
c=mt_luts(o1,o1, mode = "avg", pixels = "1 -1 -1 1", expr = "y" )
d=mt_luts(o1,o1, mode = "avg", pixels = "-1 -1 1 1", expr = "y" )
e=mt_luts(o1,o1, mode = "max", pixels = "1 -1 -1 1", expr = "y" )
f=mt_luts(o1,o1, mode = "max", pixels = "-1 -1 1 1", expr = "y" )
a,b,e,f works
c,d==>blankscreen in VD-M2

Last edited by redfordxx; 5th June 2006 at 21:06.
redfordxx is offline   Reply With Quote
Old 5th June 2006, 21:10   #194  |  Link
redfordxx
Registered User
 
Join Date: Jan 2005
Location: Praha (not that one in Texas)
Posts: 863
BTW: Courious:
Why mt_lutf has no pixels parameter?
It would be useful.
Workaround is mt_luts("y") followed by mt_lutxy but wouldn't it be faster?
redfordxx is offline   Reply With Quote
Old 5th June 2006, 21:30   #195  |  Link
Manao
Registered User
 
Join Date: Jan 2002
Location: France
Posts: 2,855
Ok, bug found, expect a release tomorrow.

mt_lutf doesn't have a pixel parameter, because its purpose is to adapt a local mask according to the value of the property of the whole picture. I fail to see how a pixels parameter would help. Can you give me an example of what you were thinking about ?

Finally, speed shouldn't be considered when playing with luts / lutf. I didn't inted these filters to be fast, only to be tweakable. Their purpose is to allow scripters who don't know how to code to have tools to make interesting scripts. From that, one could expect interesting filter's idea to come up, which, in turn, could be implemented into real filters, that would be fast.
__________________
Manao is offline   Reply With Quote
Old 5th June 2006, 22:14   #196  |  Link
redfordxx
Registered User
 
Join Date: Jan 2005
Location: Praha (not that one in Texas)
Posts: 863
Quote:
Originally Posted by Manao
Can you give me an example of what you were thinking about ?
Code:
s=mt_luts(o1,o1, mode = "avg", pixels = "1 -1 -1 1", expr = "y" )
mt_lutxy(o1,s, expr = "x y > x y ?" )
could be same as
Code:
mt_lutf(o1,o1, mode = "avg", pixels = "1 -1 -1 1", expr = "x y > x y ?" )
which would reconstruct diagonal lines..

Quote:
Their purpose is to allow scripters who don't know how to code to have tools to make interesting scripts. From that, one could expect interesting filter's idea to come up, which, in turn, could be implemented into real filters, that would be fast.
Yeah, that's 100% me.
My SmoothDeblock is slow as hell (0.25fps) and all I can do is to make it even slower. But, if I have time and am lucky, there will be something working from it, and maybe some1 will c-peed up it...
redfordxx is offline   Reply With Quote
Old 5th June 2006, 22:20   #197  |  Link
redfordxx
Registered User
 
Join Date: Jan 2005
Location: Praha (not that one in Texas)
Posts: 863
Well - throwing ideas:
How about making

mt_freerectangle : int left(0), int top(0), int width(2), int height(2)

So for example
mt_freerectangle(0,0,8,8)
would cover 8x8block right-down from pixel x inclusive
redfordxx is offline   Reply With Quote
Old 6th June 2006, 06:36   #198  |  Link
Manao
Registered User
 
Join Date: Jan 2002
Location: France
Posts: 2,855
Ok, new version is up : http://manao4.free.fr/masktools-v2.0a30.zip

Changelog :
Code:
 * fixed : luts was crashing if some pixels didn't have any neighbours in the pixels list.
 * added : mt_freerectangle, mt_freeellipse and mt_freelosange helpers.
__________________
Manao is offline   Reply With Quote
Old 6th June 2006, 06:46   #199  |  Link
Manao
Registered User
 
Join Date: Jan 2002
Location: France
Posts: 2,855
Concerning lutf, it doesn't work like you think. lutf collects information on the whole frame, and compute from that information a single value per frame, defined by the "mode". "avg", for example, will compute the average pixel value for the whole frame, while "range" will compute the difference between the max and the min on the whole frame.

Then, "expr" is a 2 variables lut which will be applied on the whole frame. In that lut, x is the value previously computed, while y is the value of the pixel. So I really can't add a pixel list parameter to lutf.

Concerning the mt_freeforms helpers, just a sidenote : mt_freerectangle(0, 0, 2, 2 ) will create a 3x3 rectangle ( 2 is included ), so if you want a 8x8 rectangle, use (0,0,7,7).
__________________
Manao is offline   Reply With Quote
Old 6th June 2006, 16:53   #200  |  Link
redfordxx
Registered User
 
Join Date: Jan 2005
Location: Praha (not that one in Texas)
Posts: 863
Quote:
Originally Posted by Manao
Concerning lutf, it doesn't work like you think.
Well I already know how it works, but that's why I proposed it as a change. If parameter pixels would be added, then
pixels="" ... current behavior
pixels=someshape ... behaviour like reverse luts

By the way it seems to me now that many operations of luts on square can be done faster with inpand,expand, lutxy, pointresize combo.

For example I am making a function to fill n*n pixels block with its max value with expand-pointrezize combo, because I don't know any other way how to do it. It has nice property that the larger n the faster. (Well, this fact also means that there should be faster solution)

But generally there can be really awsome things done with mt. Nice.

Last question: only being curious, because for implementation is maybe late.
Once I realized that lut works strange and then I realized:
mt_lut("1","2","3")
is not same as
mt_lut(yexpr="1",uexpr="2",vexpr="3")

iirc the defaults in old masktools were different there were only 3 expr parameters. In new masktools are 4 expr. What was there a reason? IMHO something like
yexpr=default(yexpr,"x")
uexpr=default(uexpr,yexpr)
vexpr=default(vexpr,uexpr)
would be best....
redfordxx 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 01:37.


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