On Wed, 2005-06-22 at 09:08 +1200, E.Chalaron wrote: > > y4mstabilizer works best with 444 progressive material. > > I am working in 422 progressive. At least its closer than 420 interlaced
The smaller the pixels, the smoother the motion will be. In 422, the horizontal jumps will be 2 pixels at a time. The conversion to 444 (and back) should not be very lossy. Of course, if it works OK, then so much the better... You are working with fairly large frames - correct? The motion will be smoother if you call the stabilizer before downsampling to DVD resolutions. Also, your jitter is all vertical, and 422 data has a vertical stride of one, so vertical adjustments should be smooth. > > Hmmm... You have given the jitter *amplitude* (12 pixels) but not the > > jitter *frequency* (how often they occur) or duty cycle (how much of > > the time is the image shifted). > > True, it does happen every 2 or 3 frames. > > > How long do the jitters last? > > 80 % of the movie reel, which makes about 15 minutes ... > > > Are they only a frame or two? or do they > > last several seconds? Best results occur if the input shift is of short > > duration, and quickly moves back to the original position. > > Ok let's say that every 2 or 3 frames it comes back to its original position. > How could I say that ... the amplitude is only one way (down, never up) Ahhh... So it seems that you have a bimodal (almost square wave) movement. The current y4mstabilizer was designed for smoother movements. Steve Schultz and I have been discussing your problem (it helps when he sits three cubicles away at work). One approach would be to recognize that the movement is not always smooth and continuous, and to treat exceptionally large motions (above a threshold) as outliers that must be corrected, but not necessarily used to adjust the accumulated global motion vector. In other words, I could correct the jitter without slewing the picture. A refinement would be to recognize jitter as a departure from smooth 2nd order (acceleration) motion vector changes. In other words, if you slew the camera, you seldom go directly from 0 motion to 20 or 30 pixel differences in a single frame. You tend to smoothly accelerate the slewing over the course of several frames. Jitter would show up as a global motion vector that differs from the previous motion vector by an amount greater than a given threshold. If you could get me 20 or 30 seconds of y4m data to test with, I think I could drum up some free time over the next week or two to get you something that might solve this problem. -- J Macropol <[EMAIL PROTECTED]> ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
