¿Qué es un archivo J2K?

Un archivo J2K contiene el mismo flujo codificado JPEG 2000 sin encapsular que otras herramientas denominan .j2c o .jpc; la extensión .j2k es una convención de nombres de archivo para ese mismo formato, no un códec ni un contenedor independiente. Su contenido se centra en datos de imagen comprimidos, no en metadatos de contenedor.

.j2k es uno de varios nombres para un flujo codificado JPEG 2000 sin encapsular. Las herramientas de OpenJPEG tratan .j2k, .j2c y .jpc como el mismo formato de entrada, y el registro de IANA del tipo de medio para flujos codificados image/j2c incluye j2k como extensión de archivo. La decodificación comienza a partir de los propios encabezados del flujo codificado, el marcador SOC y el segmento de marcador SIZ, no de una firma ni de un identificador de formato del contenedor, y los segmentos de marcador que siguen registran el estilo de codificación, la cuantización y el orden de progresión. Dentro del flujo, una imagen se codifica como uno o más mosaicos rectangulares, y los datos comprimidos de cada mosaico se dividen en paquetes, cada uno perteneciente a una capa de calidad, un nivel de resolución, un componente y un precinto; el orden de los paquetes de un mosaico es lo que permite a un decodificador detenerse antes de terminar o decodificar a una resolución reducida. Un pipeline que necesite metadatos de contenedor puede encapsular el mismo flujo codificado en un archivo JP2, que lo almacena en una caja Contiguous Codestream después de las cajas JPEG 2000 Signature, File Type y JP2 Header.

¿Cómo debería detectar un pipeline un archivo .j2k? Por su contenido. Un flujo codificado sin encapsular comienza con los bytes FF 4F FF 51, mientras que un archivo JP2 comienza con la caja de firma de 12 bytes 00 00 00 0C 6A 50 20 20 0D 0A 87 0A. La herramienta opj_decompress de OpenJPEG muestra el orden más seguro para determinar en qué confiar: lee los bytes iniciales y, si no coinciden con la extensión, imprime una advertencia de que la extensión es incorrecta y decodifica según los bytes. Una entrada cuyos bytes iniciales no coincidan con ninguna firma conocida se rechaza como formato de entrada desconocido; la excepción es un archivo llamado .jpt, que acepta por su extensión sin realizar esa comprobación.
¿Qué determina si una herramienta escribe un flujo codificado .j2k o un archivo JP2? Por lo general, el nombre del archivo de salida. La documentación de opj_compress de OpenJPEG indica .j2k y .jp2 como sus extensiones de salida, y Pillow elige la forma a partir de la extensión, salvo que se establezca no_jp2, que fuerza un flujo codificado sin encapsular. Cambiar el nombre de un archivo existente no convierte nada: los bytes siguen siendo un flujo codificado o un archivo JP2, independientemente de lo que indique el sufijo.
¿Un archivo .j2k tiene compresión con pérdida? El nombre no lo indica. La sintaxis básica permite tanto el filtro wavelet reversible 5-3 como el irreversible 9-7, y tanto opj_compress de OpenJPEG como Pillow usan el filtro reversible salvo que se indique lo contrario. Un filtro reversible tampoco demuestra que el contenido no tenga pérdida: las relaciones de compresión o los objetivos de calidad proporcionados al codificador pueden hacer que las capas de calidad tengan pérdida, y que el archivo completo siga siendo sin pérdida depende del objetivo de la última capa. El manual de opj_compress describe su ejemplo -r 20,10,1 como «comprimir 20x, luego 10x y luego sin pérdida»: sin pérdida cuando se decodifican todas las capas y con pérdida cuando solo se decodifican las primeras. T.800 también señala que una transformación reversible puede usarse en flujos codificados truncados para proporcionar compresión con pérdida.
¿Qué cambia el orden de progresión? El orden en que aparecen los paquetes de cada mosaico y, por tanto, lo que se obtiene de una lectura parcial de ese mosaico. T.800 define cinco órdenes, escritos LRCP, RLCP, RPCL, PCRL y CPRL, que se indican en el segmento de marcador COD y pueden cambiarse mediante segmentos de marcador POC. El orden que prioriza las capas (LRCP) permite que la calidad mejore a medida que llegan los datos; el orden que prioriza la resolución (RLCP) entrega primero versiones de baja resolución de todos los componentes. Como el orden se aplica dentro de un mosaico, no garantiza una vista temprana de toda la imagen en un archivo con varios mosaicos: T.800 permite, pero no exige, que un codificador intercale partes de distintos mosaicos, y sin ese intercalado una lectura secuencial solo llega a los datos de un mosaico después de todos los datos de los mosaicos almacenados antes que él. T.800 también permite truncar los datos de un mosaico descartando los bytes finales, siempre que los parámetros del segmento de marcador de longitud del mosaico reflejen el truncamiento, por lo que el orden elegido determina qué sigue conteniendo un mosaico acortado.

La detección del formato debería inspeccionar el contenido del archivo, porque las extensiones por sí solas no distinguen de forma fiable las variantes de JPEG 2000. Seleccionar un analizador que solo admita contenedores puede provocar un fallo al procesar un archivo J2K válido.

¿Qué es un archivo J2K?

Cómo funcionan los archivos J2K

Datos clave

Cuándo son importantes los archivos J2K

Fuentes

Convierte tus conocimientos sobre multimedia en un pipeline funcional