Come funzionano i vettori di movimento nella codifica predittiva per MPEG?

In MPEG, esiste un processo in cui un'immagine viene suddivisa in macroblocchi e viene calcolato un vettore di movimento per ciascuno di quei blocchi di macro. Quindi trasmetti questi vettori, insieme agli errori di previsione, per ricostruire l'immagine successiva nella sequenza video.

Sto cercando di capire bene come funziona. A ogni macroblocco è associato un vettore di movimento, che (se il vettore è [1,0]), dice all the pixels in this block move 1 in the x direction and 0 in the y direction for the next frame. Se tutti i vettori di movimento non si allineano correttamente, questo non lascerà le aree dell'immagine non considerate (come l'area in cui quel macroblocco era in primo luogo)?

Ad esempio, ho la seguente domanda che ho trovato.

Considera la seguente immagine al momento t:

7   7   7   7           
7   7   5   5        
7   5   5   8         
8   8   8   8           
9   9   9   9       
9   9   9   9

Questa immagine è stata suddivisa in macroblocchi 2x2 e sono stati inviati i seguenti vettori di movimento per ricrearla:

(0,0)  (0,0)  (0,1)  (-1,1)  (0,0)  (0,0)

L'immagine nella fase temporale precedente, t - 1, era simile alla seguente:

7   7   7   7           
7   7   5   4        
7   7   7   7         
7   5   8   8           
8   9   8   9       
9   9   9   9   

Quali sono stati gli errori trasmessi?

Come lo risolveresti?

Per semplificare la tua confusione, esistono due processi:

1. Stima del
movimento 2. Compensazione del movimento

Prima di parlare della stima, dovremmo parlare della compensazione del movimento.

Supponiamo che sia diviso nel blocco B l o c k s t [ k ] ( x ′ , y ′ ) .$Image_{t}(x,y)$$Blocks_{t}[k](x',y')$

Il compito della compensazione del movimento è di produrre da qualsiasi regione di I m a g e t - 1 ( x , y ) .$Blocks_{t}[k](x',y')$$Image_{t-1}(x,y)$

Quindi un altro blocco non necessariamente allineato al confine 16x16 è la migliore corrispondenza possibile $Blocks_{t-1}[k](x'+mx,y'+my)$

Qui, si chiama vettori di movimento.$mx, my$

Possiamo calcolare l'errore tra il target e il riferimento come

Quindi ora l'encoder trasmette sostanzialmente (con DCT e quantizzazione) e ( m x , m y ) [ k ] per ogni blocco.$Err_{t}[k](x,y)$${( mx, my) }[k]$

Quindi l'encoder ha 2 lavori da fare:

1. Stima del movimento
Il processo o la stima di per ogni k tale che E r r t [ k ] ( x , y ) è ridotto al minimo si chiama stima del movimento.${ mx, my }[k]$$k$$Err_{t}[k](x,y)$

2. Generazione dell'immagine di errore dopo la compensazione del movimento
Il processo di costruzione di da I t pixel dell'immagine e ( m x , m y ) [ k ] è chiamato compensazione del movimento . L'immagine dell'errore è ciò che viene trasmesso.$Blocks_{t}[k](x',y')$$I_{t}$${ (mx, my) }[k]$

Infine, il decodificatore può rifare da solo la compensazione del movimento usando i vettori moiton e l'immagine di errore per effettuare la ricostruzione finale dell'immagine.

Ora realizziamo alcuni punti:

1. La migliore stima del movimento aiuta a ridurre al minimo l'energia necessaria per essere trasmessa e quindi ottimizza i bit per una data qualità.

2. Tuttavia, anche se non è l'ideale o se la scena presenta cambiamenti significativi rispetto all'ultima immagine, l' E r r t [ k ] ( x , y ) viene sempre trasmessa al ricevitore, quindi la ricostruzione è sempre perfetto (modulo la perdita creata dalla quantizzazione). Quindi, anche se hai un vettore di movimento non ottimale o la ridondanza non è molto, la ricostruzione è sempre perfetta anche se con più bit!${ (mx, my) }[k]$$Err_{t}[k](x,y)$

3. Ogni blocco è compensato dal movimento da solo - quindi anche se i vettori di movimento effettivi di qualsiasi blocco vicino non hanno alcun effetto nella costruzione. Pertanto, non è necessario disporre di vettori di movimento perfettamente allineati per consentire una ricostruzione perfetta.$Blocks_{t}[k](x',y')$

4. Anche se esiste un algoritmo che è abbastanza intelligente da indovinare che se ha un vettore di movimento ( m x , m y ) [ k ] l'ipotesi di B l o c k s t [ k + 1 ] potrebbe sii solo più vicino a quello.$Blocks_{t}[k]$$( mx ,my )[k]$$Blocks_{t}[k+1]$

5. Supponiamo infine che l'immagine successiva sia completamente diversa, è possibile che l'energia per .

   $$Energy (Err_{t}[k](x,y)) > Energy ( Blocks_{t}[k](x',y') )$$

In tali casi, potrebbe essere più consigliabile trasmettere il blocco direttamente senza previsione piuttosto che inviare la differenza. Ciò è possibile anche nell'encoder da una disposizione chiamata blocco INTRA.

No, non lascerà buchi, perché il vettore proviene da un frame sconosciuto (P o B), a un frame noto (I-frame). Ricorda un po 'di come calcolare una trasformazione dell'immagine: usi una trasformazione all'indietro per evitare buchi /

$B(i,j)$$i = \{0,1,2\}$$j = \{0,1\}$$(2i, 2j)$

(0,0) (0,2)
(2,0) (2,2)
(4,0) (4,2)

$M(i,j)$

(0,0) (0,0)
(0,1) (-1,1)
(0,0) (0,0)

$B'(i,j)=B(i,j)+M(i,j)$

(0,0) (0,2)
(2,1) (1,3)
(4,0) (4,2)

$B'(i,j)$$B(i,j)$

Nota: non siamo protetti da alcun tipo di sovrapposizione del blocco "in movimento" (due blocchi vengono spostati in posizioni sovrapposte). Ci sono modi per gestirlo, ma va oltre lo scopo di questa risposta. Per ora, riscriveremo tutti i pixel con un blocco che stiamo spostando nella loro posizione, in modo che anche se ci fossero blocchi spostati lì in precedenza, verranno sovrascritti.

$B'(i,j)$$B(i,j)$$F_e$

7 7 7 7
7 7 5 7
7 7 7 8
7 5 5 8
8 9 8 9
9 9 9 9

$E$$F_e$$F$$E=F-F_e$

0 0 0 0           
0 0 0 -3        
0 0 0 -1         
0 0 3 0           
0 0 0 0       
0 0 0 0