Discrepencies in output when calling the same function twice

I've encountered some strange behavior with multiple instances of the same function being called from the same script. First, I'll describe some behavior that I did manage to solve, thus understanding what was being done wrongly on my part. Then, forward to what I don't yet understand. The issue began with me trying to compare result of several methods of smoothers, and creating a function for . The function was first conceived thus: Code:

Provide the complete AVS script with all functions, including SeeTheDifference().

Gladly, and thanks for the quick attention. :-) Code:

I removed ColorMatrix and PeachSmoother and the problem does not occur. Often, in such cases, a filter is using a global variable instead of a per-instance variable, and that causes one to interfere with the other. In this case, PeachSmoother would be implicated.

I've had a look at PeachSmoother's source code and it's riddled with globals. There's no way multiple instances can function without potentially interfering with each other. The result will be undefined and will depend on the specific invocations and ordering of operations.

Which leads me to ask: Why not just do: Code:

Ah, I see now. Seems like only possible way would be a bob -> reinterlace then.

P.S. The practical solution is, of course, instead of using SeeTheDifference(VHSPeachClean(),VHSPeachClean()) to use VHSPeachClean() SeeTheDifference(Last,Last) In which case the function isn't being called twice, but only the resulting clip (I would assume that will also translate to faster processing). I am still intrigued as to what cause the logical collision - or rather, what causes a logical collision when there's a double-call to PeachSmoother using an identical chain, that doesn't occur when the chain is arranged in a different manner. While this gives a practical solution should I want to test other functions chained after that point, it renders any testing of pre-chained filters useless, as one cannot tell whether any changes seen are due to such usage or due to the aforementioned discrepancy. Back to frame 0. -- Piggie

@PigOnWing As I said, the behavior will be undefined. Undefined can include working correctly (for some fortuitous invocations). :)

@stickboy: I actually was influenced by your functions when creating my own functions quoted above. Kudos for that. :-) @Leak: Yup, I (surprising myself) understand the problem. However, as far as I go, I would still not call anything regarding PeachSmooth's author, simply because I wouldn't allow myself to speak anything about programming when I know nothing about it. :-) It's too much of a mystery to me. @Neuron2: Thanks again. I'm now ceasing my attempts of making a non-workie work, and instead trying to approach achieving the same goal in a different manner. The original goal was to check the differences in different order of chaining several smoothers (used as general denoisers). I wanted to check the results I'll get from chaining FluxSmooth before and after PeachSmoother. In order to overcome the limitation calling PeachSmoother only once in order to get consistent results, I'm currently using this approach: Code: