CopySame Filter

[Marc FD]

CopySame Filter (beta4) with a decent motion detection engine can be dl on my site.

If you want to encode real 0-frames :devil:

(and when the 0-frame droping feature would be integrated to XviD, you will be able to encode real variable framerate video content like RV9 do !!)

:confused: => see related Doom9 forum (http://forum.doom9.org/showthread.php?s=&threadid=28773)

Hope you'll enjoy it

[Marc FD]

Here i released the beta 6.
IT WORKS !!
Here is a TEST (http://ziquash.chez.tiscali.fr/cstest.html) on HQ anime the result is simply... hmmm... great. :cool: +:D

And when the XviD 0-frame dropping feature would be implemented, the size reduction would be bigger (about 10 to 30 % !!)
and all this WITHOUT any quality reduction if you want !!

(for dl use my signature)

[Marc FD]

beta7 released.

2x to 20x faster :devil:
Can do real-time now :cool:

if you need help, just post :D

[SleepEXE]

Just wanted to say thanks for the cool plugin. I've been hanging on to some Simpsons episodes in hopes something would come along that would allow them to be compressed more efficiently. I have some compression jobs running right now but I'm definitely going to give this plugin a whirl just as soon as I can. Good stuff.

Best regards,
SleepEXE

[vlad59]

Hi,

I just made a first test with your filter and I got good results. But can you explain what does mean the numbers in the debug mode ????

I got an idea on some but not for all !!

thanks in advance.

EDIT : I'm stupid, I've found the solution in your doc, sorry

[vlad59]

I got a little problem with your filter, it cause avisynth to crash as soon as I want to compress my clip :

let's explain better :

- my avs filter is very simple :
a mpeg2source and your filter with those parameters :
CopySame(1,32,32,4,4,0.2,0.1,3)
or
CopySame(2,32,32,4,4,0.2,0.1,3)

No crop, no resize at all

- I load the script in virtualdub and I start scanning the result frame by frame, it work without any problem.

- But if I select the Xvid compressor and use the save to avi function, vdub reported me a avisynth read error. :(

If I remove your filter I can save my avs to a Xvid avi.

Just ask if I forgot to explain you something !

[Marc FD]

Thx all :)

I'm going to improve it more.
But i'm definitively waiting for XviD 0-frames :)
See my test ;)

@vlad59
CopySame(1,32,32,4,4,0.2,0.1,3)
my default settings :D are not the best !
You want me to code or tweak ;) ?

the debug mode output...
shit, i forgot. need to take a look. hop, an .avs file :) (with tons of cnr2/psnr test lines)
oops ! avisynth read error :(
I see. i use SimpleResize(576,320) before my filter and it works...
I'll fix that this afternoon.. use 4x values should work. try to tweak with crop/resize :)


"Frame # 1608 96.85 (0.90) (1/3)+"
or
"Frame # 2165 0.00 (0.00) (2/3)-"

frame # , i think you know what it is :cool:

96.85 and 0.00 : rel (relative movement computed value based on brute pel motion estimation (diamond search))

(0.90) and (0.00) : relq = rel(n)/rel(n-1) where n is the frame number

(1/3)+ and (2/3)- the 0-frame count/max 0-frames row
+ normal frame
- 0-frame :)

Hope it helps :)

[Marc FD]

Okay, i fixed it !! :cool:

i just checked the whole code and after that it worked like a charm :)
i've coded something who gives a lil'speedup on debug mode :D

You can now download CopySame beta8

[Marc FD]

CopySame beta9 is out :cool:

And beta-testers of previous versions will see that it has been totally rebuilded from scratch (no cute lil'white pels anymore..)

will make a big test as soon as Z-frames are Ok in XiD. it seems there is some issues with MC inertia...

[MoonWalker]

Originally posted by Marc FD
will make a big test as soon as Z-frames are Ok in XiD. it seems there is some issues with MC inertia...

What exaclty are Z-frames? We have I/P/B-frames.Never heard of Z-frames :)..

MoonWalker

[Didée]

Probably a joke, because "B-frames" was THE FORBIDDEN WORD some time ago?

Or is there something arising, to distinguish the (future) XviD-Bframes from the divX5 ones, because the latter are - - ah, don´t get the word here. In German, we say "hemdsärmelig" :) [meaning some kind of lazy implementation]

[dividee]

I think what he means by Z-frames (or 0-frames) are voluntarily dropped frames, to implement some kind of variable framerate.

[Didée]

Okay, now I found the button to switch my brain on, and did so.

Yes, dividee, that makes much more sense.

Let the topic continue ...

[Marc FD]

Exactly :
B-frames are constitued of B_VOPs
and Z-frames are in fact zero-frames (or 0-frames)
theorically, it should be name N-frames (N_VOP coded)
but i founded Z-frames as a liitle "something" :)

PS : i think DivX 4 or/and 5 is Z-frames capable, but i'm not relly sure of that.A Z-frame is only a 10 bytes big I-frames, in fact.

Hope it helps to understand....

[Kaiousama]

TNX to marcFD for the suggested settings (in the readme there are settings for an older beta wich accept more parameter, i don't know).

A little thing:
Because the filter is very useful for anime encoder like me, it would be good if it'll be the possibility to copysame not all the frame but leave a bottom and upper lines compressing normally and apply the copysame filter only to the rest of the frame, that's because mainly in the titles but even in the episode i have to put subtitles and toptitles with karaoke effect, this mean the frame is not exactly the same as the past frame (but at 85-90% is the same, ehy encode it all if it would be a potentially z-frame?)

Bye:p

[Marc FD]

A way to get what you want is to simply use a script like that :

(i assume 640x480 res here)
src=....
up=src.Crop(0,0,640,400).CopySame(...)
down=src.Crop(0,400,640,480)
return StackVertical(up,down)

hey, it's avisynth's power !! :devil: + :cool: !

BTW i attached a pre-release of CopySame 1.1
If you can't get CopySame 1.0 running, test it please :)

[Kaiousama]

a way to get what you want is to simply use a script like that :

Amazing :eek: i'm really without words :eek:
i'll try it soon, can I in this way apply different filters in different part of the frame (say yes and i'll marry you)?

BTW i attached a pre-release of CopySame 1.1
If you can't get CopySame 1.0 running, test it please :)

ehm..... the version 1.1 attached where?

[Marc FD]

Amazing i'm really without words
i'll try it soon, can I in this way apply different filters in different part of the frame (say yes and i'll marry you)?

