Re: the basic idea of my codec

Maciek Urbanski wrote:
>> How exactly would you suggest to integrate motion compensation?
> 
> Let's assume we have point with given coordinates screen&time space [x,y,t].
> When we want to get the left neighbour, it's coordinates are [x-1,y,t], when
> we take the upper neighbour it's [x,y-1,t]. Without motion compensation
> taking the previous neighbour in time would be: [x,y,t-1]. With motion
> compensation: [x+prevx[x,y], y+prevy[x,y],t-1]. The entries from tables
> "prevx" and "prevy" form 2-D vector which means: where this pixel was on the
> proevious frame. This approach is exactly the same like in:
> http://www.microsoft.com/china/research/dload_files/group/imedia/icme01_MCLI
> FT-4th.pdf (pixel adressing - that is).

I have been thinking about that paper ... they seem to have set out trying to do a
true wavelet decomposition in the temporal direction, but in the end found out it
just didnt work ... so they just discarded the low pass part and did normal
biderectional motion compensation with a slightly unusual ordering of frames
(using other B frames as references is not unheard of, H26L does it too).

I would not be at all surprised that if you took their coder and replaced the 9-7
wavelet coder for the 7 motion compensated frames of a GOP with DCT
coding you could do even better :)  (keeping wavelets for the intra frames of
course.)

> Example: you have the
> panorama shot with caamer panning form left to right. The motion
> compensation would build-up information, that the pixel from frame "t" in
> the frame "t+1" moved little to left. You just got more infomation. No
> signal change.

MCLIFT is a form of motion compensated predictive coding though.
Which code the DFD, not the original frames ... and these DFDs are
decorrelated from eachother.

When you said motion compensation I assumed predictive coding.

> ...but the wavelet transform , taking into account the motion vectors can be
> performed in 3D neighbouhood, thus prediction of pixel value is better than
> in 1D case (due to larger neighbourhood. in the simplest case 2 pixels in
> 1D, 4 in 3D and 6 in 3D).

This could work, but from my limited understanding this seems more simular
to CWIs approach (and to a lesser extent Taubman and Secker's) than
MCLIFT.

For a bird's eye view of their work see :
http://www.ercim.org/publication/Ercim_News/enw48/heijmans.html

For Taubman and Secker's :
http://www.stanford.edu/class/ee398b/resources/taubman:02-ICIP.pdf

Marco


--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to '[email protected]'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.