On Wed, Apr 13, 2016 at 07:24:42PM +0000, Davinder Singh wrote: > good vectors? how can i improve them? since it search for every possible > place, it should give best match. can you give more details, why > surrounding vectors need to be considered?
the goal is to find the true motion that is how the physical object moves, the best match pixel by pixel may not represent the true motion at all for example a block that contains a finely detailed high contrast object and that matches with a low difference to only one spot in the new image would likely represent a good/true motion vector a block that contains a sharp straight line and that matches well would likely be accurate in the direction normal to the line but may be somewhat inaccurate in the direction along the line a block containing nearly flat constant color will quite possibly match somewhere best that is very far from the true motion and blocks that on another frame move off screen or behind other objects will also match best somewhere pixel by pixel but wherever they will match it will not be the true motions direction whats needed is to have the "strong/good" matching vectors pull any surrounding weak ones towards themselfs in some form. Researching algorithms/papers that attempt to find true motion well and robustly, may be needed. Its liklely theres some existing research and experiments in that area. Of course we will have to experiment too but there should be some existing stuff Its important to note though that this problem differs from motion estimation used in video encoding. But the methods used in video encoding still should perform much better than "flat" independant exhaustive search (they are also MUCH faster) For encoder targeted ME there is UMH and the older EPZS i dont know what algorithm is good for finding true motion but the encoder targeted ones at least have a term that minimizes vector differnces (as there is cost in a encoder to store the difference from the predicted) > > also i tried to compare it with export_mvs, they seems quite similar. > the export_mvs ones, sometimes use multiple vectors at for certain blocks. > > > DSM_ > > On Tue, Apr 12, 2016 at 5:44 AM Michael Niedermayer <mich...@niedermayer.cc> > wrote: > > > On Sat, Apr 09, 2016 at 11:50:07PM +0000, Davinder Singh wrote: > > > ok, applied the changes. with new closest vector condition. will add > > > threshold now. > > > > it may be beyond the scope of this qualification task but to get > > good quality vectors the surrounding vectors will have to be > > considered in choosing each vector > > > > [...] > > > > -- > > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > > > The bravest are surely those who have the clearest vision > > of what is before them, glory and danger alike, and yet > > notwithstanding go out to meet it. -- Thucydides > > _______________________________________________ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If a bugfix only changes things apparently unrelated to the bug with no further explanation, that is a good sign that the bugfix is wrong.
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel