3
$\begingroup$

In all video coding standards, motion estimation is always done in pixel domain using block matching. I wonder why it cannot be estimated in DCT(Discrete cosine transform) domain using block matching directly? If two blocks are similar in value in DCT domain, doesn't it mean that they are similar to each other in pixel domain as well?

All the comments and suggestions are welcome!!! Thank you!

Improve this question
$\endgroup$

2 Answers 2

Reset to default
3
$\begingroup$

Block matching will only work well if the pixel offset is (close to) a multiple of the block size, in both dimensional axises. Odds against that might be (8*8-1):1 or (16*16-1):1.

Improve this answer
$\endgroup$
1
  • $\begingroup$ hi @hotpaw2, thank you for your reply. But evidently, many people use overlapped block matching algorithm to do motion estimation, don't they? so I don't see why the pixel offset have to be/close to a multiple of the block size. And btw, this is not relevant (or directly relevant?) to my question. I don't know why people can't use block matching in DCT domain to estimate motion vectors between key frames. $\endgroup$
    – james
    Commented May 28, 2012 at 20:51
0
$\begingroup$

If you consider the brute force matching approach for detecting motion, you'll see that though we work with blocks of fixed size, the block itself can start at any pixel. This isn't possible with the DC transformed data. You can't compare combine parts of DCT of different blocks and compare with another block (in other image).

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.