Same script, different outputs !

[Eluent]

Hi,
this is my first post but I've been browsing these pages a lot, and did learn and get a lot : thx !

Yet I've just finished my new computer (built and installed) because my laptop is slow and I have a lot of files to generate.

But the crap is the laptop gives me some better output on the scripts which include the use of some edge detection (or motionmask) : as you have probably seen, the output of any of mt_edge TedgeMask motionmask will give you a monocolor green screen, at least at the start of the ouptut.

THE PROBLEM :
using the same script with the same version of avisynth and of the filters the output is much longer monocolor on my brand new core2duo PC ! (something like 1-3 sec on the DELL inspiron laptop and around 10s on the c2d). Well actually, if used with DirectShowSource on an mpeg I would get monocolor all the way on the desktop PC !

I also have the same version of ffdshow installed on both computer.

And I have also noted that the green is longer when I watch the output on MediaPlayerClassic or BsPlayer as with VirtualDub (on both computer, and this is bugging me as of wich method can one rely on to test a script).

One example of script :

Avisource ( "x.avi" ) #or DirectShowSource
return DEdgeMask

With DEdgeMask the difference was bigger as with mt_edge or motionmask, not only would the green stay for 6s on the new PC as opposed to 3 on the laptop, but I would also have a very different edging..

(as a side note if you ask me what I want to do with this kind of output, well I've definitly some use for it, i find it extremly interesting for expermental video, VJing and so on, I didn't see anyone talking about using it this way, but avisynth can be a jewel as a special effects generator, if anyone is interested, I can provide some miore exciting examples, this one stands merely for its simplicity)

I have checked that my processors are ok with Orthos.
I have checked the RAMs with memtest86+.

I just transfered every plugins and every scripts from one computer to the other so there's no way the problem would come from there. Could it be something to do with the decoders installed on the machines ? I have the same versions of ffdshow on both computer (the latest), but maybe, I'm not sure, maybe I have installed XVid and 3ivx on the laptop after ffdshow (in order to use MPEGStreamClip)..

This is very tough and very frustrating, can anyone please enlighten me ?

[gzarkadas]

The fact is that if you use the masktools filters with the default values for parameters u and v (as you most probably do) then the content of those planes after the filter is pure garbage (from the masktools docs). Thus the random variation in color (since u, v are the chroma planes).

[Didée]

Exactly as gzarkadas explained.

If you want to use edge masking as a special effect, try

mt_Edge(mode="prewitt",thY1=0,thY2=255).Greyscale().Invert()

as a start.

[Eluent]

Wow,
thx for answering so fast, I had almost lost any hope.
I still find it puzzling the way mt_edge generates some "random" output, since it is not so random on the different machines I use (but maybe that's what you meant, that mt_edge generates something unpredictable on any computer, but will generate the same output on one specific computer ?)

Anyway that means I can either add some 15s at the beginning of my clips before edging them and the trimming this, or use what Didée suggested (except Invert which AFAIK doesn't help and is just an aesthetic choice), the way I get around this and get almost excactly what I wanted is ike this :

#############
Avisource ( "x.avi" ) #or DirectShowSource

s = last

mt_edge(mode="prewitt",thY1=0,thY2=255)
Greyscale()
#Invert()

mt_logic(s, last, "and") #brings the thresholded colors back

return last

[Didée]

If you want to keep the original colors, use

mt_edge(mode="prewitt",thY1=0,thY2=255, U=2,V=2)


From the MaskTools-v2 documentation:

[ explanation for mt_XYZ( [other parameters], Y=?, U=?, V=?) ]

int "y" (3), int "u" (1), int "v" (1)

These three values describe the actual processing mode that is to be used on each plane / channel. Here is how the modes are coded :
x=-255..0 : all the pixels of the plane will be set to -x.
x=1 : the plane will not be processed. That means the content of the plane after the filter is pure garbage.
x=2 : the plane of the first input clip will be copied.
x=3 : the plane will be processed with the processing the filter is designed to do.
x=4 (when applicable) : the plane of the second input clip will be copied.
x=5 (when applicable) : the plane of the third input clip will be copied.
As you can see, defaults parameters are chosen to only process the luma, and not to care about the chroma. It's because most video processing doesn't touch the chroma when handling 4:2:0.

[Eluent]

Yes right about U2 V2..
but that's too accurate of an output, I'm looking for something more grainy like the "roberts" kernel give, and the trick posted above just gives something like that
thx anyway,
and by the way Didée did you know that applying SeeSaw (sometime with some good denoising along with it) before edging would give much shorter monocolor output ?

[Didée]

To be sure, what d'you mean by "shorter monocolor output"?
A shorter period of time with "wrong" colors (this I guess)? Or eventually "thinner edges"?

If the latter - that's to be expected.

If the former - no, I didn't know, and don't care. Behaviour of chroma planes with U|V=1 is of zero interest.
(It depends on the actual memory layout/usage, and will change with every tiny change made to the script. It will even change when re-opening the same script again. The behaviour is *not deterministic*, aka 'random'.)