Yes. "Hey, it's AviSynth's Power !! :cool: + :devil: "(tm)(R)

ehm..... the version 1.1 attached where?

a mod must accept the attachement...
and it's already an old version (more than 12 hours :D )
so i don't think it worth it. I gived the last 1.1 bin to vlad and it finally works "sans pb, impecable" (~like a charm) for him.
So i think i will release it the 2/8 . i'll improve the movement detection before.

[Defiler]

I'm having some difficulty getting CopySame to function.
Have the parameters changed since the beta?
Doing CopySame(1,35,35,0,350,10) yields a nasty access violation when the script is executed, as does CopySame(1,32,32,4,3,3).
(As you can see, I have no idea what types of numbers are valid for the second-to-last parameter.)
I am using AviSynth 2.04, and I've tried both 1.0 and 1.1 of CopySame.
I've read the HTML file included with the 1.0 download, but some of the parameters puzzle me. It would be nice to have some guidelines as to which numbers are valid/sane.
I've searched the forums, and pasted in every instance of CopySame() that I found mentioned, but none work for me.

Here's an example script:
LoadPlugin("C:\Bin\AviSynth\CopySame.dll")
AVISource("D:\Blah...")
CopySame(1,35,35,0,350,10)
crop(10,3,695,470)
BicubicResize(624,464,0,0.75)

Total failure when I try to handle that AVS file.

[Belgabor]

Hi MarcFD,

I know you somewhere said you don't want to work anymore on this filter, but nevertheless i have an improvement request which i think could be quite useful.

First my problem: the anime ep I'm currently using to test new filters has a scene which is over all pretty dark, not black, just dark. In one corner there's a flickering torch. If i tweak the Copysame filter that way that it recognizes the flickering as motion, other frames which are much brighter and are clearly the same are not copied because the noise "motion" was higher than the torch in the other scene.

So what would be the request? Well i though a possiblility would be to separate the picture in squares (2x2 or 3x3 perhaps) and call a frame "in motion" if the threshold is matched in just ONE of this sqares. This way you could ignore something more distributed across the whole frame like noise (= it would fall below the threshold).

I don't know if this is a totally weird idea or how much of a hassle it actually would be to code it, it's just a thought you might consider ;)

Cheers
Belgabor

P.S.: Some statistical function (DebugView output?) would be nice too ;) aka how much frames were actually "zeroed" in total.

[spyder]

very good idea Belgador. This would be a nice addition to CopySame.

[Marc FD]

In fact i was thinking of an optimised box search, who would scan all AxA blocks of the image (A would be a coef)
I was going for it in 1.1 :)

In fact i don't think i will break devellopement on CopySame, because the 1.1 is really too cool (MMX/ISSE optimised :D)

I will just split MAM in 2 filters, that's all.
My Mpack idea was just a dumb idea. i will stop it ...

PS : I'll think of a log output too :)

[Defiler]

Marc: Can you point out what I'm doing wrong there in my script?

[Marc FD]

@defiler
Simple : CopySame 1.0 is buggy, slow and less accurate than 1.1.
that's all :)
Don't worry i know this bug and i already corrected it in CopySame 1.1

@belgador
i think you'll be happy, i had already coded 50% of the algo. i've just finished the code and optimised it (but it's slower, ~20 fps).

@All
after 6 hours of coding (20h30-02h30), i'm finally almost (98%) ready for a pre-release (no src) of CopySame 1.1 :cool:
i'll do a lil MMX fix and udate the doc this morning, and i'll release.
Just need to sleep right now because i've a some MMX code to fix and i can't think at all ! now sleeeeeeeeeeeep ...............

[Marc FD]

Here it is :)
CopySame 1.1 official release out :cool:
don't thing a 0.1 increment in the version count mean it's a little update in the code : there are tons of improvements :

- All know bugs fixed (first-frame bug, random acces violations)
- Some cosmetics (new HUD)
- local MAD implemented and working (+debug mode lMAD info)
- low-level MMX/ISSE code optimisation
(should work around 25 fps without the lMAD algo)
- New spatial cleaning algo (fast and accurate)
- easy to use param list

in fact there are so much modifications between 1.0 and 1.1 that i don't remember them all !

Enjoy :devil: !

PS : I'm going to make some tests with XviD on some anime material, to update cstest.html (because the last test was made with beta6 !)

[bb]

Great! I'll test it ASAP (probably this weekend...).
Why didn't you name it CopySame 2.0?

bb

[lark]

at least i cannot find the copysame 1.1 from your download page.
actually 1.0 (the zip) seems to be gone as well...

is this a problem w/ our proxy?

regards
t :)

[Marc FD]

I don't like too boost version values.
i.e. having a CopySame v20.58 would not make it better than a v1.9

almost all coders are shy and avoid to show off ;)

[Marc FD]

@iark
hit on "update" :D

[lark]

thanks for almost real-time answer.
i tried to reload the page many times
and even with different browser, but
didn't see it... :-(

and after your post the miracle happened.
thanks a million.

(must have been our proxy that gave me
the old page regardless of the reload)

regards
t :)

[Defiler]

Thanks!
By the way; I took TomsMoComp out of the script, and suddenly CopySame started working. Conflicts ahoy!

[Defiler]

Sorry to keep replying to your thread here.. but I'm trying to use CopySame in the following way:
When there are two or more consecutive frames that are nearly identical, copy the second frame over the first one.
Here's an example.

Bad frame (first):
http://www.hellninjacommando.com/misc/goodframe.jpg

Good frame (immediately thereafter):
http://www.hellninjacommando.com/misc/badframe.jpg

Here's the entirety of the script I'm using:

LoadPlugin("D:\Programs\avisynth\CopySame.dll")
AVISource("D:\Temp\Test.avi")
ConvertToYUY2()
CopySame(mode=1,llt=256,lct=256,slt=256,minMAD=10.0,minlMAD=987654321,lxs=60,lys=60,mfs=10)


I started at the default settings, and worked my way up to the (very aggressive) settings you see above. I tried putting reverse() statements on either side of CopySame, but that doesn't help.

Any tips?
By the way.. 1.1 is MUCH more stable and well-documented than 1.0. Thanks.
In the "usage" portion of the help document, I did notice that the last three parameters are ",mlxs=0,mlys=0,mfs=3".. That should be ",lxs=0,lys=0,mfs=3", right?

[Marc FD]

@ALL
ARGH, there is indeed a bug in CopySame 1.1 who disables dropping.
a very dumb thing : a && in the place of a ||
download CopySame 1.1b, it should work now :)

