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. |
12th March 2006, 07:43 | #183 | Link |
Registered User
Join Date: Jan 2002
Location: France
Posts: 2,856
|
__________________
|
19th March 2006, 11:55 | #184 | Link |
Angel of Night
Join Date: Nov 2004
Location: Tangled in the silks
Posts: 9,559
|
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 Last edited by foxyshadis; 19th March 2006 at 14:00. |
19th March 2006, 12:53 | #185 | Link |
Registered User
Join Date: Jan 2002
Location: France
Posts: 2,856
|
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 ).
__________________
|
19th March 2006, 13:15 | #186 | Link |
Angel of Night
Join Date: Nov 2004
Location: Tangled in the silks
Posts: 9,559
|
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. |
19th March 2006, 19:34 | #187 | Link | |
Angel of Night
Join Date: Nov 2004
Location: Tangled in the silks
Posts: 9,559
|
From PM:
Quote:
|
|
19th March 2006, 21:03 | #188 | Link | |
Registered User
Join Date: Jan 2002
Location: France
Posts: 2,856
|
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:
__________________
|
|
19th March 2006, 23:23 | #189 | Link |
Avisynth Developer
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,167
|
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. |
10th May 2006, 15:12 | #190 | Link |
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. |
10th May 2006, 15:27 | #191 | Link |
Registered User
Join Date: Jan 2002
Location: France
Posts: 2,856
|
No, the filter isn't smart enough to see that zeroes are useless ( and won't, ever ).
__________________
|
31st May 2006, 21:07 | #192 | Link |
Registered User
Join Date: Jan 2002
Location: France
Posts: 2,856
|
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.
__________________
|
5th June 2006, 21:02 | #193 | Link |
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" ) c,d==>blankscreen in VD-M2 Last edited by redfordxx; 5th June 2006 at 21:06. |
5th June 2006, 21:30 | #195 | Link |
Registered User
Join Date: Jan 2002
Location: France
Posts: 2,856
|
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.
__________________
|
5th June 2006, 22:14 | #196 | Link | ||
Registered User
Join Date: Jan 2005
Location: Praha (not that one in Texas)
Posts: 863
|
Quote:
Code:
s=mt_luts(o1,o1, mode = "avg", pixels = "1 -1 -1 1", expr = "y" ) mt_lutxy(o1,s, expr = "x y > x y ?" ) Code:
mt_lutf(o1,o1, mode = "avg", pixels = "1 -1 -1 1", expr = "x y > x y ?" ) Quote:
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... |
||
5th June 2006, 22:20 | #197 | Link |
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 |
6th June 2006, 06:36 | #198 | Link |
Registered User
Join Date: Jan 2002
Location: France
Posts: 2,856
|
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.
__________________
|
6th June 2006, 06:46 | #199 | Link |
Registered User
Join Date: Jan 2002
Location: France
Posts: 2,856
|
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).
__________________
|
6th June 2006, 16:53 | #200 | Link | |
Registered User
Join Date: Jan 2005
Location: Praha (not that one in Texas)
Posts: 863
|
Quote:
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.... |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|