HomeDivulgaciónDCP, un acercamiento práctico al estándar de proyección de cine (III)

DCP, un acercamiento práctico al estándar de proyección de cine (III)

DCP

Formateando los fotogramas: tamaño y compresión

En este punto vamos realizar dos acciones necesarias para tener los fotogramas terminados: adaptar la resolución (acción propia de DCDM) y la compresión de la imagen (acción exclusiva del DCP). De esta forma solapamos el término del DCDM con el inicio del DCP propiamente dicho. Vamos a explicar esto por partes.
La resolución más baja estandarizada por el DCI fue 2K (2048×1080 píxeles) para el área contenedora de la imagen. Tras ésta vendría la 4K (4096×2160 píxeles) y actualmente se espera la incorporación del tamaño 8K. Usar un formato superior a la resolución de nuestra fuente no supone ninguna mejora de la calidad ni de las posibilidades de distribución (todos los proyectores 4K interpolan fuentes 2K) y solo supone un sobrecoste de tiempo, espacio y dinero.
Nosotros nos vamos a centrar en el formato de imagen nivel 3 (2K@24fps), que es el más próximo a nuestra fuente HD. Dentro de este formato, la imagen en proyección puede tener una de las dos posibles relaciones de aspecto aceptadas en D-Cinema: 2.39:1 (scope) o 1.85:1 (flat). Esto implica unas resoluciones de imagen de 2048×858 y de 1998×1080 respectivamente, siempre con píxeles con relación de aspecto cuadrada (1:1). Lo lógico es no interpolar la imagen a un tamaño mayor, aunque tengamos cacheada parte de la imagen de nuestro Full-HD para tener un área de imagen cinemascope (tendríamos 1920×804 píxeles activos). Si interpolamos hasta 2048×858 para abarcar el máximo de pantalla, podemos tener problemas de definición. Lo mejor será dejar nuestra imagen base HD 1920×1080 centrada sobre uno de los formatos de proyección 2K, mapeada píxel a píxel. Así que, propiamente dicho, no existe conformado de la imagen (puesto que esta se mantiene con su resolución original), sino una incrustación de la imagen centrada dentro del contenedor de imagen 2K. Eso es lo que hará la sentencia “border”: rellenar los bordes con negro hasta alcanzar el tamaño de imagen necesario compatible con 2K. Debemos escribir este código después de –gamma 2.6 y antes del directorio de salida del comando ImageMagick que vimos en el apartado anterior (Imagen 1).

dcp
Imagen 1. bordercolor black -border 39×0. Imagen izquierda: imagen Full-HD 1920×1080 original (16:9). Imagen derecha: incrustación de la imagen dentro del contenedor de imagen flat 1998×1080 (1.85:1).

Si el área de nuestra imagen no ocupa el 16:9 original, es decir, estamos usando una relación de aspecto diferente (cacheando parte de la imagen con negro) y estamos convencidos de interpolar y extender nuestra imagen hasta ocupar uno de los dos formatos de imagen activa posibles por completo, podemos hacerlo escribiendo una de las siguientes sentencias después de –gamma 2.6 y antes del directorio de salida del comando ImageMagick que vimos en el apartado anterior (Imagen 2).

dcp
Imagen 2. Para formato flat (1.85:1) completo: -crop 1920×1038+0+21 +repage -filter lagrange -define filter:support=2.0 -resize 1998×1080. Imagen izquierda: imagen full-HD 1920×1080 original (16:9) con marcas de 1.85:1. Imagen derecha: imagen recortada y ampliada a formato flat 1998×1080 (1.85:1).

