Dup 2.0 for Avisynth 2.5

[MaTTeR]

@FuPP

Thx for the reply. My experience is also exactly as you describe, just wanted to verify it.

[Ewi]

@neuron2

is it possible to let Dup write a log file which frames are replaced so you can easily check with vdub if there are frames that should not be replaced (for example the described situation with a guy walking far away)...

Thank you...

[Guest]

Originally posted by Ewi
is it possible to let Dup write a log file which frames are replaced so you can easily check with vdub if there are frames that should not be replaced (for example the described situation with a guy walking far away)

Just set debug=true and the needed information will be visible through the DebugView utility (available at my web site). Then use the logging capabilities of the DebugView utility if you want to capture the output to a file.

[Ewi]

@neuron2

Ohhh, Ok thank you.

What about this idea:

I don't know exactly how Dup is working but I as far as I know it's working on whole frame and if two (or more) frames have a difference less than a threshold the second frame is replaced by frame 1 (except for blend...). But in anime there are often parts of the picture that don't move (for example a person speaking and only its mouth is changing).

So what is about partly "dupping" the frame. A simple way would be to divide the picture in submatrices, f.e. 3x5 or more, and use dup on each of them. A more complex method could require to detect motion, chroma and lumi changes and to mask the parts of the frame that are under a given threshold of a weight function f(motion[atPixel],chromachange[atPixel],lumichange[atPixel]), and then dup or blend-dup only these parts.

Both of this would allow to go lower with the threshold values that have to be actually used and so perhaps our man on the horizon is walking again with a gain in compression in his pocket....

Thank you...

P.S.: If Dup is working in this or a better way: don't hate me for asking silly questions....

[Guest]

@Ewi

Thank you for your suggestion. The idea was already suggested on the main Dup thread. Search for "New duplicate detection filter". I am considering it but fear that it may fragment motion in an ugly way.

@all

I have released Dup 2.00, the first release version. It has several robustness fixes versus the last beta, and fixes a bug such that the blended frame wasn't used when show=true. It's a good idea for all Dup users to get this version. Please get it from my web site (the Avisynth 2.5 version). The source code is also available there.

Thank you all for your valuable feedback during development.

[Marc FD]

lol, it'ld be a temporalsmoother ^^

>Now even MarcFD can't argue that Dup is useless.

i still argue it's useless.
your work is great, as always, don, it's all the fault of the dumb guy who had the idea ^_^.

are you still using the same algo to detect movement, by searching the biggest mean difference in 32x32 windows ?

because i've a new filter, with a similar approach, and i'd like to know the drawbacks ^^

[Guest]

Originally posted by Marc FD
are you still using the same algo to detect movement, by searching the biggest mean difference in 32x32 windows?

Yes.

because i've a new filter, with a similar approach, and i'd like to know the drawbacks ^^

Can't say without knowing the purpose of your filter.

[Marc FD]

>Can't say without knowing the purpose of your filter.
just a temporal smoother more ^^.

[Guest]

Originally posted by Marc FD
just a temporal smoother more ^^.

Your statement is too brief and cryptic to understand.

Do you mean block-based conditional copying/blending as suggested by Ewi and others?

[Marc FD]

sorry don.

okay, let's go technical

pixel-based 5x5 (or more) interleaved diff with inloop affine (based on the accumulation of 5x5 diffs) blending.

[sh0dan]

@neuron: If you're interested, I've written a very fast ISSE routine that returns the largest accumulated sum of differences of a 32x32 pixel area on the entire image.

It processes 16 pixels in parallel, with less than 1 cycle per pixel, so it's probably maxed out at memory speed. It'll be committed to avisynth now, but it's not activated, because I'd like to reference test it, so it would be great if you could help there.

It might actually not be useful for what I'm doing, but it's just an experiment.

cvs sourceforge link see int TemporalSoften::isse_scenechange(const BYTE* c_plane, const BYTE* tplane, int height, int width, int pitch)

[Guest]

@sh0dan

Thank you for the offer and link. I need the function to return the x and y coordinates of the block so that I can display the little box when show=true. Any chance of that?

[sh0dan]

Not entirely impossible - I can send you an offset x + (y*width/32) that should be enough. Pure luck I still have an mmx register, but I may need two to avoid memory reads, or stalls.

edit: cr*p I didn't have an mmx-register - not even a general purpose register. Couldn't you use the C-code, when show is true? I assume the C-code does exatly the same, so if you test the results, and see if they are the same, it would be pretty safe to use it.
It could added to the code, but in real life there isn't anything time-critical, when show=true (ie. it's not an encode).