Originally posted by Defiler
Sorry to keep replying to your thread here.. but I'm trying to use CopySame in the following way:
When there are two or more consecutive frames that are nearly identical, copy the second frame over the first one.
Here's an example.

Bad frame (first):
http://www.hellninjacommando.com/misc/goodframe.jpg

Good frame (immediately thereafter):
http://www.hellninjacommando.com/misc/badframe.jpg

i could add a reverse mode, because you're not he first user who tries to do it ;) (and it would be as fast than norm mode)

Here's the entirety of the script I'm using:

LoadPlugin("D:\Programs\avisynth\CopySame.dll")
AVISource("D:\Temp\Test.avi")
ConvertToYUY2()
CopySame(mode=1,llt=256,lct=256,slt=256,minMAD=10.0,minlMAD=987654321,lxs=60,lys=60,mfs=10)


I started at the default settings, and worked my way up to the (very aggressive) settings you see above. I tried putting reverse() statements on either side of CopySame, but that doesn't help.

dl CopySame 1.1b

Any tips?
By the way.. 1.1 is MUCH more stable and well-documented than 1.0. Thanks.
In the "usage" portion of the help document, I did notice that the last three parameters are ",mlxs=0,mlys=0,mfs=3".. That should be ",lxs=0,lys=0,mfs=3", right?

the param list is like decomb : you can enter them in any order, and you just need to type params who are not defaults :)


sorry for the buggy first releas.

[kyousuke]

i'll test this right now !
thks marco :D

[Defiler]

Works as advertised now. Amazingly great.
Stomps on those Divx 3.11 artifacts perfectly.
Maybe I wasn't clear enough in my previous post.. I meant that the parameter names in the example are incorrect. I know they can be used in any order.

[Marc FD]

i see. yep, mlys/mlxs is false. i renamed them recently.

i'm working on the blend/reverse feature now.

[Marc FD]

I worked late on some improvements for copysame.
so here is a beta bin of CopySame 1.2

new :
- reverse mode (use mode=2)
- blend mode :devil: (use mode=3)
there are some bugs when you use big max frame shifts with blend but it seems to work with mfs=3 (default)
- debugview info
will send a line to debugview each time it creates a Z-frame

i hope some experienced users of CopySame could test it ;)

I'm going to build a custom version of XviD with anime-specific ME
(EPZS16 mixed with PMVfast8 adv diamonds) and frame_drop_ratio activated (but without B-frames)

If anybody is interessed, i could post it
(it's just a little experimental build to get the best of XviD+CopySame)

"CopySame 1.2(beta) bin.zip" attached.

[bb]

I am interested in your XviD version. Please post it.

bb

[Ivion]

I totally agree with bb, please post it, I'm eager to test it. (In conjuction with the new CopySame, Decomb and Masked Smoother :D).
So I'm going to test many things, please post it Marc FD! :)

[Defiler]

Will we need to use this "test" Xvid build to both play and encode files with Z-frames, or just to encode them?
Either way, I want to test it. Heh.
I'm playing with CopySame 1.2b now.

[Marc FD]

just to _encode_ them !!
it would be a build with a different ME and the frame_drop_ratio enabled. so you would be able to play it with _any_ mpeg-4 decoder.

[Defiler]

That's so far beyond awesome, I'm not sure there's even a word for it. Voopy!

[Marc FD]

hey, ii's just a custom XviD build. no magic here. don't expect something else than better Z-frame dropping and maybe 1-2% gain with the ME !!
if Koepi help me, i could even give a intel compilator optimised version ;)

[kyousuke]

very interesting marc by your build !

i would test it on a recent raw and on my STaker dvd (the screen you saw last days :p)

all of this is really "sugoi" :p

[kyousuke]

your CopySame.dll don't want to be loaded !
v1.1 or v1.2b, my avs don't want it o_o

so i made a rapid test without all my plugins :
LoadPlugin("c:\test_encode\anime\MPEGDecoder.dll")
LoadPlugin("c:\test_encode\anime\CopySame.dll")
MPEGSource("c:\test_encode\anime\STopening.m2p")
CopySame(false,32,32,4,4,0.2,0.1,3)

vdub reply by : script error : invalid arguments "CopySame"
(c:\test_encode\anime\test.avs, line 4)

nothing to do...... that don't want to load the dll o__o,,,

[Marc FD]

READ THE README !!!!

it's really dumb as that : the param list is a new one in v1.1 / v1.2

PS: using 32,32 could gives you a very poor fade detection. you should check that before doing real encoding.

about my XviD build, i'm doing intensive testing and the result are very ..... (you would know when you would test it ;) )
but currently i get ME-artifacts, so i need to fix that.

[kyousuke]

for the PS, i c/c your exemple form your read me :p
wait i try to understand your plug

ok for your build, good luck


nb : for my problem with MAM on the other thread... i think i won't use TemporalSoften again. it seems the problem came from it... :(


update :
yes it works ;)

[Kaiousama]

It would be a paradise to have an anime dedicated xvid version *_*

In my opinion an ideal anime codec has to have a full variable framerate support:
in that way you can save the maximum space in the 12 and 8 fps scenes and see the CG 30fps scenes fluid, not as the decimating IVTC process give.
For the detection of lower framerate scenes your copysame code is a good worker, it would flag this scenes and the codec decimate them.
I don't know how much is this an utopistic possibility ^_^

another good implementation for an anime codec would be an algorithm that identifies the edges in the scene and gives to the moving edge a bigger (much bigger) bitrate than the other motion vectors, that's to minimize the bad ringing effect that appears i.e. when a character moves the head or speaks (that actually only an higher total bitrare or an ugly blur filter can solve).

For now, i'm testing the copysame, can you explain more in detail, in the next readme, how the imad option work?

An idea for the developement would be to make the frame in many parts (i.e. 1part=1macroblock) and apply the copysame to each part,to have in every frame only the real changing portions, i mean: if in a frame there is only a character that speaks, copysame will copy the exact rest of the frame but the mouth field, in that way the background noise of the scene can be totally calcelled and the codec can use the lowest space possible to encode that frame.

You are making a great work,thanks!!

[Marc FD]

Originally posted by Kaiousama
It would be a paradise to have an anime dedicated xvid version *_*

In my opinion an ideal anime codec has to have a full variable framerate support:
in that way you can save the maximum space in the 12 and 8 fps scenes and see the CG 30fps scenes fluid, not as the decimating IVTC process give.
For the detection of lower framerate scenes your copysame code is a good worker, it would flag this scenes and the codec decimate them.
I don't know how much is this an utopistic possibility ^_^

that's why i want frame_frop_ratio actived. with it XviD make 10 bytes big Z-frames
(hard to decimate more ;) )

another good implementation for an anime codec would be an algorithm that identifies the edge in the scene and give to the moving edge a bigger (much bigger) bitrate than the other motion vectors, that's to minimize the bad ringing effect that appears i.e. then a character moves the head.

that's what DCT coefs are for, and it's because the codec is edge sensible that you see ringing effects (or mosquito noise) it's due to the DCT high frequencies... it's not XviD specific nor anime specific (movie have edges too..)

For now, i'm testing the copysame, can you explain more in detail, in the next readme, how the imad option work?

i hope belgador would be able to use the power of this feature (because he had the almost same idea) so he could explain it to you. for me, there is nothing more to explain :(

An idea for the developement would be to make the frame in many parts (i.e. 1part=1macroblock) and apply the copysame to each part,to have in every frame only the real changing portions, i mean: if in a frame there is only a character that speaks, copysame will copy the exact rest of the frame but the mouth field, in that way the background noise of the scene can be totally calcelled and the codec can use the lowest space possible to encode that frame.

an easy way to do it right now : use a.MAM(a.temoralsoften(1,255,255,a) where a is your source clip. never tested it but should fix everything who isn't moving . maybe i would give an another try to the MAD concept, with temoralfixing and spatialsmoothing...

You are making a great work,thanks!!
thx


going to work on "MarcFD anime-spec XviD build" now :cool:

[Suikun]

Originally posted by Kaiousama
another good implementation for an anime codec would be an algorithm that identifies the edges in the scene and gives to the moving edge a bigger (much bigger) bitrate than the other motion vectors, that's to minimize the bad ringing effect that appears i.e. when a character moves the head or speaks (that actually only an higher total bitrare or an ugly blur filter can solve).


In fact I actually implemented such a thing =). It somehow works like inversed luminance masking and lowers the quants for macroblocks with edges in it. I haven't tried to make it motion adaptive yet...
The problem is that the files most times get way too big (1.5 times the size for quant 5 o_O;) and it most likely completely screws the curve algorithms. Also it only seems to works with const quant (is someone who knows about the curve treatment able to help me there?)...
If someone (Marc FD? ;) ) wants the code, just ask.

[Marc FD]

if you try to reverse the logic of DCT-based (MPEG-1,2,3,4) codecs, you can't use such a codec to do it :D

some pre-processing would help, Bframes are designed for this type of movement, post-processing totally kills ring noise and some ME do slightly less ringing (like EPZS, but EPZS are a still in very early stage of developement, and are bad for inter4v ME)

it's getting confusing, because there are 2 kind of ringing-like artifacts : DCT-based and ME-based. they seems very alike,and are somehow close from eachother, but the source is not exactly the same...

[Kaiousama]

if you try to reverse the logic of DCT-based (MPEG-1,2,3,4) codecs, you can't use such a codec to do it
this is not totally true, i mean suikun has touched the right point, the logic of DTC is good in some cases,the matter is only to tweak this logic recognising the edges (it seems suikun has the algorithm done) and made an exception that recognise this fields like a static scene even if around there is movement (and gives to it a big bitrate).

The logic of DCT is good in scenes where the movement is total and strong.
But often the movement (even quick) is only in a small part of the frame and the uman eye mades the focus in this restricted area and can watch the definition of the shape even in quick moving(and the rest of the frame gets over-focus),that's why it'll be very useful to treat this tipe of edges as a static scene, toggle the bitrate to the rest of the frame and give it to the moving edges, it'll result in a better quality of the scenes but doen't change the filesize of the frame.

I think it can be implemented in the codec like an exception to recall if the edge algorithm find a scene wich has the amount of movement in the edge portions much bigger than the rest and if this movement is in a certain% of the total frame size, what do you think about?

that's what DCT coefs are for, and it's because the codec is edge sensible that you see ringing effects (or mosquito noise) it's due to the DCT high frequencies... it's not XviD specific nor anime specific (movie have edges too..)
that's true but in the movies this problem has a minor importance because the real things hasn't a definite edge like the pencil works, so this edging effects are very lesser.