De una u otra forma, lo que obtenemos es un formato de imagen compatible con el tamaño 2K (se iguala siempre una de las dimensiones), que contiene nuestra imagen con la relación de aspecto de proyección correcta.
La compresión de la imagen es un tema ya muy debatido, estudiado y estandarizado. Una imagen sin compresión con 2K de resolución y 12 bits por componente ocupa unos 10 MB. Solo hay que pensar que a 24 fps el flujo sin compresión de D-Cinema sería equivalente a unos 240 MB/s o casi 2Gbps (¡equivalente a 100 ADSLs de 20 Mbps!).  La decisión de distribuir el material comprimido se tomó en base a la necesidad de hacer un archivo de tamaño manejable, que cupiera en un disco duro de la época (no existían los discos duros de 2TB en aquellos años, ¡menos mal!) y pudiera enviarse por medios telemáticos (satélite, conexión de Internet…) reduciendo los tiempos y los costes de distribución. Y todo ello sin sacrificar la calidad. Sabemos (porque todos lo usamos en nuestra cámara de fotos digital, en Internet y en el móvil) que el formato de compresión de imagen más extendido y alabado actualmente es el JPEG. Posterior a éste apareció en el año 2000 el JPEG2000 (IEC/ISO 15444), una mejora del estándar anterior con más posibilidades y que se adaptaba a las necesidades del DCI: alta calidad y eficiencia de compresión, soporte de hasta16 bits por componente sin submuestreo de color, capacidad de aceptar las resoluciones de 2K y 4K y, lo más importante, tratarse de un estándar abierto, de forma que pudiera ser fácilmente implementado por los fabricantes de hardware de cine digital en sus equipos de procesado de señal y en el futuro software de creación DCP. En verano de 2004, el DCI elegía definitivamente el JPEG2000 como su estándar de compresión.
Recordar que cualquier formato JPEG (original y versión 2000) siempre trabaja descomponiendo las imágenes frecuencialmente y que, por lo tanto, el error de codificación depende de las altas frecuencias (cantidad y densidad de zonas con alto detalle) que contenga la imagen original. La mejora de JPEG2000 está en el uso de wavelets en vez de la conocida transformada discreta del coseno (DCT). No vamos a entrar en detalles matemáticos pero sí vamos a explicar sus bases funcionales. El JPEG original basa su motor de compresión en la división de la imagen en bloques de 8×8 píxeles que posteriormente comprimía frecuencialmente. Esto supone la aparición de errores de codificación (sobretodo en zonas de ruido, en negros y en regiones degradadas sin detalle) en forma de macrobloques visibles para compresiones medias y altas. Sin embargo, JPEG2000 no usa bloques de compresión sino que descompone toda la imagen en bandas frecuenciales, de forma que cada vez se analiza la imagen entera y así no se producen problemas de banding ni de macrobloques en la imagen. Visualmente, el error apreciable es siempre menor (e incluso despreciable) que para el JPEG original a igualdad de tamaño de archivo.

dcp
Imagen 3. Para formato scope (2.39:1) completo: -crop 1920×804+0+138 +repage -filter lagrange -define filter:support=2.0 -resize 2048×858. Imagen izquierda: imagen full-HD 1920×1080 original (16:9) con marcas de 2.35:1. Imagen derecha: imagen recortada y ampliada a formato scope 2048×858 (2.35:1).