Edit2: Wouldn't it make more sense, for it to be used as scene-change detector to add all the differences together and simply threshold-test this value.

Edit 3: Just saw, that the code assumes that the pitch of both images is the same - not a good thing. I'll correct it.

[Guest]

Couldn't you use the C-code, when show is true? I assume the C-code does exatly the same, so if you test the results, and see if they are the same, it would be pretty safe to use it.
It could added to the code, but in real life there isn't anything time-critical, when show=true (ie. it's not an encode).

Yes. That would be acceptable.

Wouldn't it make more sense, for it to be used as scene-change detector to add all the differences together and simply threshold-test this value.

Yes, of course. That application is very different from a duplicate detector.

Just saw, that the code assumes that the pitch of both images is the same - not a good thing. I'll correct it.

If you fix that I can give it a try.

Thank you.

[esby]

Good thing,
both protagonists are here ^^ (see below...)

This code giving me avisynth error...

It seems linked to cnr2() and dup() [edit : Cnr2 and not Dnr2, sorry for the typo ]

I put the whole script cause it could come from other plugins used...

source = avisource("...").killaudio()
source = source.SwapUV()

#used to correct somes frames before decomb fails on them...
#note : frames 36 and 37 are KF but frame 36 is just baaaaad (mixing of 35 & 37)
dest = source
dest = dest.freezeFrame(36,37,37)
#(...) some freezeframes too
dest = dest.freezeFrame(36249,36250,36250)
source = dest

#ivcting cause raw is 29.76 fps (anime)
Source = source.Telecide(chroma=true,dthreshold=13)
source = source.Decimate(cycle=5,show=false,mode=2) 

#cropping evil baaaaad bar & resizing
source = source.crop(0,2,628,478)
source = source.BiLinearResize(640,480)

#one of the two plugin alone works
#but both together just won't work 
source = source.Cnr2("xxx",6,7,255) 
source = source.dup()

#just to check the 1000 first frames in nandub ( or vdub)
return source.trim(0,1000)

When i put
dup() before cnr2()
or cnr2() before dup()
...I m getting an "avisynth read error : AviSynth caught an access violation at 0x01651c17, attempting to write frame 0x00000000..."

Any idea why, or how to avoid it, (I tried moving it before ivtc etc.,
but i haven't found a way to do not crash avisynth actually.)
of course i can do cnr in vdub... But that just mean that cnr2 avs is useless for me in this case


Versions I am using:

AViSynth: 2.50 beta 22 jan. 2003
Decomb: Version 4.06
Dup: 2.00 ( took from the realm of Mordor )
Cnr2: Chroma Noise Reducer for AviSynth (v2.4)

esby

[Guest]

@esby

You say dnr2() in one place and cnr2() in another. I assume you mean cnr2().

I put Dup() first in the script followed by a debug build of Cnr2(). It crashes in Cnr2():

PVideoFrame __stdcall Cnr2::GetFrame(int n, IScriptEnvironment* env) 
{
  if (n<1) return child->GetFrame(n, env);

  PVideoFrame src = child->GetFrame(n, env);

  if (lastn+1!=n || !pre) {
    pre = child->GetFrame(n-1, env);   // CRASHES HERE !!!
    env->MakeWritable(&pre);
  }

  const uc *srcp = src->GetReadPtr();
  uc *prep = pre->GetWritePtr();
...

It crashes in the Avisynth core on the marked GetFrame() call when stepping from frame 0 to frame 1. I verified that n-1 is 0 at this call.

So it appears to be a bug in the Avisynth core, maybe the cache. We need to get sh0dan involved. I will PM him to draw his attention to this thread.

[sh0dan]

Couldn't it just be CNR2 crashing?

It has been known to do that.


(but I'll look at it ASAP)

[esby]

It's possible,
But as far i remember cnr2 alone or dup2 alone worked for the first frame processed.
And both crashed together.
I think i ended removing both, not satisfacted of the final result.
(prolly cause dup blending mode not really good with some 'decombed' frames)

esby

[Guest]

@sh0dan

I traced through Cnr's code and it crashes on the simple GetFrame() call for frame 0. I don't know how you can blame Cnr2. But by all means if you can think of a mechanism let me know and I'll look some more at it. Thank you.

[sh0dan]

@neuron: Sorry - I thought you were listing the Dup-code (thus the crash would be in CNR2's GetFrame). I'll do a testsetup, and hopefully find it.