MVTools

[Didée]

Originally Posted by Fizick

... chroma tint (no thanks to Didee due to lack of official bugreport in MVTools forum thread

Sorry to contradict you, but I DID report that chroma issue: lookathis.
(Though, admittedly, the discussion ended without a real ending.)

Thank you very much for finally fixing it!


While I'm at it, thanks also for MVRecalculate. It works pretty much like what I had in mind.
The embarassing news: Without MVRecalculate, I used some sloppy calculation. With MVRecalculate, the calculation is much more exact. Compairing both, it seems the sloppy one gives more pleasing results than the accurate one ... ouch!
BTW, the point is to mix different blocksizes. Asked for two years ago, and now that i script it, you start to implement it ... funny. :-)

[Fizick]

Didée, you have wonderful memory, but you was not very hard in the bug report
BTW, I am not sure, that I am fixed all rounding errors. What I fixed was in degrain functions, not dependent on overlap, and do not very dependent on pel.
It is not coinside with your observations...

MVRecalculate is experimental. But I have no much time for experiments...

[Nikos]

Thanks Fizick for the new stable version.
If i want to use external subpixel interpolation clip and prefiltered clip, the below code is correct?

s = last
pre = s.mydenoise()

up_s = s.EEDI2(field=1).LanczosResize(2*width(s), 2*height(s), src_left=0.25)
up_pre = pre.EEDI2(field=1).LanczosResize(2*width(pre), 2*height(pre), src_left=0.25)


b1v = pre.MVAnalyse(isb=true, delta= 1, blksize=8, pel=2, sharp=2, pelclip=up_pre, idx=1)
f1v = pre.MVAnalyse(isb=false, delta= 1, blksize=8, pel=2, sharp=2, pelclip=up_pre, idx=1)

den = s.MVDegrain1(b1v, f1v, thSAD=350, pelclip=up_s, idx=2)

cb1 = s.MVCompensate(b1v, thSAD=400, pelclip=up_s, idx=2)
cf1 = s.MVCompensate(f1v, thSAD=400, pelclip=up_s, idx=2)

pmax = s.mt_logic(cb1, "max").mt_logic(cf1, "max")
pmin = s.mt_logic(cb1, "min").mt_logic(cf1, "min")

sharp= s.mysharpen()
sharp.mt_clamp(pmax, pmin, 0, 0, U=2, V=2)

[Leak]

Originally Posted by Fizick

Is stl maps open source? What it doing?

Definition of Standard Template Library
STL Maps Documentation

An implementation of the STL comes with about any C++ compiler, be it MSVC, Intel's compiler or G++.

np: Landesvatter - Fläz. (Lax)

[Didée]

Originally Posted by Fizick

Didée, you have wonderful memory, but you was not very hard in the bug report

Yeah, it's a lame excuse ... but it's the best that I have.


@ Nikos: From my point of view, that's spot-on correct. 'pelclip' is (should be) fix-correlated to 'idx' ... in easy words: "existing idx, existing pelclip ... new idx, new pelclip". If that isn't the case, then it's a bug.

[Nikos]

Thanks Didée for the answer. The idx's alone is a little confusion, the idx's with peclip's are big headache!!!

With new MVtools i think we need a small modification in TempGaussMC beta-1

## MVDegrain causes a chroma shift (yes it does, with pel>1 !)  We compensate by shifting chroma towards plain EDI by a small notch 
##   [ 1+(x-1)/(1+(x/5)^4) ] on 128-centered diff-clip (x-y) ==>  [ x y - abs 2 < y x x y - abs 1 - 1 x y - abs 5 / 4 ^ + / 1 + x y - x y - abs 0.0001 + / * + ? ]
stage2 = stage2.mt_lutxy(edi,"x y - abs 2 < y x x y - abs 1 - 1 x y - abs 5 / 4 ^ + / 1 + x y - x y - abs 0.0001 + / * - ?",Y=2,U=3,V=3)

[josey_wells]

Originally Posted by Fizick

josey_wells,
See PlaneOfBlock.cpp for LSAD and FakeGroupOfPlakes for nOverlapX (around digits 1.10.2).
Changes are commented in code and as minimal as needed.
It makes clear tracking and delimits responsibility.

Thanks I have rolled this update as well as the rounding update into the latest build.

Originally Posted by Fizick

As IanB noted, it would be fine, if you not simply public a huge DIFF, but mark (by approriate comment in code) all needed changes and revert all unneeded changes.
I say about i++ to ++i replacing, BitBlt to PlaneCopy renaming, and other similar things.

I'm sorry but at this point it doesn't make much sense to do this since so many structural changes have taken place.

Originally Posted by Fizick

Well, you have rewritten the entire queueing mechanism to use stl maps.
Sorry, I do not know nothing about stl maps. The only language I ever was learned was FORTRAN IV in university . Is stl maps open source? What it doing?
How much memory usage is decreased in result?

Leak already answered that STL is the Standard Template Library. I was able to get rid of two classes and embed everything in MVCore.

Originally Posted by Nikos

Thanks Fizick for the new stable version.

I am hoping that this was not a slight against the version that I have been working on.

This version also contains a new thSADC parameter for MVCompensate, MFlowIter, MVFlowFPS, MVFlowFPS2. Although currently both SAD parameters are ignored in the MVFlowXXX.

Before posting the source code, I want to try something to possibly improve the MVDegrain results. Currently the total SAD is used to find the motion vectors and then the total SAD is again used to weight the Luma and Chroma planes in MVDegrain. I would like to change the MVAnalyseXXX function to store the total SAD and the SAD's for each Luma and Chroma plane in the vector data. Then use the SAD for each plane to degrain that plane instead of the total SAD.

Here it is

http://rapidshare.com/files/14089552...9.7.2.rar.html

[Nikos]

@ josey_wells my comment was not a slight against your version, on the contrary i appreciate your work.
The bold letters was just for distinction from your version who is in alpha stage.
With your hard work i think very soon will be stable for every day usage

[LaTo]

@ josey_wells : thanks for your hard work on MT version

But, I have a feature request: can you make multithreaded version for MVCompensate & MVMask ???

Like this:

OLD

b1v=last.MVanalyse(isb=true,delta=1)
b2v=last.MVanalyse(isb=true,delta=2)
b3v=last.MVanalyse(isb=true,delta=3)
f1v=last.MVanalyse(isb=false,delta=1)
f2v=last.MVanalyse(isb=false,delta=2)
f3v=last.MVanalyse(isb=false,delta=3)

b1c=last.MVcompensate(b1v)
b2c=last.MVcompensate(b2v)
b3c=last.MVcompensate(b3v)
f1c=last.MVcompensate(f1v)
f2c=last.MVcompensate(f2v)
f3c=last.MVcompensate(f3v)
comp=interleave(b1c,b2c,b3c,f1c,f2c,f3c)

NEW

vectors = last.MVanalyseMulti(refframes=3)
comp    = last.MVcompensateMulti(vectors)

With the same way as MVanalyseMulti (one thread for each compensated frame).
Idem for MVmask.

It would be great

[krieger2005]

Why you need a MultiCompensate? In the next step you must extract every compenstated part again (for interleave). And then you have the same as like it is now. Sorry, don't see the point yet.

[LaTo]

Originally Posted by krieger2005

Why you need a MultiCompensate? In the next step you must extract every compenstated part again (for interleave). And then you have the same as like it is now. Sorry, don't see the point yet.

Because the old method is not multithreaded... (the interleave will be part of MultiCompensate and after use selectevery)

[krieger2005]

Oh... I forget always the thread-thingy..

[josey_wells]

OK, here is version 1.9.7.3

http://rapidshare.com/files/14104839...9.7.3.rar.html

This has all the builds in it and I believe I have fixed the problem with the IC10 builds also.

This also has the modification of of calculating the SadLuma, SadChromaU, SadChromaV and carrying that information through the vector data.

I also added a SadMode to MVDegrainXXX

SadMode=0 - Works as old method
SadMode=1 - Works with new method which may or may not be better

                    switch(pTS->pMVDegrainBase->SadMode) {
                    case 0: // total SAD
                        if (bLumaY)   pPS->WRefF_Y[i] = std::max<int>(0, pTS->pMVDegrainBase->thSAD  - blockF.GetSAD());
                        if (bChromaU) pPS->WRefF_U[i] = std::max<int>(0, pTS->pMVDegrainBase->thSADC - blockF.GetSAD());
                        if (bChromaV) pPS->WRefF_V[i] = std::max<int>(0, pTS->pMVDegrainBase->thSADC - blockF.GetSAD());
                        break;
                    case 1: // Individual SAD's
                        if (bLumaY)   pPS->WRefF_Y[i] = std::max<int>(0, pTS->pMVDegrainBase->thSAD  - blockF.GetSADLuma());
                        if (bChromaU) pPS->WRefF_U[i] = std::max<int>(0, pTS->pMVDegrainBase->thSADC - blockF.GetSADChromaU());
                        if (bChromaV) pPS->WRefF_V[i] = std::max<int>(0, pTS->pMVDegrainBase->thSADC - blockF.GetSADChromaV());
                        break;
                    }

This should be a stable build. Please report back either way and if new method is useful or not.

[Fizick]

josey_wells,

1. So, stl maps is internal (hidden), and license terms of stl maps is GPL-compatible?

2. Well, I see that you do not want revert the changes.
But you should mark all changes by notices even if (and especially if) changes are big.
BTW, there are also GPL terms about "prominent notices".
(Why you do not use (updated) mvtools.rc? )

3. I am not sure, that SAD's for each Luma and Chroma plane may be use useful,
but if you changed the motion data format (or MVAnalyseData structure), then you must at least increment MVANALYSIS_DATA_VERSION.
Previously I could load motion data clip of v1.9.6-1.9.7 to MVShow v.1.10.1 due to same (compatible) data format.

[mikeytown2]

@ josey_wells
1.9.7.3 still has some issues
Using this same test MSVC08 has smeared/blurred output. IC10 bombs in AvsP and it only has blurred output in Vdub.

TempGaussMC()/MCBob() works in AvsP with both versions and it looks ok.

[Manao]

Fizick : use stlport to get a full portable stl implementation.
Fizick, josey_wells : if you keep developing together, take some time to find a svn/cvs/git server, in the long run it'll help you.

[josey_wells]

Originally Posted by mikeytown2

@ josey_wells
1.9.7.3 still has some issues
Using this same test MSVC08 has smeared/blurred output. IC10 bombs in AvsP and it only has blurred output in Vdub.

TempGaussMC()/MCBob() works in AvsP with both versions and it looks ok.

I missed the ExtraDivide function when changing the data output so anything with divide!=0 would be in error. It has been corrected.

I have also fixed rounding errors in several placed.

Here is the MSVC08-SSE2 only version for now.

http://rapidshare.com/files/14114630...9.7.4.rar.html

[Delerue]

Originally Posted by josey_wells

I have also fixed rounding errors in several placed.

Here is the MSVC08-SSE2 only version for now.

http://rapidshare.com/files/14114630...9.7.4.rar.html

Thanks, but MVFlowFPS performance is almost 50% slower than Fzick's last version, and it can't work well with Avisynth MT. Any idea?

[Adub]

How are you calling it?

[josey_wells]

Originally Posted by Fizick

josey_wells,

1. So, stl maps is internal (hidden), and license terms of stl maps is GPL-compatible?

2. Well, I see that you do not want revert the changes.
But you should mark all changes by notices even if (and especially if) changes are big.
BTW, there are also GPL terms about "prominent notices".
(Why you do not use (updated) mvtools.rc? )

3. I am not sure, that SAD's for each Luma and Chroma plane may be use useful,
but if you changed the motion data format (or MVAnalyseData structure), then you must at least increment MVANALYSIS_DATA_VERSION.
Previously I could load motion data clip of v1.9.6-1.9.7 to MVShow v.1.10.1 due to same (compatible) data format.

1. STL is part of the C++ standard is freely distributible in compiled executables.

2. I could possibly do that once everything stabilizes if I have time. I have been lazy updating the rc file each time.

3. I'm not sure it is useful either. Just thought to give it a try it does seem to give a lower PSNR than the old method. I only changed the vector data not the Analysis structure. It might be better to code a flag to choose old or new structure?

Here are all the builds and the source.

http://rapidshare.com/files/14116526...4_All.rar.html