La compresión JPEG2000 es una compresión intra-frame o de imagen completa, que no se ve afectada por las imágenes anteriores o posteriores como ocurre en MPEG. JPEG2000 saca provecho de las limitaciones propias del sistema visual humano y de la redundancia de información de cada imagen, de forma que puede optimizar los datos hasta cierto nivel sin que el espectador detecte errores. El algoritmo base (basado solo en la parte I de la especificación) implementa el CDF: una transformación wavelet irreversible o, hablando llanamente, una compresión con pérdidas de información. Suele emplearse el término “lossy” para describir estas compresiones con pérdidas de información que, si bien no implican pérdidas visuales, en casos muy aislados sí que han llegado a aparecer defectos tales como la falta de detalle o incluso imágenes borrosas.
La tasa de datos más alta posible para imágenes de un DCP está establecida en 250Mbps. Esta velocidad de datos implica trabajar con compresiones lossy eficientes. Si se baja la tasa de datos, el primer defecto que se observa es el de pérdida del detalle llegando en casos extremos a borrosidad en las imágenes. La tasa crítica a partir de la cual pueden aparecer defectos es un valor que depende directamente de las imágenes originales y de sus características técnicas. Hay que tener en cuenta que la compresión aplicada es altamente eficiente en cuanto a datos producidos, y usa una tasa de bits variable (VBR) para optimizar el flujo final de salida. Esto se aplica en imágenes con poco detalle original o fondos uniformes (como los títulos de crédito sobre fondo negro), de tal forma que el archivo de salida ocupa muy poco espacio, mientras que imágenes con mucho detalle fino se comprimen en archivos mucho más grandes (hasta un máximo de 10.5 Mbits). En la práctica, tasas de DCP entre 80 y 160 Mbps consiguen resultados igual de eficientes que el máximo de 250 Mbps comentado, de forma que ahorramos espacio de almacenamiento igualando la calidad.
El formato de archivo elegido fue el JPEG2000 “codestream”, conocido con el formato “.j2c”. Esto dignifica que no posee metadatos extra de información y que solo se almacena la imagen en bruto codificada. Sin embargo, existe un pequeño problema y es que se trata de una implementación versión 3 y no todas las herramientas son compatibles con la generación de este tipo de .j2c. Por ejemplo, ¡el motor QuickTime realiza exportaciones en este formato que posteriormente son incompatibles con el servidor D-Cinema!
Me duele decirlo de nuevo, pero otra vez y tal como ocurría con ImageMagick, para este paso requerimos de un programa de código abierto que, si no somos expertos en línea de comandos durante su instalación, Windows se plantea como mejor alternativa. Mientras que sobre este sistema operativo la instalación es fácil y sencilla, los usuarios de MAC OS X han de dar una pincelada que pueda ayudar a tener esta herramienta funcionando. Podemos instalar este software usando, de nuevo, MacPorts. Si esta opción no nos funciona, sólo nos queda, aunque sea poco ortodoxa, descargarnos de la red el archivo específico “openjpeg_v1_4_osx.tgz” (es la última versión) y descomprimirlo para tener los ejecutables y las librerías completas que habrá que copiar en los directorios adecuados: “image_to_j2k” lo copiamos al directorio donde tengamos las imágenes TIFF X’Y’Z’, y desde el terminal y en modo comandos ejecutamos lo siguiente:sudo cp /opt/local/lib/libtiff.3.dylib /usr/local/lib/ (nos pedirá la contraseña de administrador para ejecutar el comando).
El comando explícito que debemos usar para la compresión de las imágenes será:
En Windows:
FOR %a in (C:\DCP\Imagenes_TIFF_XYZ\*.tif) DO image_to_j2k -cinema2K 24 -i %a -o %a.j2c
Este comando, que debe ejecutarse estando en el directorio que contiene la aplicación “image_to_j2k.exe”, convierte todas las imágenes TIFF del directorio C:\DCP\Imagenes_TIFF-_XYZ\ al perfil 3 de JPEG2000 y los comprime en codestream en el mismo directorio (debemos mover los archivos .j2c creados a un nuevo directorio, por ejemplo, C:\DCP\Imágenes_J2C).
En MAC OS X:
for image in *; do echo $image; ./image_to_j2k -cinema2K 24 -i $image -o $image.j2c; done

Este comando, que debe ejecutarse estando en el directorio que contiene los fotogramas TIFF a tratar, convierte todas las imágenes del directorio donde estemos a JPEG2000 compatible con la especificación del DCI en el mismo directorio (debemos mover los archivos .j2c creados a un nuevo directorio, por ejemplo, Imágenes_J2C, en el mismo nivel que los anteriores).
El proceso es lento (cada imagen requerirá entre medio segundo y dos segundos de procesado) debido a que estamos codificando imágenes de más de 2 megapíxeles con procesadores no dedicados. Esto conviene saberlo porque existen fabricantes que venden tarjetas hardware especiales para la compresión JPEG2000 a alta velocidad e incluso en tiempo real usando granjas de render (muchos ordenadores trabajando en red como si fueran uno solo). Pero claro, esto tiene un coste elevado que solo productoras fuertes pueden permitirse. Nosotros, a cambio, disponemos de tiempo y paciencia para realizar el proceso, ¿verdad? El cálculo rápido es que el tiempo de compresión puede llegar a ser de tantas horas como minutos tenga nuestra creación audiovisual. Así, un largometraje puede tener al ordenador trabajando 100 horas, es decir, ¡más de cuatro días seguidos!

Txt: Gorka Larralde

Llega un nuevo conce
Estreno del canal TV
Rate This Article: