390 likes | 573 Views
Jose Javier Garcia Aranda email: jose_javier.garcia_aranda@alcatel-lucent.com Marina Gonzalez Casquete 22 Octubre 2013. Codificación logarítmica: C alidad wavelet a precio de DPCM. Hiparco de Nicea. Contexto: Videoxperience. Retos para un posible nuevo algoritmo.
E N D
Jose Javier Garcia Aranda email: jose_javier.garcia_aranda@alcatel-lucent.com Marina Gonzalez Casquete 22 Octubre 2013 Codificación logarítmica: Calidad wavelet a precio de DPCM Hiparco de Nicea
Retos para un posible nuevo algoritmo • No debe estar sujeto a patentes ( JPEG2000 y fractales tienen patentes asociadas que limitan su difusión) • Mejorar el ratio de compresión de forma significativa sobre algoritmos estándar basados en DCT ( JPEG), wavelets (JPEG2000) , fractales y otros (predictivos como WebP) • Compresión mayor y con menor coste computacional que los más avanzados (como wavelets, la compresión fractal, la compresión basada en redes neuronales y/o el video H264) • Permitir relacionar secuencias de imágenes con un bajo coste computacional, evitando así el tiempo invertido en el cálculo de vectores de movimiento (para vídeo)
Agenda 1| Introducción y concepto de saltologarítmico 2| Relevancia perceptual, mallas y escalados 3| color 4| Video y Futuro
LHE: fundamento La cantidad de información para el ojo humano es la variación logarítmica de la luz.
LHE: LogarithmicalHoppingEncoding Ytop Yleft Yi Un juego de saltos para cada Yref
LHE: LogarithmicalHoppingEncoding • LHE permite compresión estadística (huffman) de los hops, ya que los hops más pequeños aparecen un 90% • Cuantos más tipos de hops, mas calidad , aunque también aumentan los bpp (Bit Per Pixel) • Más de 8 tipos de hops + hop nulo no aportan significativamente más calidad
Asignación de códigos a los hops Puesto que un pixel se parece al anterior ( x-1) , el hop mas frecuente será el hop nulo Redundancia H Redundancia V Puesto que un pixel se parece al anterior ( y-1) , el siguiente hop mas frecuente será el hop localizado en y-1 Al resto de hops les asignaremos códigos huffman de mayor a menor probabilidad de aparición. Para cualquier imagen, los mas probables son los mas pequeños de modo que la tabla huffman será estática Estrategias mejores pendientes de ser inventadas
Ejemplo 8 hops + hop nulo 512x512 1.91 bpp LHE 42.11 dB JPEG 40.7dB JPEG2000 42.7dB complejidad O(n) nlog(n) >nlog(n)
Agenda 1| Introducción y concepto de saltologarítmico 2| Relevancia perceptual, mallas y escalados 3| color 4| Video y Futuro
Relevancia perceptual • Bordes y detalles (suaves y marcados) pero no “pelo” ni “ruido” ni “espuma”. La medida por tanto no puede ser la de la entropía
Estrategia: escalar las zonas de baja relevancia perceptual
Mallas: 3 niveles de escalado block 8x8 block 8x8 escalatedto 4x4 (ratio 4:1) or 8x4 (ratio 2:1) or 4x8 (ratio 2:1) Macroblock 16x16 macroblock 16x16 escalatedto 8x4 or 4x8 (ratio 8:1) or 4x4 (ratio 16:1) Macroblock 32x32 macroblock 32x32 escalatedto 4x8 or 8x4 (ratio 32:1) or 4x4 (ratio 64:1)
LHE : distintas calidades Calidad media Máxima calidad Minima calidad Algunos bloques escalados en malla 2, otros en malla 1 y otros en malla 0, en función de su relevancia perceptual Todos los bloques en malla cero y sin escalar Todo escalado a malla 2 ¿Se podria usar la informacion de mallas para elegir una estrategia de asignación de códigos a los hops más adecuada y así reducir más los bpp? Es posible, aun son posiblesmuchasmejoras. LHE acaba de nacer
3 Mallas y reconstrucción 1. Asignacion de escalados según relevancia perceptual 2. escalado y codificación de bloques escalados 3. Reconstrucción por interpolación
LHE : comparativa con DCT JPEG a 0.1 bpp: 21.9 dB LHE a 0.1 bpp : 27.4dB
DCT LHE LHE : comparativa con DCT
Paralelización y performance Ytop Yleft Yi Tiempos (ms) LHE parallel processing of NxN pixels in 2N-1 steps. Tiempos tomados de prototipo java experimental, no optimizado
Agenda 1| Introducción y concepto de saltologaritmico 2| Relevancia perceptual, mallas y escalados 3| Color en LHE 4| Video y Futuro
Modelo YUV (422 y 420) crominanciaU[i]=128+(-147*red- 289*green+ 436* blue)/1000; //funcion de crominanciaU crominanciaV[i]=128+ (615*red – 515*green -100*blue)/1000; //funcion de crominanciaV luminancia[i]=(red*299+ green*587 + blue*114)/1000; YUV 420 YUV 422 Y1 Y2 Y3 Y4 Y1 Y2 Y3 Y4 Y5 Y6 Y7 Y8 Y5 Y6 Y7 Y8 U1 U2 U3 U4 U1 U2 V1 V2 V3 V4 V1 V2
Modelo YUV (422 y 420) en LHE Liso Caracterización del color Admite escalados YUV 420 YUV 422
Modelo YUV 422 aplicado a LHE 0,96 BPP 0,32 BPP 0,37 BPP
Modelo YUV 422 aplicado a LHE 1,65 BPP 33,22 dB
Modelo YUV 422 aplicado a LHE Y: 0,18 BPP U: 0,05 BPP V: 0,058 BPP 0,388 BPP 28,4 dB
Agenda 1| Introducción y concepto de saltologaritmico 2| Relevancia perceptual, mallas y escalados 3| Color en LHE 4| Video y Futuro
Cloud gaming:Latencycomposition Video Decoding Video Encoding network Game server Entre que un jugador realiza una acción y ve sus efectos en la pantalla pasan al menos: 1 2 3 4 5 6 2 x latencia red + latencia encoder + latencia decoder Como norma general se aprecia que 60 ms de latencia de red (en el caso de 30-40vms de latencia de codificación/decodificación) es el límite para una experiencia de juego satisfactoria independientemente del tipo de juego
Vectores de movimiento La estimación de movimiento es un proceso con una alta complejidad de cálculo y a menudo representa 2/3 del coste computacional en la codificación de vídeo. Actualmente, muchas de las investigaciones dentro el campo de la codificación de vídeo se centran en buscar algoritmos que puedan realizar más eficientemente la estimación de movimiento. En cloudgaming (o aplicaciones de video interactivo) solo va a haber frames I y frames P, no frames B. Por tanto los vectores se calculan sólo a partir del frame/s anteriores y no posteriores.
Hops logarítmicos temporales (T-hops) “Target frame” “lastframe” Las metricas sobre los T-Hops ahora no nos dicen cuanta relevancia tiene la información, sino cuánto ha cambiado la información
video codificado en T-hops Podemos representar una secuencia de video con T-HOPS. Si el movimiento es brusco se pierden los detalles. Cuando se estabiliza empiezan a verse los detalles, pues los nuevos saltos mas pequeños van refinando en el tiempo la imagen
Estimación LHE de Vectores Calculamos el centro de gravedad de los hops de cada tipo, al tiempo que estamos haciendo la codificacion de los T-hops 1 Lastframe + T-hops = target frame + V 2 Lastframe + V + T-hops’ = target frame + V’ Macrobloque 32x32 “caja 1” “caja 1” v “caja 2” “caja 2” Si la caja2 conserva el centro de gravedad de cada hop mas o menos en el mismo lugar relativo, es que el vector ha sido bien estimado y se puede usar para el siguiente fotograma. SI por el contrario se ha desplazado, actualizamos el vector para estimar el siguiente fotograma. Si ha cambiado mucho, lo despreciamos y asignamos V=0
Estimación LHE de Vectores Estimación incorrecta en un bloque Estimación correcta. Informaciónresultantenula Estimación correcta. Presencia de información en las areas “nuevas”
Video con LHE: conclusiones Podemos representar una secuencia de video con T-HOPS. Si el movimiento es brusco se pierden los detalles. Cuando se estabiliza empiezan a verse los detalles, pues los nuevos saltos mas pequeños van refinando en el tiempo la imagen Los T-HOPS tienen una altísima redundancia espacial, mayor aun que los Hops espaciales, por lo que son fácilmente compresibles con técnicas de escalado similares Los T-HOPS permiten calcular vectores de movimiento sin apenas coste computacional, lo que permitiría tiempos de codificación cercanos al 1ms , con alta compresión LHE, por lo tanto se presenta como una alternativa superior a DCT en calidad y computacionalmente y a la vez como una técnica de codificación de vídeo ultra rápida para aplicaciones de video interactivo (cloudgaming, videoconf…) LHE necesita desarrollarse mucho más. Acaba de nacer y puede mejorar mucho tanto en imagen fija como en video, aplicando nuevas ideas que están por inventar, mejorando la asignación de códigos a los hops, robusteciendo el calculo de vectores, etc jose_javier.garcia_aranda@alcatel-lucent.com marina.gonzalez_casquete@alcatel-lucent.com