¿Cómo funcionan los vectores de movimiento en la codificación predictiva para MPEG?

En MPEG, hay un proceso en el que una imagen se divide en macrobloques y se calcula un vector de movimiento para cada uno de esos macrobloques. Luego, transmite estos vectores, junto con los errores de predicción, para reconstruir la siguiente imagen en la secuencia de video.

Estoy tratando de comprender cómo funciona esto. Cada macrobloque tiene un vector de movimiento asociado, que (si el vector es [1,0]), dice que all the pixels in this block move 1 in the x direction and 0 in the y direction for the next frame. si todos los vectores de movimiento no se alinean correctamente, esto no dejará áreas de la imagen sin explicar (como el área donde ese macrobloque estaba en primer lugar)?

Por ejemplo, tengo la siguiente pregunta que encontré.

Considere la siguiente imagen en el tiempo 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

Esta imagen se dividió en macrobloques de 2x2 y se enviaron los siguientes vectores de movimiento para recrearla:

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

La imagen en el paso de tiempo anterior, t - 1, se veía así:

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

¿Cuáles fueron los errores transmitidos?

Como resolverias esto?

Para simplificar su confusión, hay dos procesos:

1. Estimación de
movimiento 2. Compensación de movimiento

Antes de hablar sobre la estimación, deberíamos hablar sobre la compensación de movimiento.

Digamos que la se divide en bloques .B l o c k s t [ k ] ( x ′ , y ′$Image_{t}(x,y)$$Blocks_{t}[k](x',y')$

La tarea de la compensación de movimiento es producir de cualquier región de la .I m a g e t - 1 ( x , y $Blocks_{t}[k](x',y')$$Image_{t-1}(x,y)$

Por lo tanto, otro bloque no necesariamente alineado en el límite de 16x16 es la mejor coincidencia posible$Blocks_{t-1}[k](x'+mx,y'+my)$

Aquí, se llama vectores de movimiento.$mx, my$

Podemos calcular el error entre el objetivo y la referencia como

Así que ahora, el codificador básicamente transmite (con DCT y cuantización) y para cada bloque.( m x , m y ) [ k $Err_{t}[k](x,y)$${( mx, my) }[k]$

Entonces el codificador tiene 2 trabajos que hacer:

1. Estimación de movimiento
El proceso o estimación para cada manera que se minimiza se llama estimación de movimiento.k E r r t [ k ] ( x , y ${ mx, my }[k]$$k$$Err_{t}[k](x,y)$

2. Generación de imagen de error después de la compensación de movimiento
El proceso de construcción de partir de píxeles de imagen y se denomina compensación de movimiento. La imagen de error es lo que se transmite.I t ( m x , m y ) [ k $Blocks_{t}[k](x',y')$$I_{t}$${ (mx, my) }[k]$

Finalmente, el decodificador puede rehacer la compensación de movimiento por sí mismo usando vectores moiton y la imagen de error para hacer la reconstrucción final de la imagen.

Ahora nos damos cuenta de algunos puntos:

1. La estimación de Best Motion ayuda a minimizar la energía que se requiere transmitir y, por lo tanto, optimiza los bits para una calidad determinada.

2. Sin embargo, incluso si no es ideal o si la escena tiene un cambio significativo sobre la última imagen, el siempre se transmite al receptor, de ahí la reconstrucción siempre es perfecto (módulo la pérdida creada por la cuantización). Por lo tanto, incluso si tiene un vector de movimiento subóptimo o la redundancia no es mucho, la reconstrucción siempre es perfecta, ¡aunque con más bits!E r r t [ k ] ( x , y ${ (mx, my) }[k]$$Err_{t}[k](x,y)$

3. Cada bloque es un movimiento compensado por derecho propio, por lo tanto, incluso si los vectores de movimiento reales de los bloques vecinos no tienen ningún efecto en la construcción. Por lo tanto, no es necesario tener vectores de movimiento perfectamente alineados para que sea posible una reconstrucción perfecta.$Blocks_{t}[k](x',y')$

4. Aunque existe un algoritmo que es lo suficientemente inteligente como para adivinar que si tiene un vector de movimiento la suposición para podría estar más cerca de eso solamente.$Blocks_{t}[k]$$( mx ,my )[k]$$Blocks_{t}[k+1]$

5. Finalmente, suponga que la siguiente imagen es completamente diferente, es posible que la energía para .

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

En tales casos, podría ser más aconsejable transmitir el bloque directamente sin predicción que enviar la diferencia. Esto también es posible en el codificador mediante una disposición llamada bloque INTRA.

No, no dejará agujeros, porque el vector es de un cuadro desconocido (P o B), a un cuadro conocido ( cuadro I). Recuerda un poco cómo calcular una transformación de imagen: utiliza una transformación hacia atrás para evitar agujeros /

$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: No estamos protegidos de ningún tipo de superposición del bloque "en movimiento" (dos bloques se mueven a ubicaciones superpuestas). Hay formas de manejar eso, pero está más allá del alcance de esta respuesta. Por ahora, solo vamos a reescribir los píxeles con un bloque que estamos moviendo a su ubicación, de modo que incluso si hubo bloques movidos allí anteriormente, se sobrescribirán.

$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