an easy way to do it right now : use a.MAM(a.temoralsoften(1,255,255,a) where a is your source clip. never tested it but should fix everything who isn't moving .
you're going too fast ^_^
i haven't understood if this is a common line to put in the script or to put it in the copysame parameters, can you post a complete example script with this option enabled? tnx

going to work on "MarcFD anime-spec XviD build" now
it sounds cool -_-

[Marc FD]

Originally posted by Kaiousama
this is not totally true, i mean suikun has touched the right point, the logic of DTC is good in some cases,the matter is only to tweak this logic recognising the edges (it seems suikun has the algorithm done) and made an exception that recognise this fields like a static scene even if around there is movement (and gives to it a big bitrate).

The logic of DCT is good in scenes where the movement is total and strong.
But often the movement (even quick) is only in a small part of the frame and the uman eye mades the focus in this restricted area and can watch the definition of the shape even in quick moving(and the rest of the frame gets over-focus),that's why it'll be very useful to treat this tipe of edges as a static scene, toggle the bitrate to the rest of the frame and give it to the moving edges, it'll result in a better quality of the scenes but doen't change the filesize of the frame.

I think it can be implemented in the codec like an exception to recall if the edge algorithm find a scene wich has the amount of movement in the edge portions much bigger than the rest and if this movement is in a certain% of the total frame size, what do you think about?

i know that, it's why i'm will modify some hardcoded settings who would allow to skip more MBs...
gruel just coded (3 days ago) a new encoder version for anime, it would do approx. the same that the algo you describe. it would be included in my XviD build

that's true but in the movies this problem has a minor importance because the real things hasn't a definite edge like the pencil works, so this edging effects are very lesser.

i never said the opposite ! hey, you're not speaking at a n00b in anime here : i always said that anime encodes are MUCH harder than movies encodes !! it's why anime DVDs always seems to be bad masterised...

you're going too fast ^_^
i haven't understood if this is a common line to put in the script or to put it in the copysame parameters, can you post a complete example script with this option enabled? tnx

MAM is another of my filters, based on CopySame movement detection.
look at the world-record-length thread named "smooth in time and space".
a full script ? i'm in a good mood :

LoadPlugin("MAM.dll")
a=*Source(...)
MAM(a.TemporalSoften(1,255,255),a)

that's all. maybe it will produce TERRIBLE artifacts, dunno at all, didn't tested it. (you're gonna discover first,) post a word if it works ;)

it sounds cool -_-

You said it. I've now configured my intel compilers correctly and i've found a way to avoid artifacts. but the Motion Compensation would be image-based = a little bit slower (-0.1 fps ?)
there will be advanced coeff thresholding in this version too.




@all
i didn't do much much animes encodes last weeks, so what do you think it's better for anime ??
EPZS ME (Koepi's builds) or PMVfast ME (uManiacs)
i would vote for PMVfast, but i'm open to everything ;)

[Kaiousama]

i never said the opposite ! hey, you're not speaking at a n00b in anime here : i always said that anime encodes are MUCH harder than movies encodes !! it's why anime DVDs always seems to be bad masterised...
excuse me, but i don't want to give that meaning, i agree with you that many anime dvd productions doesn't have the good treatment reserved to films :(

gruel just coded (3 days ago) a new encoder version for anime, it would do approx. the same that the algo you describe. it would be included in my XviD build,there will be advanced coeff thresholding in this version too.
it sounds to have all the cards to be a great xvid build, i'm very happy ^_______^ (now i have definitively to say that french are very lucky people, because they have saw many Ghibli's masterpieces in their language and will be the first to develope an anime xvid build, Good!)

that's all. maybe it will produce TERRIBLE artifacts, dunno at all, didn't tested it. (you're gonna discover first,) post a word if it works
It produces many artifacts and makes ghosts in every frame, i think it's not the right solution :p

i didn't do much much animes encodes last weeks, so what do you think it's better for anime ??
EPZS ME (Koepi's builds) or PMVfast ME (uManiacs)
my opinion: i vote for PMVfast ME because it results in a better image quality and fluidity, the difference is visible, not only my tastes.
but the dark side of the medal is that the last umaniac build is near 1fps slower than koepi's one (for me not a problem, i prefer quality to speed ;) )

But please, include the koepi version of the decoder because it's very good, the umaniac's one is bad and doesn't have any option (taking the better from the two builds is a good way)

Bye, and good work!:p

[Marc FD]

Originally posted by Kaiousama
excuse me, but i don't want to give that meaning, i agree with you that many anime dvd productions doesn't have the good treatment reserved to films :(

it sounds to have all the cards to be a great xvid build, i'm very happy ^_______^ (now i have definitively to say that french people are very lucky, because he have saw many Ghibli's masterpieces in them language and will be the first to develope an anime xvid build, Good!)

funny, i do several tests on princess mononoke ;)

my opinion: i vote for PMVfast ME because it results in a better image quality and fluidity, the difference is visible, not only my tastes.
but the dark side of the medal is that the last umaniac build is near 1fps slower than koepi's one (for me not a problem, i prefer quality to speed ;) )


PMVfast is much faster than EPZS (15% faster)
but uManic's build is not optimised, and koepi used intel compilers.
i will _try_ to use them too, so it should be a _very_ fast build.
(did you test the PMVfast based build Koepi made last week ? it was hell fast, i had broke my record with XviD : 35 fps !!


But please, include the koepi version of the decoder because it's very good, the umaniac's one is bad and doesn't have any option (taking the better from the two builds a good way)


there is no problem with that : i'm not going to make a package :
it would be a _very_ experimental build, even Bframes would be actived
when it would be ready, i would attach a XviD.dll to copy over the current XviD.dll on your system. if you have Nic's Dshow decoder, you could still use it (but i prefer ffdshow to play my avis)
[B]

Bye, and good work!:p

yes, i've lots of test to do to select the better anime-spec hardcoded settings. :(

[Suikun]

Originally posted by Marc FD
if you try to reverse the logic of DCT-based (MPEG-1,2,3,4) codecs, you can't use such a codec to do it :D

some pre-processing would help, Bframes are designed for this type of movement, post-processing totally kills ring noise and some ME do slightly less ringing (like EPZS, but EPZS are a still in very early stage of developement, and are bad for inter4v ME)


As far as I know the noise around edges and in general is a result of the quantization of the DCT coefficients. The DCT itself is not lossy enough to create it.
Try encoding some (clean!) animes with quant 1 and >=2 and compare them (if possible use a TFT display, like a notebook's or flatscreen or some use some substract avisynth script) and you will see that there is not much difference between the original and the quant 1 version, but for quant 2+ it is apparant and increases with the quantizers naturally.
The use of edge detection thus is to simply introduce no or at least less noise by lowering the quantizer for a macroblock.

And btw, there is no MPEG-3 ;)

[Edit]
What do you mean with "ME noise"?

[Kaiousama]

funny, i do several tests on princess mononoke
very funny, mononoke hime is the one of two ghibli's films released in italy (we have made also an europena petition because disney doesn't want to include the japanese language track, and we have won :D ) i have the dvd and it's a very clean master for tests.
For the new version of anime-Xvid i've now ready my Akira re mastered-sbav sbav-version (the american master): this will be my war field for the HQ tests (for the LQ i haven't decided yet) :p :p :p

PMVfast is much faster than EPZS (15% faster) but uManic's build is not optimised, and koepi used intel compilers. i will _try_ to use them too, so it should be a _very_ fast build.
now i understand many things,mumble...mumble...
(did you test the PMVfast based build Koepi made last week ? it was hell fast, i had broke my record with XviD : 35 fps !!
Eh?!?! i've downloaded the 18 august version but has the EPSZ^2 ME (the last koepi version, for the umaniac i've tested the last instant build of today)
What kind of machine do you have to encode at that cosmic speed? (or what's the trick?)

there is no problem with that : i'm not going to make a package : it would be a _very_ experimental build, even Bframes would be actived when it would be ready, i would attach a XviD.dll to copy over the current XviD.dll on your system. if you have Nic's Dshow decoder, you could still use it (but i prefer ffdshow to play my avis)
If i've well understood the fdshow filter (with the options) included in Koepi binaries is from NIC, i've also ffdshow and ithink is great, but i've also seen that it (ffdshow) doesn't make a good decoding (at least as much as the xvid included decoder) and there are many more macroblocks if you keep the decoder with no postprocessing, it means that nic's dshow apply the post process starting with advantage (i don't know what the real technical trick ^_^)

[Marc FD]

Originally posted by Suikun

As far as I know the noise around edges and in general is a result of the quantization of the DCT coefficients. The DCT itself is not lossy enough to create it.


yes, of course, because DCT not lossy at all, it only a mathematical concept : depending of your floating math precision, ie with 80 bits double floating point precision, it's about 1/12089258196146291747061 % lossy ;) . but we _DO_ DCT to quantize it after, or it would be meaningless


Try encoding some (clean!) animes with quant 1 and >=2 and compare them (if possible use a TFT display, like a notebook's or flatscreen or some use some substract avisynth script) and you will see that there is not much difference between the original and the quant 1 version, but for quant 2+ it is apparant and increases with the quantizers naturally.
The use of edge detection thus is to simply introduce no or at least less noise by lowering the quantizer for a macroblock.


... do you really think i don't know that ??? ....
lowering the quantizer of the edges is _dumb_ because you would only have bigger files !! and you would only encode more noise and MPEG-2 artifacts (if you rip a DVD) if you want more "crispness" at a fixed bitrate, you would need to accept block artifacts or mosquito noise.
there is no "magic solution" even for anime.


And btw, there is no MPEG-3 ;)

yep, wrote it too fast. i meaned MPEG-1,2,4,7 (but who cares...)


[Edit]
What do you mean with "ME noise"?

last answer....
if you want to be really precise :rolleyes: : "MC noise depending of ME" instead of ME.
happy now ??




PS : I've enough of that. do you want to test my knowledge or what ??

Originally posted by Kaiousama

Eh?!?! i've downloaded the 18 august version but has the EPSZ^2 ME (the last koepi version, for the umaniac i've tested the last instant build of today)
What kind of machine do you have to encode at that cosmic speed? (or what's the trick?)


it was 08082002 if i remeber. it was with PMVfast ME because EPZS seemed buggy with lumi-masking. but now he's back to EPZS

a medium config (1.4 Ghz)
i just use avisynth+MPEG2dec+Vdub without any colorspace convertion (just YUY12(MPEG2)->YUY2->(XviD)YUY12 and it really fast)
but the size was somewhat shrinked (576x388) so i think it's totally meaningless (with a bigger size it would be much slow)
i think that's the "trick"


If i've well understood the fdshow filter (with the options) included in Koepi binaries is from NIC, i've also ffdshow and ithink is great, but i've also seen that it (ffdshow) doesn't make a good decoding (at least as much as the xvid included decoder) and there are many more macroblocks if you keep the decoder with no postprocessing, it means that nic's dshow apply the post process starting with advantage (i don't know what the real technical trick ^_^)

maybe ffdshow use too old XviD sources ... never compared them
(i use too much postprocessing... and don't have many XviD movies to view (only mine...)



i'm almost ready...
i've some tests to do with a PMVfast/EPZS mix...
and some special code to test...
and i would release a little something :)

[Suikun]

I did I no way intend to offend you or question your knowledge, sheesh -_-. If you thought of it that way, I apologize. I visit this board almost dayly (XviD devel list, too), so I know of your capabilities regarding MPEG compression and avisynth filters.

My point just was that for clean sources (clean, like no MPEG artifacts) a given amount of bits for edges are more useful than for a whole frame, if you want to accept a bigger file but you want the bits to be spend where it's most effective.

Anyway, if you don't like my idea, I don't care...
/me resumes read-only mode...

[Marc FD]

ok, i misundertood you, i apologize too.

Originally posted by Suikun
My point just was that for clean sources (clean, like no MPEG artifacts) a given amount of bits for edges are more useful than for a whole frame, if you want to accept a bigger file but you want the bits to be spend where it's most effective.


hmm, maybe i've made some shortcuts...
with h263 and thresholded coefs, you wouldn't give more bytes to edges, but you will use less bytes where there is no edges, and it gives _exactly_ the same results, but it's not done the same way. with DCT quantization, it's better to lower coeffs, because you will gain more compressibility at encoding (ie ZigZag). giving higher coeffs to edges would destroy the curve-based compression. i just think it's easier to lower size than to lower quantizers. and to lower the average quantizers after to have achieve the same quality. it's how lumi-masking works.

good night...

[kyousuke]

very interesting and very technical :)

i'll wait for this :)

but what do you in front of xvid blackout ? the project is stopped cause of this ******* sig...xxxxxxxxxx lammers..... :angry:

so i'll continue to hope.
the world isn't so bad, there're just too lamers... :angry:

++

[Belgabor]

Originally posted by Marc FD
i hope belgador would be able to use the power of this feature (because he had the almost same idea) so he could explain it to you. for me, there is nothing more to explain

Well, I think my earlier post pretty much explains why I thought it was a good idea. Well practice showed its still pretty hard to tweak it correctly, but sure this feature helps. I dont think that you'll ever get a perfect result with a noisy source (with perfect i mean all doubles detected and vice versa no non-doubles detected), but who cares if one or two slip through? Won't usually make that much of a diffrence.

Cheers (and thx for the feature :D)
Belgabor

P.S: Its Belgabor. But rejoice, you're not the first one to get it wrong ;)

[Marc FD]

Sorry. VERY BAD DAY.
I was pretty sure Sigma had used some XviD code, but i didn't suspect they stollen so wide parts.

I'm supporting the XviD team. so no release before a clear situation.

sh*t. crisis time....

[kyousuke]

oki, i agree with all of this and will wait for.

no matter they stolen small part or wide part, they broke the GNU GPL so for making profits... no others solution again us... :angry:


sig suxxxxxxxxxxx

[vidiot]

@Marc FD

...the XVid situation is bad (I´m not a Xvid user...)

but it is not so bad since you can spend some time with more of your fantastic avisynth plugins...

:D

Harald

[Marc FD]

do you realize the *sigh* _outstanding_ violation of the GNU-GPL !!!

i'll try to explain my point of view :
i could work as a devlopper in a firm, but i would not do it in my whole life. i simply would _never_ code for money. the only great think in developping is users who say things like "[...]your fantastic avisynth plugins", and other progs who help you to code.
that's why i code, and for nothing else.

now, whe are in a case where i spend lots of my time (because i'm a lamer) and achieve to code acceptable plugins/softs. I'll _naturally_ use the GNU-GPL, so the whole community can profit from my attempts to do readable and working code. without GNU-GPL, Cnr2 couldn't exist, because i was inspired by the code of Cnr1.1 for VDub, who was GPLed (and much slower)

imagine now SD want to use some prefiltering on their MPEG-4 util (VDub with a modified GUI !). to achieve the best speed and quality, the would of course choose AviSynth : hop, they ripp avs. next ? plugins of course.

they want some denoising on TV source ? a SD coder : "hey, this dumb guy named MarcFD share the source of his plugin with the GNU-GPL, let's ripp it too" and here you have SD's Rnc (Reducer on noise on chroma) inculded in a package who cost 50 $ !!!

now you understand why i'm going to shut-down my site. and if the situation isn't cleared (if SD wins), i would not code GLPed things anymore. and if i can't code GPLed things. i wouldn't code at all.

I mean, the future of freesource will depend on the issue of this.

(i personnaly don't think SD will ever ripp my plugs, because i'm a too bad coder, but i do this to support the XviD team.)

[vlad59]

@Mark

I agree it's a sad day.

But you should see that Xvid had a little victory (SD realeased their sources without talking about xvid at all).
Maybe we could have a big victory : Sigma copyright removed on some parts of the program and original xvid headers put back.

I agree it's to think that your program given freely to all could be sell by _evil_ people (when I first GPLed some Java program, I seriously feared that).
But you should always think that there is more and more Free Software addicted people. So a lot of people can always help you in such bad cases.

I will personnaly continue to release my following filter under the GPL licence.

Just my 2 € cents ;)

[vidiot]

@ Marc FD

I fully understand!
Sorry if my silly answer was misleading.

I hope not all programming was stopped now:(

But I can understand every coder not to spread the codein this situation.
Even if it´s to late for already available code pieces.

Hope they (Xvid Team and Sigma) found a solution for that pretty soon.

Kind regards

Harald

[Kaiousama]

Yeah, i agree those are black days, and i support at 100% the marcFD decision to stop the releasing untill ALL is cleared (difficult but good decision Marc).

It's a good thing to see all the comunity compact and with the same ideas, i think the situation can only be solved if there will be comunication between the Xvid staff and SD, if not, will begun one of the long term wars in wich the winner is only the SD and the losers will be all the people who spent so much time in making for free and for the others what they like

[Sigmatador]

@kyousuke
stop calling SigmaDesign sig... (look my nickname, all my friends call me sig :D:D ) hmm... say... *******Design ^^

@everybody
well I fully understand too the reaction of xvid's developper... take their work to make money (and with a very bad codec) ... shame on Sigmadesign...

[kyousuke]

@Sigmatador > ^^;
scuse, i didn't knew that all your friends calle you sig ^^; hiiii

@marc > you're right.
we must wait now ...

[midiguy]

does anyone know where I can get a readme for the copysame filter explaining the parameters? also, what exactly does this filter do? since there are some duplicate frames (specially in anime) does it just encode dup frames once and then just reuse them to save space and increase compressibility? and, it is a filter, isn't that up to the codec? please, enlighten me!

[Lefungus]

Ok, i've made a little test with the first episode of Kenshin (Anime)and copysame 1.2b plugin ( Thanks a LOT Marc ! ). I was aiming for three sessions per CD ( 230-235 Mb per session)

My avs script is :

#
Source=mpeg2source
"C:\Data\Video\FichiersVOB\Kenshin\vts_02.d2v").Telecide().crop(14,11,687,563).BicubicResize(576,432,0,0.75)


Intro=Source.Trim(0,225).TemporalSmoother(10)
Movie=Source.Trim(226,32555).Convolution3d(1,8,16,8,8,3,0)
Credits=Source.Trim(32556,35050).TemporalSmoother(10)
Endtro=Source.Trim(35051,0).Convolution3d(1,8,16,8,8,3,0)
return (Intro+Movie+Credits+Endtro).Copysame()
#


I used convolution3D ( Thanks Vlad59 !) as it removes a lot of noise without taking out (much) details.

I also used Xvid 2-pass (Koepi 18-2002-1 binaries -> Thanks Koepi and xvid team !) with modulated quantization type,Ultra high motion search precision, Min-max I-frame (2-6), Min-max P-frame (2-16). Tweaked alt. curve with perfectxivd (Medium,High 682,Low 99) (Thanks Unplugged !)

As i downloaded copysame plugin in this thread, i got no readme.txt so i use defaults. Maybe some improvements could be achieved by tweaking parameters.


Nevertheless I'm VERY pleased with the final output. Copysame seems to perform very well. I think there is a lot of potential there for anime. And as you've already said , it should be much better with frame-drop enabled into Xvid. Be sure i'll test your customised xvid version when Sigma issue will be resolved.

Ps : I know my english is bad :D

[vidiot]

@ MarcFD:
I had some trouble using your CNR2 with your copysame filter:

for example:
Avisource ...... (picvideosource 448 x 544)
telecide()
CNR2()
copysame

...won´t work (caught an access violation at 0x08c513c2,
attempting to read from 0xffffffff ) in VD!

without CNR2 it works well.

- the same goes with 2DcleanerYuv
(which is maybe violationg GPL, read: http://members.tripod.co.jp/kiraru2002/)

- it depends on what filter comes first:
2DCleanerYuV before CNR2 worked,
after doesn´t work...

Any idea´s?

kind regards

Harald

[bill_baroud]

just in case, try to put a ConvertToYUY2() after AviSource to be sure that you are in this color mode.

for example with MS-MPEG4 i'm not in this mode (RGB i think) , so i need to convert, perhaps it's the same for you with mjpeg (picvideo right ?)

dunno if i have something wrong in my config , but it's the way it is.

[vidiot]

thank you bill_baroud,

i wasn´t sure either, so I´ll look at the file information in VD which said YUV - so color space doe´sn´t seem to be the problem.

It looks like CNR2 doesn´t like some of the other filters....
:confused:


Harald

[arckange]

first : sorry for my english

2nd : i have make a lot of test of copysame with pal dvd and
i've alway a bad result with hashing in travelling but i've not this
pb with ntsc dvd. this result has been checked whith other people.
Do you know what happen ?

thank a lot for your work

[vidiot]

:sly: Now it starts getting weird:

If I put temporal soften 2 inbetween my script
copysame works like a charm:

Avisource ...... (picvideosource 448 x 544)
telecide()
CNR2()
copysame()
won´t still work

Avisource ...... (picvideosource 448 x 544)
telecide()
CNR2()
TemporalSoften2(2,6,8)
copysame()

works like a charm...


...i´m curious if anybody else has got such a problem!?

Harald

[Marc FD]

hi, i'm back from holidays...

mmh, weird bug here. could be due to CopySame 1.2 or 1.1 or from Cnr2 or from both....
it's a acces violation, right ??

[vidiot]

Originally posted by Marc FD
hi, i'm back from holidays...

mmh, weird bug here. could be due to CopySame 1.2 or 1.1 or from Cnr2 or from both....
it's a acces violation, right ??

Yes, absoluteley right!
Hope you can fix it.

kind regards
Harald

[Marc FD]

test with a Trim(10,0) just after the source.
are you sure to have mod4 res ?
try Crop(8,8,-8,-8) too.

[Guest]

Marc,

Your web site seems to be down. Is there an alternative URL? Thank you.

[Marc FD]

I've updated my site now.

@All
If Koepi release new binaries, i think i can continue to work on my anime-spec XviD build :devil:

[Kaiousama]

@marc

Happy to have you back :)

[Wilbert]

@marc,

I wanted to do a second test-round, but I'm unable to download the newest MAM (it says page not found ...)?

[Marc FD]

i need to update MAM.
i would do it sooner or later.
i know the link is broken.
it's corrected on my HDD, i just need to upload it ;)

[JasonFly]

I haven't test copysame yet but I would have some information before

Can we use this filter with divx3.11 or not?

Dropping frames could cause desynch between video and audio?

Is the gain very important we other things that are not anime?

Thank you very much Marc FD you do a great job with all these filters!

[Marc FD]

Can we use this filter with divx3.11 or not?


why not ? of course you can !


Dropping frames could cause desynch between video and audio?


it's not dropping frames : it's copying them = no desynch.


Is the gain very important we other things that are not anime?


the gain is never "very important" if you want 100% quality.
and it's designed _for_ anime. (for HQ result i mean)

if you use it on movies, you will have hashing in slow-motion scenes like RV9 does at low bitrates.

if you want to highly compress something, and can suffer some hashing, maybe it could help.

i never tested it on movies. test yourself and you'll see ;)

[vidiot]

Originally posted by Marc FD
test with a Trim(10,0) just after the source.
are you sure to have mod4 res ?
try Crop(8,8,-8,-8) too.

Marc FD,

The above mentioned didn´t help.
Only activating of Temporal Smoother or Temporal soften will help.
"Every" (has to be proven) filter works after TS but nearly none does work immidiatley after CNR2 - maybe a buffer/cache problem?

But not only with your "CS-engine":
The 2DCleanerYUV2 will although work after TS or BEFORE CNR2 (but I think after will be better...)

...and yes: Source is mod4 res (448 x 544).

And please: Could you be so kind to put some more effort into your documentation? I´m not a programmer and have difficulties to use your fine tools like they should be used.
:confused:

Thanx

Harald

[JasonFly]

Does debugview analyser detect z frmes.
Because I encoded a movie but I didnt detect any drop frame.

There should have be at least one or two coppied frames.
Maybe I haven't put the filter at the right place.(I have placed it at the end of the file:is it that?)

Here is my avs:

LoadPlugin("C:\Video\Encoder\GORDIA~1.26\mpeg2dec.dll")
LoadPlugin("C:\Video\Encoder\GORDIA~1.26\CopySame.dll")

Source=mpeg2source("D:\DVD\asterix.d2v").crop(3,72,714,432)
Movie=Trim(Source,0,147044).BicubicResize(576,240,0,0.5)
Credits=Trim(Source,147045,155362).TemporalSmoother(2).BilinearResize(576,240)

Return Movie+Credits

CopySame(1,4,8,4,0.1,987654321,50,50,3)

[Didée]

@JasonFly

Return(XXX)
Filter(something)

-> The argument of "Return" is what is put out. Everything after "Return" is just making your AVS bigger, but doesn´t do anything.

[Marc FD]

THERE IS NO DROPPING !!!!!

@vidiot
i will try to reproduce this error.

[Defiler]

This is what you're looking for:

LoadPlugin("C:\Video\Encoder\GORDIA~1.26\mpeg2dec.dll")
LoadPlugin("C:\Video\Encoder\GORDIA~1.26\CopySame.dll")

Source=mpeg2source("D:\DVD\asterix.d2v").crop(3,72,714,432).CopySame(1,4,8,4,0.1,987654321,50,50,3)
Movie=Trim(Source,0,147044).BicubicResize(576,240,0,0.5)
Credits=Trim(Source,147045,155362).TemporalSmoother(2).BilinearResize(576,240)

Return Movie+Credits

[JasonFly]

Yes I have already done that and that work fine.
Thak you

[JasonFly]

Debug analyser reports me a wrong frame number.
Is that mean that "non counted" frame are frames which are copied?

[Marc FD]

tu deviens lourd la....
considère CopySame comme un _très_ puissant TemoralSoften actif seulement quand il detecte des images identiques. le nombre de frames reste _exactement_ le même !!! compris ??

[JasonFly]

C'est bon j'ai compris, je suis pas con.
Seulement Debug analyser ne me donne un nombre de frame I+B frame différent que ce qu'il devrait etre, c'est tout.Ma question c'etait de savoir d'où pouvait venir cette erreur.

C'est vrai que le frame rate reste le meme mais sur un film quand les personnages parle et que le reste bouge pas eh bien ca donne l'impression d'une video un peu saccadé.

[kyousuke]

putain cé marqué ds la doc qd meme ^^

marco, about your xvid mod for animes, the project is always ok ?

+

[Marc FD]

i think i could put something out this WE. if i have time ;)

BTW, i think developement in XviD will speed up with the API 3.0

[soujir0u]

Hi, I have tried using CopySame together with Convolution3d. However, when I use copysame before convolution3d, it gives Avisynth write error. If I use copysame after convolution3d, then everything is OK. Actually, which one should be the better method? And I use the default values for copysame (I'm encoding anime), is that OK? Thanks for you help.

[Marc FD]

In fact, if i were you, i wouldn't use copysame 1.1 or 1.2 yet.
there is know bugs and the engine is not perfect.
i'm currently in R&D stage for CopySame v2.0
I've tested many algos for the engine and i'm coming to the solution.
a complex mix of differents search modes for each specific problematic case to reach 99.999% of accuracy.

In need to implement and test each search mode separatly (i've currently 1/3 ready)
Then i would merge the whole stuff, test and debug it a lot, and do a beta release.

It's going to take some time, so if you want to use CopySame, i would suggest you to :
- Use CopySame 1.2 !!! (neuron2 said it was much better than 1.1)
- Test and Tweak.
If the results are good for your stuff, you can use CopySame. I didn't say it was bad. I said it's going to be better.

Back to work :devil:

[Defiler]

I'll be standing by, ready to test any future beta versions. :)