home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / compress / 4179 < prev    next >
Encoding:
Internet Message Format  |  1992-12-20  |  3.5 KB

  1. Path: sparky!uunet!usc!usc!not-for-mail
  2. From: haddadi@sipi.usc.edu (Navid Haddadi)
  3. Newsgroups: comp.compression
  4. Subject: Re: Motion Compensation?
  5. Date: 18 Dec 1992 02:39:40 -0800
  6. Organization: University of Southern California, Los Angeles, CA
  7. Lines: 51
  8. Sender: haddadi@sipi.usc.edu
  9. Message-ID: <1gs9pcINNl4l@sipi.usc.edu>
  10. References: <1992Dec14.161316.38402@ns1.cc.lehigh.edu> <1gkkjfINN7c6@sipi.usc.edu> <1992Dec18.003748.17601@cs.wayne.edu>
  11. NNTP-Posting-Host: sipi.usc.edu
  12.  
  13. In article <1992Dec18.003748.17601@cs.wayne.edu> bhh@isis.cs.wayne.edu (Bhaskar Holur) writes:
  14. >Well, you did not mention the method of motion compensation used
  15. >in MPEG Video Compression Standard. Although the MPEG does not specify
  16. >any particular method for it, the main idea is block-based
  17. >motion compensation.  The method is to search for  a best matching
  18. >block in the reference frame within a predetermined search area (depending
  19. >on the speed and type of motion in the frames) around the point
  20. >corresponding to the target block in the current frame. The cost function
  21. >or the matching function can be any one of : Mean Absolute Difference,
  22. >MSE, or a correlation function, etc. There are fast search procedures
  23. >to idendify the match in the search area, like the 3-step procedure.
  24. >
  25. >Note: for block based motion compensation, the frame is divided into
  26. >non-overlapping square blocks of size 16x16 or application specific
  27. >size.
  28. >
  29. >--Bascar
  30. >bhh@cs.wayne.edu
  31.  
  32. True. However, the concept of block matching (not the computation)
  33. is so tivial that there is not much to be said about it 
  34. (although, some variations such as Anandon's work is by no means trivial).
  35. If the size of image is 512x512 then it can be subsampled 16:1 to
  36. create 32x32 images from which an optical flow can be computed in a fraction
  37. of time required to perform block matching at 512x512 resolution. If one
  38. is willing to tollerate a higher computational cost, then multiresolution
  39. computation of optical flow based on Gradient Constraint Equation
  40. (with appropriate constraints) provides a very reliable measure of motion
  41. (even for 16x16 blocks) which minimizes prediction error (one-step in case
  42. of two images) in a non-trivial way. Block matching methods whick seek
  43. to minimize a measure of local error (such as sum-of-squared differences),
  44. on the other hand, are too "greedy" in their search for an optimal solution.
  45. In fact, block matching methods are only one way of computing the optical flow
  46. (after all B.M. methods are also based on preservation of intensity). 
  47. Token matching, Contour based matching (Hildreth, Butox, Waxman), 
  48. spatio-temporal-frequency (Heeger) and phase (Fleet and Jepson) methods 
  49. as well as the gradient based methods are among the more sophisticated
  50. (both computationally and theoretically) methods of
  51. estimation motion (This is of course my opinion). Correlation techniques
  52. (such as Anandon's pyramid skim) can be made competitive at higher
  53. computational cost when the first and second curvatures of the images are 
  54. used to resolve conflicts in match probability. However, The true power of 
  55. motionfield is that it computes motion of each pixel. If we find an 
  56. efficient method of coding the resulting flow field, then we would almost 
  57. certainly achieve much better compression than is possible with the protocols
  58. of the MPGE's fixed block structure. We need a protocol in which different
  59. block sizes can be used in the same frame. Here at SIPI (Signal and 
  60. Image Processing Inst. at USC), we are currently working on such problems. 
  61.  
  62. Navid,
  63. haddadi@sipi.usc.edu
  64.