Jpeg

Ajustar Compartir Imprimir Citar
Compresión JPEG continuamente variada (entre Q=100 y Q=1) para una tomografía abdominal

JPEG (JAY-peg) es un método comúnmente usado de compresión con pérdida para imágenes digitales, particularmente para aquellas imágenes producidas por fotografía digital. El grado de compresión se puede ajustar, lo que permite un compromiso seleccionable entre el tamaño de almacenamiento y la calidad de la imagen. JPEG normalmente logra una compresión de 10:1 con poca pérdida perceptible en la calidad de la imagen. Desde su introducción en 1992, JPEG ha sido el estándar de compresión de imágenes más utilizado en el mundo y el formato de imagen digital más utilizado, con varios miles de millones de imágenes JPEG producidas todos los días a partir de 2015.

El término "JPEG" es un acrónimo de Joint Photographic Experts Group, que creó el estándar en 1992. JPEG fue en gran parte responsable de la proliferación de imágenes y fotografías digitales en Internet y, posteriormente, en las redes sociales.

La compresión JPEG se utiliza en varios formatos de archivo de imagen. JPEG/Exif es el formato de imagen más común utilizado por las cámaras digitales y otros dispositivos de captura de imágenes fotográficas; junto con JPEG/JFIF, es el formato más común para almacenar y transmitir imágenes fotográficas en la World Wide Web. Estas variaciones de formato a menudo no se distinguen y simplemente se denominan JPEG.

El tipo de medio MIME para JPEG es image/jpeg, excepto en las versiones anteriores de Internet Explorer, que proporciona un tipo MIME de image/pjpeg al cargar imágenes JPEG. Los archivos JPEG suelen tener una extensión de nombre de archivo de .jpg o .jpeg. JPEG/JFIF admite un tamaño de imagen máximo de 65 535 × 65 535 píxeles, por lo tanto, hasta 4 gigapíxeles para una relación de aspecto de 1:1. En 2000, el grupo JPEG introdujo un formato destinado a ser un sucesor, JPEG 2000, pero no pudo reemplazar al JPEG original como estándar de imagen dominante.

Historia

Antecedentes

La especificación JPEG original publicada en 1992 implementa procesos de varios trabajos de investigación y patentes anteriores citados por el CCITT (ahora ITU-T) y el Grupo Conjunto de Expertos Fotográficos.

La especificación JPEG cita patentes de varias empresas. Las siguientes patentes sirvieron de base para su algoritmo de codificación aritmética.

La especificación JPEG también cita otras tres patentes de IBM. Otras empresas citadas como titulares de patentes incluyen AT&T (dos patentes) y Canon Inc. Está ausente de la lista U.S. Patente 4.698.672, presentada por Compression Labs' Wen-Hsiung Chen y Daniel J. Klenke en octubre de 1986. La patente describe un algoritmo de compresión de imágenes basado en DCT y luego sería motivo de controversia en 2002 (ver Controversia de patente a continuación). Sin embargo, la especificación JPEG sí citó dos trabajos de investigación anteriores de Wen-Hsiung Chen, publicados en 1977 y 1984.

Estándar JPEG

"JPEG" significa Joint Photographic Experts Group, el nombre del comité que creó el estándar JPEG y también otros estándares de codificación de imágenes fijas. La "articulación" significaba ISO TC97 WG8 y CCITT SGVIII. Fundado en 1986, el grupo desarrolló el estándar JPEG a fines de la década de 1980. El grupo publicó el estándar JPEG en 1992.

En 1987, ISO TC 97 se convirtió en ISO/IEC JTC 1 y, en 1992, CCITT se convirtió en ITU-T. Actualmente en el lado del JTC1, JPEG es uno de los dos subgrupos del Comité Técnico Conjunto 1 de ISO/IEC, Subcomité 29, Grupo de Trabajo 1 (ISO/IEC JTC 1/SC 29/WG 1), denominado Codificación de imágenes fijas. Por el lado de ITU-T, ITU-T SG16 es el cuerpo respectivo. El JPEG Group original se organizó en 1986 y emitió el primer estándar JPEG en 1992, que fue aprobado en septiembre de 1992 como Recomendación ITU-T T.81 y, en 1994, como ISO/IEC 10918-1.

El estándar JPEG especifica el códec, que define cómo se comprime una imagen en un flujo de bytes y se descomprime nuevamente en una imagen, pero no el formato de archivo utilizado para contener ese flujo. Los estándares Exif y JFIF definen los formatos de archivo comúnmente utilizados para el intercambio de imágenes comprimidas en JPEG.

Los estándares JPEG se denominan formalmente como Tecnología de la información: compresión y codificación digital de imágenes fijas de tono continuo. ISO/IEC 10918 consta de las siguientes partes:

Compresión digital y codificación de imágenes continuas – Partes
Parte ISO/IEC standard UIT-T Rec. Primera fecha de publicación pública Última enmienda Título Descripción
Parte 1 ISO/IEC 10918-1:1994 T.81 (09/92) 18 de septiembre de 1992Requisitos y directrices
Segunda parte ISO/IEC 10918-2:1995 T.83 (11/94) 11 de noviembre de 1994Pruebas de cumplimiento Reglas y cheques para la conformidad del software (a la Parte 1).
Parte 3 ISO/IEC 10918-3:1997 T.84 (07/96) 3 de julio de 19961o de abril de 1999Extensiones Conjunto de extensiones para mejorar la Parte 1, incluyendo el Formato de archivo de intercambio de imágenes (SPIFF).
Parte 4 ISO/IEC 10918-4:1999 T.86 (06/98) 18 de junio de 199829 de junio de 2012Registro de perfiles JPEG, perfiles SPIFF, etiquetas SPIFF, espacios de color SPIFF, marcadores APPn, tipos de compresión SPIFF y autoridades de registro (REGAUT) métodos para registrar algunos de los parámetros utilizados para ampliar JPEG
Parte 5 ISO/IEC 10918-5:2013 T.871 (05/11) 14 de mayo de 2011Formato de intercambio de archivos JPEG (JFIF) Un formato popular que ha sido el formato de archivo de facto para imágenes codificadas por el estándar JPEG. In 2009, the JPEG Committee formally established an Ad Hoc Group to standardize JFIF as JPEG Part 5.
Parte 6 ISO/IEC 10918-6:2013 T.872 (06/12) Jun 2012Aplicación a sistemas de impresión Especifica un subconjunto de características y herramientas de aplicación para el intercambio de imágenes codificadas según la ISO/IEC 10918-1 para impresión.
Parte 7 ISO/IEC 10918-7:2021 T.873 (06/21) Mayo 2019 Junio 2021 Software de referencia Proporciona implementaciones de referencia del sistema de codificación básico JPEG

Ecma International TR/98 especifica el formato de intercambio de archivos JPEG (JFIF); la primera edición se publicó en junio de 2009.

Controversia de patentes

En 2002, Forgent Networks afirmó que poseía y haría cumplir los derechos de patente sobre la tecnología JPEG, derivados de una patente que se había presentado el 27 de octubre de 1986 y concedida el 6 de octubre de 1987: U.S. Patente 4,698,672 de Compression Labs' Wen-Hsiung Chen y Daniel J. Klenke. Si bien Forgent no era propietario de Compression Labs en ese momento, Chen luego vendió Compression Labs a Forgent, antes de que Chen comenzara a trabajar para Cisco. Esto llevó a Forgent a adquirir la propiedad de la patente. El anuncio de Forgent en 2002 creó un furor que recuerda al de Unisys; intenta hacer valer sus derechos sobre el estándar de compresión de imágenes GIF.

El comité JPEG investigó las reclamaciones de patentes en 2002 y opinó que estaban invalidadas por el estado de la técnica, una opinión compartida por varios expertos.

Entre 2002 y 2004, Forgent pudo obtener alrededor de 105 millones de dólares al otorgar licencias de su patente a unas 30 empresas. En abril de 2004, Forgent demandó a otras 31 empresas para hacer cumplir los pagos de licencias adicionales. En julio del mismo año, un consorcio de 21 grandes empresas informáticas presentó una contrademanda con el objetivo de invalidar la patente. Además, Microsoft inició una demanda por separado contra Forgent en abril de 2005. En febrero de 2006, la Oficina de Marcas y Patentes de los Estados Unidos acordó volver a examinar la patente JPEG de Forgent a pedido de la Public Patent Foundation. El 26 de mayo de 2006, la USPTO declaró inválida la patente basándose en el estado de la técnica. La USPTO también descubrió que Forgent conocía el estado de la técnica, pero intencionalmente evitó decírselo a la Oficina de Patentes. Esto hace que cualquier apelación para restablecer la patente sea muy poco probable que tenga éxito.

Forgent también posee una patente similar otorgada por la Oficina Europea de Patentes en 1994, aunque no está claro qué tan aplicable es.

El 27 de octubre de 2006, el plazo de 20 años de la patente de EE. UU. parece haber expirado y, en noviembre de 2006, Forgent acordó abandonar la aplicación de las reclamaciones de patente contra el uso del estándar JPEG.

El comité JPEG tiene como uno de sus objetivos explícitos que sus estándares (en particular, sus métodos básicos) se puedan implementar sin pagar tarifas de licencia, y ha obtenido los derechos de licencia apropiados para su estándar JPEG 2000 de más de 20 grandes organizaciones.

A partir de agosto de 2007, otra empresa, Global Patent Holdings, LLC, afirmó que su patente (Patente de EE. UU. 5.253.341) emitida en 1993 se infringe al descargar imágenes JPEG en un sitio web o a través de Email. Si no se invalida, esta patente podría aplicarse a cualquier sitio web que muestre imágenes JPEG. La patente estuvo bajo revisión por parte de la Oficina de Marcas y Patentes de EE. UU. De 2000 a 2007; en julio de 2007, la Oficina de Patentes revocó todos los reclamos originales de la patente pero encontró que un reclamo adicional propuesto por Global Patent Holdings (reclamo 17) era válido. Global Patent Holdings luego presentó una serie de demandas basadas en la reivindicación 17 de su patente.

En sus dos primeros juicios posteriores a la revisión, ambos presentados en Chicago, Illinois, Global Patent Holdings demandó a Green Bay Packers, CDW, Motorola, Apple, Orbitz, Officemax, Caterpillar, Kraft y Peapod como demandados. Se presentó una tercera demanda el 5 de diciembre de 2007 en el sur de Florida contra ADT Security Services, AutoNation, Florida Crystals Corp., HearUSA, MovieTickets.com, Ocwen Financial Corp. y Tire Kingdom, y una cuarta demanda el 8 de enero de 2008, en el sur de Florida contra el Boca Raton Resort & Club. Se presentó una quinta demanda contra Global Patent Holdings en Nevada. Esa demanda fue presentada por Zappos.com, Inc., que supuestamente fue amenazada por Global Patent Holdings, y buscó una declaración judicial de que la patente '341 no es válida y no se ha infringido.

Global Patent Holdings también había utilizado la patente '341 para demandar o amenazar a los críticos abiertos de patentes de software amplias, incluidos Gregory Aharonian y el operador anónimo de un blog de sitio web conocido como "Patent Troll Tracker. #34; El 21 de diciembre de 2007, el abogado de patentes Vernon Francissen de Chicago solicitó a la Oficina de Marcas y Patentes de EE. UU. que reexaminara el único reclamo restante de la patente '341 sobre la base del nuevo estado de la técnica.

El 5 de marzo de 2008, la Oficina de Patentes y Marcas Registradas de los EE. UU. acordó volver a examinar la patente '341 y descubrió que el nuevo estado de la técnica planteaba nuevas preguntas sustanciales con respecto a la validez de la patente. A la luz del reexamen, los infractores acusados en cuatro de las cinco demandas pendientes han presentado mociones para suspender (suspender) sus casos hasta que finalice la revisión de la patente '341 por parte de la Oficina de Patentes y Marcas Registradas de EE. UU. El 23 de abril de 2008, un juez que preside las dos demandas en Chicago, Illinois, concedió las mociones en esos casos. El 22 de julio de 2008, la Oficina de Patentes emitió la primera "Acción de Oficina" de la segunda revisión, declarando inválida la pretensión por diecinueve motivos distintos. El 24 de noviembre de 2009, se emitió un Certificado de Reexamen cancelando todas las reclamaciones.

A partir de 2011 y continuando desde principios de 2013, una entidad conocida como Princeton Digital Image Corporation, con sede en el este de Texas, comenzó a demandar a un gran número de empresas por supuestas infracciones de U.S. Patente 4.813.056. Princeton afirma que el estándar de compresión de imágenes JPEG infringe la patente '056 y ha demandado a un gran número de sitios web, minoristas, fabricantes y revendedores de cámaras y dispositivos. La patente fue originalmente propiedad y asignada a General Electric. La patente expiró en diciembre de 2007, pero Princeton ha demandado a un gran número de empresas por "infracciones pasadas" de esta patente. (Según las leyes de patentes de EE. UU., el propietario de una patente puede demandar por "infracción pasada" hasta seis años antes de la presentación de una demanda, por lo que, en teoría, Princeton podría haber seguido demandando a las empresas hasta diciembre de 2013). A partir de marzo de 2013, Princeton tenía juicios pendientes en Nueva York y Delaware contra más de 55 empresas. Se desconoce la participación de General Electric en la demanda, aunque los registros judiciales indican que asignó la patente a Princeton en 2009 y retiene ciertos derechos sobre la patente.

Uso típico

El algoritmo de compresión JPEG funciona de la mejor manera en fotografías y pinturas de escenas realistas con suaves variaciones de tono y color. Para el uso web, donde la reducción de la cantidad de datos utilizados para una imagen es importante para una presentación receptiva, los beneficios de compresión de JPEG hacen que JPEG sea popular. JPEG/Exif es también el formato más común que guardan las cámaras digitales.

Sin embargo, JPEG no es adecuado para dibujos lineales y otros gráficos textuales o icónicos, donde los fuertes contrastes entre píxeles adyacentes pueden causar artefactos notables. Estas imágenes se guardan mejor en un formato de gráficos sin pérdida, como TIFF, GIF, PNG o un formato de imagen sin procesar. El estándar JPEG incluye un modo de codificación sin pérdidas, pero ese modo no es compatible con la mayoría de los productos.

Como el uso típico de JPEG es un método de compresión con pérdida, que reduce la fidelidad de la imagen, no es apropiado para la reproducción exacta de datos de imágenes (como algunas aplicaciones de imágenes científicas y médicas y ciertos trabajos técnicos de procesamiento de imágenes).

JPEG tampoco es adecuado para archivos que se someterán a múltiples ediciones, ya que se pierde algo de calidad de imagen cada vez que se vuelve a comprimir la imagen, especialmente si la imagen se recorta o se desplaza, o si se cambian los parámetros de codificación; consulte la pérdida de generación digital. para detalles. Para evitar la pérdida de información de la imagen durante la edición secuencial y repetitiva, la primera edición puede guardarse en un formato sin pérdidas, luego editarse en ese formato y finalmente publicarse como JPEG para su distribución.

Compresión JPEG

JPEG utiliza una forma de compresión con pérdida basada en la transformada de coseno discreta (DCT). Esta operación matemática convierte cada cuadro/campo de la fuente de video del dominio espacial (2D) al dominio de frecuencia (también conocido como dominio de transformación). Un modelo de percepción basado libremente en el sistema psicovisual humano descarta información de alta frecuencia, es decir, transiciones bruscas en intensidad y tono de color. En el dominio de transformación, el proceso de reducción de información se llama cuantización. En términos más simples, la cuantificación es un método para reducir de manera óptima una gran escala numérica (con diferentes ocurrencias de cada número) en una más pequeña, y el dominio de transformación es una representación conveniente de la imagen porque los coeficientes de alta frecuencia, que contribuyen menos a la imagen general que otros coeficientes, son valores característicamente pequeños con alta compresibilidad. A continuación, los coeficientes cuantificados se secuencian y empaquetan sin pérdidas en el flujo de bits de salida. Casi todas las implementaciones de software de JPEG permiten al usuario controlar la relación de compresión (así como otros parámetros opcionales), lo que permite al usuario cambiar la calidad de la imagen por un tamaño de archivo más pequeño. En aplicaciones integradas (como miniDV, que utiliza un esquema de compresión DCT similar), los parámetros se preseleccionan y fijan para la aplicación.

El método de compresión suele tener pérdidas, lo que significa que parte de la información de la imagen original se pierde y no se puede restaurar, lo que posiblemente afecte la calidad de la imagen. Hay un modo sin pérdidas opcional definido en el estándar JPEG. Sin embargo, este modo no es ampliamente compatible con los productos.

También hay un formato JPEG progresivo entrelazado, en el que los datos se comprimen en varias pasadas con un nivel de detalle progresivamente mayor. Esto es ideal para imágenes grandes que se mostrarán durante la descarga a través de una conexión lenta, lo que permite una vista previa razonable después de recibir solo una parte de los datos. Sin embargo, la compatibilidad con archivos JPEG progresivos no es universal. Cuando los archivos JPEG progresivos son recibidos por programas que no los admiten (como versiones de Internet Explorer anteriores a Windows 7), el software muestra la imagen solo después de que se haya descargado por completo.

También hay muchas aplicaciones de cámaras, tráfico e imágenes médicas que crean y procesan imágenes JPEG de 12 bits, tanto en escala de grises como en color. El formato JPEG de 12 bits se incluye en una parte extendida de la especificación JPEG. El códec libjpeg admite JPEG de 12 bits e incluso existe una versión de alto rendimiento.

Edición sin pérdidas

Se pueden realizar varias modificaciones a una imagen JPEG sin pérdida (es decir, sin recompresión y la pérdida de calidad asociada) siempre que el tamaño de la imagen sea un múltiplo de 1 bloque MCU (Unidad codificada mínima) (generalmente 16 píxeles en ambas direcciones, para submuestreo de croma 4:2:0). Las utilidades que implementan esto incluyen:

Los bloques se pueden girar en incrementos de 90 grados, voltear en los ejes horizontal, vertical y diagonal y moverse en la imagen. No es necesario utilizar todos los bloques de la imagen original en la modificada.

Los bordes superior e izquierdo de una imagen JPEG deben estar en un límite de bloque de 8 × 8 píxeles, pero no es necesario que los bordes inferior y derecho estén así. Esto limita las posibles operaciones de recorte sin pérdidas y también evita los giros y rotaciones de una imagen cuyo borde inferior o derecho no se encuentra en un límite de bloque para todos los canales (porque el borde terminaría en la parte superior o izquierda)., donde, como se mencionó anteriormente, un límite de bloque es obligatorio).

Las rotaciones en las que la imagen no es un múltiplo de 8 o 16, cuyo valor depende del submuestreo de croma, no son sin pérdidas. La rotación de una imagen de este tipo hace que se vuelvan a calcular los bloques, lo que provoca una pérdida de calidad.

Al usar el recorte sin pérdidas, si el lado inferior o derecho de la región de recorte no está en un límite de bloque, el resto de los datos de los bloques usados parcialmente seguirán estando presentes en el archivo recortado y se podrán recuperar. También es posible transformar entre formato base y progresivo sin pérdida de calidad, ya que la única diferencia es el orden en que se colocan los coeficientes en el archivo.

Además, varias imágenes JPEG se pueden unir sin pérdidas, siempre que se hayan guardado con la misma calidad y los bordes coincidan con los límites del bloque.

Archivos JPEG

El formato de archivo conocido como "Formato de intercambio JPEG" (JIF) se especifica en el Anexo B de la norma. Sin embargo, este "puro" El formato de archivo rara vez se usa, principalmente debido a la dificultad de programar codificadores y decodificadores que implementen completamente todos los aspectos del estándar y debido a ciertas deficiencias del estándar:

Se han desarrollado varios estándares adicionales para abordar estos problemas. El primero de ellos, lanzado en 1992, fue el formato de intercambio de archivos JPEG (o JFIF), seguido en los últimos años por el formato de archivo de imagen intercambiable (Exif) y los perfiles de color ICC. Ambos formatos usan el diseño de bytes JIF real, que consiste en diferentes marcadores, pero además, emplean uno de los puntos de extensión del estándar JIF, a saber, los marcadores de aplicación: JFIF usa APP0, mientras que Exif usa APP1. Dentro de estos segmentos del archivo que quedaron para uso futuro en el estándar JIF y no son leídos por este, estos estándares agregan metadatos específicos.

Por lo tanto, de alguna manera, JFIF es una versión reducida del estándar JIF en el sentido de que especifica ciertas restricciones (como no permitir todos los diferentes modos de codificación), mientras que en otras formas, es una extensión de JIF debido a los metadatos añadidos. La documentación para el estándar JFIF original establece:

JPEG El formato de intercambio de archivos es un formato de archivo mínimo que permite intercambiar bitstreams JPEG entre una amplia variedad de plataformas y aplicaciones. Este formato mínimo no incluye ninguna de las características avanzadas encontradas en la especificación TIFF JPEG o cualquier formato de archivo específico de aplicación. Tampoco debería, para el único propósito de este formato simplificado es permitir el intercambio de imágenes comprimidas JPEG.

Los archivos de imagen que emplean compresión JPEG se denominan comúnmente "archivos JPEG" y se almacenan en variantes del formato de imagen JIF. La mayoría de los dispositivos de captura de imágenes (como las cámaras digitales) que emiten JPEG en realidad están creando archivos en formato Exif, el formato que la industria de las cámaras ha estandarizado para el intercambio de metadatos. Por otro lado, dado que el estándar Exif no permite perfiles de color, la mayoría del software de edición de imágenes almacena JPEG en formato JFIF y también incluye el segmento APP1 del archivo Exif para incluir los metadatos de una manera casi compatible; el estándar JFIF se interpreta con cierta flexibilidad.

Estrictamente hablando, los estándares JFIF y Exif son incompatibles, porque cada uno especifica que su segmento marcador (APP0 o APP1, respectivamente) aparece primero. En la práctica, la mayoría de los archivos JPEG contienen un segmento marcador JFIF que precede al encabezado Exif. Esto permite que los lectores más antiguos manejen correctamente el segmento JFIF de formato anterior, mientras que los lectores más nuevos también decodifican el siguiente segmento Exif, siendo menos estrictos en cuanto a exigir que aparezca primero.

Extensiones de nombre de archivo JPEG

Las extensiones de nombre de archivo más comunes para archivos que emplean compresión JPEG son .jpg y .jpeg, aunque < También se utilizan código>.jpe, .jfif y .jif. También es posible que los datos JPEG se incrusten en otros tipos de archivos: los archivos codificados en TIFF suelen incrustar una imagen JPEG como una miniatura de la imagen principal; y los archivos MP3 pueden contener un archivo JPEG de portada en la etiqueta ID3v2.

Perfil de color

Muchos archivos JPEG incorporan un perfil de color ICC (espacio de color). Los perfiles de color comúnmente utilizados incluyen sRGB y Adobe RGB. Debido a que estos espacios de color usan una transformación no lineal, el rango dinámico de un archivo JPEG de 8 bits es de aproximadamente 11 paradas; ver curva gamma.

Si la imagen no especifica la información del perfil de color (sin etiquetar), se supone que el espacio de color es sRGB a los efectos de la visualización en las páginas web.

Sintaxis y estructura

Una imagen JPEG consta de una secuencia de segmentos, cada uno de los cuales comienza con un marcador, cada uno de los cuales comienza con un byte 0xFF, seguido de un byte que indica qué tipo de marcador es. Algunos marcadores consisten solo en esos dos bytes; otros van seguidos de dos bytes (alto y luego bajo), lo que indica la longitud de los datos de carga útil específicos del marcador que siguen. (La longitud incluye los dos bytes de la longitud, pero no los dos bytes del marcador). Algunos marcadores van seguidos de datos codificados en entropía; la longitud de dicho marcador no incluye los datos codificados por entropía. Tenga en cuenta que los bytes 0xFF consecutivos se utilizan como bytes de relleno con fines de relleno, aunque este relleno de bytes de relleno solo debe tener lugar para los marcadores que siguen inmediatamente a los datos de escaneo codificados por entropía (consulte las secciones B.1.1.2 y E.1.2 de la especificación JPEG para obtener más detalles; específicamente "En todos los casos en los que se agregan marcadores después de los datos comprimidos, los bytes de relleno 0xFF opcionales pueden preceder al marcador").

Dentro de los datos codificados por entropía, después de cualquier byte 0xFF, el codificador inserta un byte 0x00 antes del siguiente byte, de modo que no parece haber un marcador donde no se pretende, lo que evita errores de trama. Los decodificadores deben omitir este byte 0x00. Esta técnica, denominada relleno de bytes (consulte la sección F.1.2.3 de la especificación JPEG), solo se aplica a los datos codificados por entropía, no a los datos de carga útil de marcadores. Sin embargo, tenga en cuenta que los datos codificados por entropía tienen algunos marcadores propios; específicamente los marcadores de reinicio (0xD0 a 0xD7), que se utilizan para aislar fragmentos independientes de datos codificados en entropía para permitir la decodificación paralela, y los codificadores pueden insertar estos marcadores de reinicio a intervalos regulares (aunque no todos los codificadores hacen esto).

Marcadores JPEG comunes
Nombre corto Bytes Carga Nombre Comentarios
SOI 0xFF, 0xD8ningunoInicio de la imagen
SOF0 0xFF, 0xC0tamaño variableInicio del marco (baseline DCT) Indica que se trata de un JPEG basado en DCT de base, y especifica el ancho, la altura, el número de componentes y el subcampeonato de componentes (por ejemplo, 4:2:0).
SOF2 0xFF, 0xC2tamaño variableInicio del marco (TCD progresivo) Indica que se trata de un JPEG progresivo basado en DCT, y especifica el ancho, la altura, el número de componentes y el subcampeonato de componentes (por ejemplo, 4:2:0).
DHT 0xFF, 0xC4tamaño variableDefine Huffman Table(s) Especifica una o más tablas Huffman.
DQT 0xFF, 0xDBtamaño variableDefinir tablas de cuantificación Especifica una o más tablas de cuantificación.
DRI 0xFF, 0xDD4 bytesDefinir Interval de reinicio Especifica el intervalo entre RSTn marcadores, en unidades de código mínimo (MCUs). Este marcador es seguido por dos bytes indicando el tamaño fijo para que pueda ser tratado como cualquier otro segmento de tamaño variable.
SOS 0xFF, 0xDAtamaño variableInicio del escáner Comienza un escaneo superior a fondo de la imagen. En las imágenes de base DCT JPEG, generalmente hay un solo escaneo. Las imágenes progresivas de DCT JPEG generalmente contienen múltiples escaneos. Este marcador especifica qué rebanada de datos contiene, y es seguida inmediatamente por datos codificados por entropía.
RSTn0xFF, 0xDn ()n=0,7)ningunoRestart Insertar todos r macrobloques, donde r es el intervalo de reinicio establecido por un marcador DRI. No se usó si no había un marcador DRI. Los tres pedazos bajos del ciclo de código marcador en valor de 0 a 7.
APPn0xFF, 0xEntamaño variableAplicación específica Por ejemplo, un archivo Exif JPEG utiliza un marcador APP1 para almacenar metadatos, establecido en una estructura basada estrechamente en TIFF.
COM 0xFF, 0xFEtamaño variableComentario Contiene un comentario de texto.
EOI 0xFF, 0xD9ningunoFin de la imagen

Hay otros marcadores Start Of Frame que introducen otros tipos de codificaciones JPEG.

Dado que varios proveedores pueden usar el mismo tipo de marcador APPn, los marcadores específicos de la aplicación a menudo comienzan con un nombre estándar o de proveedor (por ejemplo, "Exif" o " Adobe") o alguna otra cadena de identificación.

En un marcador de reinicio, las variables predictoras de bloque a bloque se restablecen y el flujo de bits se sincroniza con un límite de bytes. Los marcadores de reinicio proporcionan medios para la recuperación después de un error de flujo de bits, como la transmisión a través de una red poco confiable o la corrupción de archivos. Dado que las ejecuciones de macrobloques entre marcadores de reinicio pueden decodificarse de forma independiente, estas ejecuciones pueden decodificarse en paralelo.

Ejemplo de códec JPEG

Aunque un archivo JPEG se puede codificar de varias maneras, lo más común es hacerlo con la codificación JFIF. El proceso de codificación consta de varios pasos:

  1. La representación de los colores en la imagen se convierte de RGB a Y′CBCR, consistente en un componente luma (Y'), que representa el brillo, y dos componentes de croma, (CB y CR), representando el color. Este paso a veces se salta.
  2. La resolución de los datos del croma se reduce, generalmente por un factor de 2 o 3. Esto refleja el hecho de que el ojo es menos sensible a detalles de color fino que a detalles de brillo fino.
  3. La imagen se divide en bloques de 8×8 píxeles, y para cada bloque, cada uno de los Y, CB, y CR los datos se someten a la discreta transformación cosina (DCT). Un DCT es similar a una transformación Fourier en el sentido de que produce una especie de espectro de frecuencia espacial.
  4. Las amplitudes de los componentes de frecuencia se cuantifican. La visión humana es mucho más sensible a pequeñas variaciones de color o brillo sobre grandes áreas que a la fuerza de variaciones de brillo de alta frecuencia. Por lo tanto, las magnitudes de los componentes de alta frecuencia se almacenan con menor precisión que los componentes de baja frecuencia. El ajuste de calidad del encoder (por ejemplo 50 o 95 en una escala de 0 a 100 en la biblioteca del Grupo Independiente de JPEG) afecta en qué medida se reduce la resolución de cada componente de frecuencia. Si se utiliza un ajuste de calidad excesivamente bajo, los componentes de alta frecuencia se descartan por completo.
  5. Los datos resultantes para todos los bloques 8×8 se comprimen más con un algoritmo sin pérdidas, una variante de codificación Huffman.

El proceso de decodificación invierte estos pasos, excepto la cuantificación porque es irreversible. En el resto de esta sección, los procesos de codificación y decodificación se describen con más detalle.

Codificación

Muchas de las opciones del estándar JPEG no se usan con frecuencia y, como se mencionó anteriormente, la mayoría del software de imágenes usa el formato JFIF más simple al crear un archivo JPEG, que, entre otras cosas, especifica el método de codificación. Aquí hay una breve descripción de uno de los métodos de codificación más comunes cuando se aplica a una entrada que tiene 24 bits por píxel (ocho de rojo, verde y azul). Esta opción particular es un método de compresión de datos con pérdida.

Transformación del espacio de color

Primero, la imagen debe convertirse de RGB (por defecto, sRGB, pero son posibles otros espacios de color) a un espacio de color diferente llamado Y′CBCR (o, informalmente, YCbCr). Tiene tres componentes Y', CB y CR: el Y' representa el brillo de un píxel, y los componentes CB y CR representan la crominancia (dividida en componentes azul y rojo). Este es básicamente el mismo espacio de color que se usa en la televisión digital en color, así como en el video digital, incluidos los DVD de video. La conversión del espacio de color Y′CBCR permite una mayor compresión sin un efecto significativo en la calidad de imagen perceptible (o mayor calidad de imagen perceptible para la misma compresión). La compresión es más eficiente porque la información de brillo, que es más importante para la eventual calidad de percepción de la imagen, se limita a un solo canal. Esto se corresponde más estrechamente con la percepción del color en el sistema visual humano. La transformación de color también mejora la compresión por decorrelación estadística.

En el estándar JFIF se especifica una conversión particular a Y′CBCR, y se debe realizar para que el archivo JPEG resultante tenga la máxima compatibilidad. Sin embargo, algunas implementaciones de JPEG en "calidad más alta" no aplique este paso y en su lugar mantenga la información de color en el modelo de color RGB, donde la imagen se almacena en canales separados para los componentes de brillo rojo, verde y azul. Esto da como resultado una compresión menos eficiente y probablemente no se usaría cuando el tamaño del archivo es especialmente importante.

Reducción de muestreo

Debido a las densidades de los receptores sensibles al color y al brillo en el ojo humano, los humanos pueden ver detalles considerablemente más finos en el brillo de una imagen (el componente Y') que en el tono y la saturación de color de una imagen (los componentes Cb y Cr). Usando este conocimiento, los codificadores pueden diseñarse para comprimir imágenes de manera más eficiente.

La transformación en el modelo de color Y′CBCR permite el siguiente paso habitual, que consiste en reducir la resolución espacial de los componentes Cb y Cr (llamada "reducción de resolución" o "submuestreo de croma"). Las proporciones en las que normalmente se realiza la reducción de resolución para las imágenes JPEG son 4:4:4 (sin reducción de resolución), 4:2:2 (reducción por un factor de 2 en la dirección horizontal) o (más comúnmente) 4:2: 0 (reducción por un factor de 2 en las direcciones horizontal y vertical). Para el resto del proceso de compresión, Y', Cb y Cr se procesan por separado y de manera muy similar.

División de bloques

Después del submuestreo, cada canal debe dividirse en bloques de 8×8. Según el submuestreo de croma, esto genera bloques de unidades codificadas mínimas (MCU) de tamaño 8 × 8 (4: 4: 4, sin submuestreo), 16 × 8 (4: 2: 2) o más comúnmente 16 × 16 (4: 2:0). En la compresión de video, las MCU se denominan macrobloques.

Si los datos de un canal no representan un número entero de bloques, el codificador debe llenar el área restante de los bloques incompletos con alguna forma de datos ficticios. Rellenar los bordes con un color fijo (por ejemplo, negro) puede crear artefactos de timbre a lo largo de la parte visible del borde; repetir los píxeles del borde es una técnica común que reduce (pero no necesariamente elimina) tales artefactos, y también se pueden aplicar técnicas de relleno de bordes más sofisticadas.

Transformada coseno discreta

La subimagen 8×8 muestra en escala gris de 8 bits

A continuación, cada bloque de 8 × 8 de cada componente (Y, Cb, Cr) se convierte en una representación en el dominio de la frecuencia mediante una transformada de coseno discreta (DCT) de tipo II normalizada y bidimensional. Consulte la cita 1 en transformada discreta del coseno. La DCT a veces se denomina "DCT tipo II" en el contexto de una familia de transformadas como en la transformada de coseno discreta, y la inversa correspondiente (IDCT) se denota como "tipo-III DCT".

Como ejemplo, una subimagen de 8 × 8 de 8 bits podría ser:

Antes de calcular el DCT del bloque 8×8, sus valores se desplazan de un rango positivo a uno centrado en cero. Para una imagen de 8 bits, cada entrada en el bloque original cae en el rango . El punto medio del rango (en este caso, el valor 128) se resta de cada entrada para producir un rango de datos centrado en cero, por lo que el rango modificado es . Este paso reduce los requisitos de rango dinámico en la etapa de procesamiento de DCT que sigue.

Este paso da como resultado los siguientes valores:

El DCT transforma un bloque 8×8 de valores de entrada a una combinación lineal de estos 64 patrones. Los patrones se denominan DCT bidimensional Funciones básicas, y los valores de salida se denominan transformar coeficientes. El índice horizontal es y el índice vertical .

El siguiente paso es tomar la DCT bidimensional, que viene dada por:

dónde

Si realizamos esta transformación en nuestra matriz anterior, obtenemos lo siguiente (redondeado a los dos dígitos más cercanos más allá del punto decimal):

Observe la entrada de la esquina superior izquierda con una magnitud bastante grande. Este es el coeficiente DC (también llamado componente constante), que define el tono básico para todo el bloque. Los 63 coeficientes restantes son los coeficientes AC (también llamados componentes alternos). La ventaja de DCT es su tendencia a agregar la mayor parte de la señal en una esquina del resultado, como se puede ver arriba. El siguiente paso de cuantificación acentúa este efecto y, al mismo tiempo, reduce el tamaño general de los coeficientes DCT, lo que da como resultado una señal que es fácil de comprimir de manera eficiente en la etapa de entropía.

La DCT aumenta temporalmente la profundidad de bits de los datos, ya que los coeficientes de la DCT de una imagen de 8 bits/componente requieren hasta 11 o más bits (según la fidelidad del cálculo de la DCT) para almacenarse. Esto puede obligar al códec a usar temporalmente números de 16 bits para contener estos coeficientes, duplicando el tamaño de la representación de la imagen en este punto; estos valores se reducen normalmente a valores de 8 bits mediante el paso de cuantificación. El aumento temporal de tamaño en esta etapa no es un problema de rendimiento para la mayoría de las implementaciones de JPEG, ya que, por lo general, solo una parte muy pequeña de la imagen se almacena en formato DCT completo en un momento dado durante el proceso de codificación o decodificación de la imagen.

Cuantificación

El ojo humano es bueno para ver pequeñas diferencias de brillo en un área relativamente grande, pero no tan bueno para distinguir la fuerza exacta de una variación de brillo de alta frecuencia. Esto permite reducir en gran medida la cantidad de información en los componentes de alta frecuencia. Esto se hace simplemente dividiendo cada componente en el dominio de la frecuencia por una constante para ese componente y luego redondeando al entero más cercano. Esta operación de redondeo es la única operación con pérdida en todo el proceso (aparte del submuestreo de croma) si el cálculo DCT se realiza con una precisión suficientemente alta. Como resultado de esto, suele ocurrir que muchos de los componentes de frecuencia más alta se redondean a cero, y muchos del resto se convierten en pequeños números positivos o negativos, que requieren muchos menos bits para ser representados.

Los elementos de la matriz de cuantización controlan la relación de compresión, y los valores más grandes producen una mayor compresión. Una matriz de cuantificación típica (para una calidad del 50% como se especifica en el estándar JPEG original) es la siguiente:

Los coeficientes DCT cuantificados se calculan con

Donde son los coeficientes DCT no cuantificados; es la matriz de cuantificación arriba; y es el coeficiente DCT cuantificado.

Usar esta matriz de cuantificación con la matriz de coeficientes DCT de arriba da como resultado:

Izquierda: se construye una imagen final de una serie de funciones de base. Derecha: cada una de las funciones de base DCT que componen la imagen, y el correspondiente coeficiente de ponderación. Medio: la función base, después de la multiplicación por el coeficiente: este componente se añade a la imagen final. Para la claridad, el macroblock 8×8 en este ejemplo es magnificado por 10x utilizando la interpolación bilineal.

Por ejemplo, usando −415 (el coeficiente DC) y redondeando al entero más cercano

Observe que la mayoría de los elementos de mayor frecuencia del subbloque (es decir, aquellos con una frecuencia espacial x o y mayor que 4) se cuantifican en cero valores.

Codificación de entropía

Ordenación de componentes de imagen JPEG

La codificación de entropía es una forma especial de compresión de datos sin pérdidas. Se trata de organizar los componentes de la imagen en un "zigzag" orden que emplea el algoritmo de codificación de longitud de ejecución (RLE) que agrupa frecuencias similares, inserta ceros de codificación de longitud y luego usa la codificación Huffman en lo que queda.

El estándar JPEG también permite, pero no requiere, que los decodificadores admitan el uso de codificación aritmética, que es matemáticamente superior a la codificación Huffman. Sin embargo, esta función rara vez se ha utilizado, ya que históricamente estaba cubierta por patentes que requerían licencias con regalías, y porque es más lenta de codificar y decodificar en comparación con la codificación Huffman. La codificación aritmética generalmente hace que los archivos sean entre un 5% y un 7% más pequeños.

El coeficiente de CC cuantificado anterior se utiliza para predecir el coeficiente de CC cuantificado actual. La diferencia entre los dos está codificada en lugar del valor real. La codificación de los 63 coeficientes AC cuantificados no utiliza dicha diferenciación de predicción.

La secuencia en zigzag para los coeficientes cuantificados anteriores se muestra a continuación. (El formato que se muestra es solo para facilitar la comprensión/visualización).

−26
−30
−3−2−6
2−41−3
11512
−11−1200
000−1−100
00000000
0000000
000000
00000
0000
000
00
0

Si i- el bloque está representado por y las posiciones dentro de cada bloque están representadas por Donde y , entonces cualquier coeficiente en la imagen DCT puede ser representado como . Así, en el esquema anterior, el orden de los píxeles de codificación (para el i-th block) , , , , , , , y así sucesivamente.

Base de referencia secuencia Procesos de codificación y decodificación de JPEG

Este modo de codificación se denomina base de referencia secuencial Codificación. Base de referencia JPEG también admite progresivo Codificación. Mientras que la codificación secuencial codifica coeficientes de un solo bloque a la vez (de una manera zigzag), códigos de codificación progresivos lote de coeficientes de todos los bloques en una sola marcha (llamado un Escaneos), seguido por el próximo lote de coeficientes de todos los bloques, y así sucesivamente. Por ejemplo, si la imagen se divide en bloques N 8×8 , entonces un componente de codificación progresiva 3-scan códigos DC, para todos los bloques, es decir, para todos En el primer escaneo. Esto es seguido por el segundo escaneo que encogía algunos componentes más (asumiendo cuatro componentes más, son a , todavía de manera zigzag) coeficientes de todos los bloques (por lo que la secuencia es: ), seguido de todos los coeficientes restantes de todos los bloques en el último escaneo.

Una vez que se hayan codificado todos los coeficientes con posiciones similares, la siguiente posición que se codificará es la siguiente en el recorrido en zigzag como se indica en la figura anterior. Se ha descubierto que la codificación JPEG progresiva de línea de base generalmente brinda una mejor compresión en comparación con JPEG secuencial de línea de base debido a la capacidad de usar diferentes tablas de Huffman (ver a continuación) adaptadas para diferentes frecuencias. en cada "escaneo" o "pasar" (que incluye coeficientes de posición similar), aunque la diferencia no es demasiado grande.

En el resto del artículo, se supone que el patrón de coeficientes generado se debe al modo secuencial.

Para codificar el patrón de coeficientes generado anteriormente, JPEG utiliza la codificación Huffman. El estándar JPEG proporciona tablas de Huffman de propósito general; los codificadores también pueden optar por generar tablas de Huffman optimizadas para las distribuciones de frecuencia reales en las imágenes que se codifican.

El proceso de codificación de los datos cuantificados en zig-zag comienza con una codificación de longitud de ejecución que se explica a continuación, donde:

La codificación de longitud de ejecución funciona examinando cada coeficiente AC distinto de cero x y determinando cuántos ceros hay antes del anterior Coeficiente CA. Con esta información, se crean dos símbolos:

Signatura 1Signatura 2
(RUNLENGTH, SIZE)(AMPLITUDE)

Tanto RUNLENGTH como SIZE descansan en el mismo byte, lo que significa que cada uno solo contiene cuatro bits de información. Los bits superiores se ocupan de la cantidad de ceros, mientras que los bits inferiores indican la cantidad de bits necesarios para codificar el valor de x.

Esto tiene la implicación inmediata de que el Símbolo 1 solo puede almacenar información sobre los primeros 15 ceros que preceden al coeficiente AC distinto de cero. Sin embargo, JPEG define dos palabras de código Huffman especiales. Uno es para finalizar la secuencia prematuramente cuando los coeficientes restantes son cero (llamado "Fin de bloque" o "EOB"), y otro cuando la serie de ceros va más allá de 15 antes de alcanzar un coeficiente AC distinto de cero. En tal caso, donde se encuentran 16 ceros antes de un coeficiente AC distinto de cero, el Símbolo 1 se codifica como "especialmente" como: (15, 0)(0).

El proceso general continúa hasta que "EOB" – denotado por (0, 0) – se alcanza.

Con esto en mente, la secuencia anterior se convierte en:

(0, 2)(-3);(1, 2)(-3);(0, 1)(-2);(0, 2)(-6);(0, 1) 2);(0, 1)(-4);(0, 1) 1);(0, 2)(-3);(0, 1) 1) 1);(0, 1) 1) 1) 1);
(0, 2)(5);(0, 1) 1);(0, 1) 2);(0, 1)(-1);(0, 1)(1);(0, 1)(-1);(0, 1) 2);(5, 1)(-1);(0, 1)(-1);(0, 0);(0, 0);

(El primer valor en la matriz, −26, es el coeficiente DC; no está codificado de la misma manera. Ver arriba).

Desde aquí, los cálculos de frecuencia se realizan en función de las ocurrencias de los coeficientes. En nuestro bloque de ejemplo, la mayoría de los coeficientes cuantificados son números pequeños que no van precedidos inmediatamente por un coeficiente cero. Estos casos más frecuentes estarán representados por palabras clave más cortas.

Relación de compresión y artefactos

Esta imagen muestra los píxeles que son diferentes entre una imagen no comprimida y la misma imagen JPEG comprimido con un ajuste de calidad de 50. Más oscuro significa una diferencia más grande. Tenga en cuenta especialmente los cambios que ocurren cerca de bordes afilados y tener una forma similar al bloque.
La imagen original
Los 8×8 cuadrados comprimidos son visibles en la imagen escalada, junto con otros artefactos visuales de la compresión perdida.

La relación de compresión resultante se puede variar según las necesidades siendo más o menos agresivos en los divisores utilizados en la fase de cuantificación. La compresión de diez a uno generalmente da como resultado una imagen que no se puede distinguir a simple vista del original. Por lo general, es posible una relación de compresión de 100:1, pero se verá claramente alterada en comparación con el original. El nivel de compresión adecuado depende del uso que se vaya a dar a la imagen.

Quienes usan la World Wide Web pueden estar familiarizados con las irregularidades conocidas como artefactos de compresión que aparecen en las imágenes JPEG, que pueden tomar la forma de ruido alrededor de los bordes contrastantes (especialmente curvas y esquinas) o "bloques" 34; imágenes Estos se deben al paso de cuantificación del algoritmo JPEG. Se notan especialmente alrededor de las esquinas afiladas entre colores contrastantes (el texto es un buen ejemplo, ya que contiene muchas de esas esquinas). Los artefactos análogos en el video MPEG se conocen como ruido de mosquito como el "ocupación de borde" y puntos espurios, que cambian con el tiempo, se asemejan a mosquitos que pululan alrededor del objeto.

Estos artefactos se pueden reducir eligiendo un nivel más bajo de compresión; se pueden evitar por completo guardando una imagen con un formato de archivo sin pérdidas, aunque esto dará como resultado un tamaño de archivo más grande. Las imágenes creadas con programas de trazado de rayos tienen formas de bloques notables en el terreno. Ciertos artefactos de compresión de baja intensidad pueden ser aceptables cuando simplemente se ven las imágenes, pero se pueden enfatizar si la imagen se procesa posteriormente, lo que generalmente da como resultado una calidad inaceptable. Considere el siguiente ejemplo, que demuestra el efecto de la compresión con pérdida en un paso de procesamiento de detección de bordes.

ImagenCompresión sin pérdidasCompresión perdida
Original Lossless-circle.pngLossy-circle.jpg
Procesado por
Detector de bordes Canny
Lossless-circle-canny.pngLossy-circle-canny.png

Algunos programas permiten al usuario variar la cantidad en la que se comprimen los bloques individuales. Se aplica una compresión más fuerte a las áreas de la imagen que muestran menos artefactos. De esta forma, es posible reducir manualmente el tamaño del archivo JPEG con menos pérdida de calidad.

Dado que la etapa de cuantificación siempre resulta en una pérdida de información, el estándar JPEG siempre es un códec de compresión con pérdida. (La información se pierde tanto en la cuantificación como en el redondeo de los números de punto flotante). Incluso si la matriz de cuantificación es una matriz de unos, la información aún se perderá en el paso de redondeo.

Decodificación

La decodificación para mostrar la imagen consiste en hacer todo lo anterior a la inversa.

Tomando la matriz del coeficiente DCT (después de volver a sumar la diferencia del coeficiente DC)

y tomando el producto de entrada por entrada con la matriz de cuantificación de arriba da como resultado

que se parece mucho a la matriz de coeficiente DCT original para la parte superior izquierda.

El siguiente paso es tomar la DCT inversa bidimensional (una DCT 2D tipo III), que viene dada por:

dónde

Redondear la salida a valores enteros (ya que el original tenía valores enteros) da como resultado una imagen con valores (todavía desplazada hacia abajo en 128)

Las diferencias de luz son notables entre la imagen original (top) y descomprimida (abajo), que se ve más fácilmente en la esquina inferior izquierda.

y agregando 128 a cada entrada

Este es el subimage descomprimido. En general, el proceso de descompresión puede producir valores fuera del rango de entrada original . Si esto ocurre, el decodificador necesita cortar los valores de salida para mantenerlos dentro de ese rango para evitar el desbordamiento al almacenar la imagen descomprimida con la profundidad de bit original.

La subimagen descomprimida se puede comparar con la subimagen original (vea también las imágenes a la derecha) tomando la diferencia (original − sin comprimir) que da como resultado los siguientes valores de error:

con un error promedio absoluto de unos 5 valores por pixels (es decir, ).

El error es más notorio en la esquina inferior izquierda, donde el píxel inferior izquierdo se vuelve más oscuro que el píxel inmediatamente a la derecha.

Precisión requerida

La precisión de implementación requerida de un códec JPEG se define implícitamente a través de los requisitos formulados para el cumplimiento del estándar JPEG. Estos requisitos se especifican en la Recomendación UIT.T T.83 | ISO/CEI 10918-2. A diferencia de los estándares MPEG y muchos estándares JPEG posteriores, el documento anterior define las precisiones de implementación requeridas para el proceso de codificación y decodificación de un códec JPEG por medio de un error tolerable máximo de la DCT directa e inversa en el dominio DCT según lo determinado por la prueba de referencia. arroyos Por ejemplo, la salida de la implementación de un decodificador no debe exceder un error de una unidad de cuantificación en el dominio DCT cuando se aplica a los trenes de código de prueba de referencia proporcionados como parte del estándar anterior. Si bien es inusual y, a diferencia de muchos otros estándares más modernos, ITU.T T.83 | ISO/IEC 10918-2 no formula límites de error en el dominio de la imagen.

Efectos de la compresión JPEG

Los artefactos de compresión JPEG se combinan bien en fotografías con texturas no uniformes detalladas, lo que permite relaciones de compresión más altas. Observe cómo una relación de compresión más alta afecta primero las texturas de alta frecuencia en la esquina superior izquierda de la imagen y cómo las líneas contrastantes se vuelven más borrosas. La relación de compresión muy alta afecta gravemente a la calidad de la imagen, aunque los colores generales y la forma de la imagen siguen siendo reconocibles. Sin embargo, la precisión de los colores sufre menos (para el ojo humano) que la precisión de los contornos (basada en la luminancia). Esto justifica el hecho de que las imágenes deban transformarse primero en un modelo de color separando la luminancia de la información cromática, antes de submuestrear los planos cromáticos (que también pueden utilizar una cuantificación de menor calidad) para preservar la precisión del plano de luminancia con más bits de información..

Fotografías de muestra

Impacto visual de una compresión de jpeg en Photoshop en una imagen de 4480x4480 píxeles

Para obtener información, la siguiente imagen de mapa de bits RGB de 24 bits sin comprimir (73 242 píxeles) requeriría 219 726 bytes (sin incluir todos los demás encabezados de información). Los archivos de archivo que se indican a continuación incluyen los encabezados de información JPEG internos y algunos metadatos. Para imágenes de la más alta calidad (Q=100), se requieren alrededor de 8,25 bits por píxel de color. En imágenes en escala de grises, un mínimo de 6,5 bits por píxel es suficiente (una información de color de calidad Q=100 comparable requiere alrededor de un 25 % más de bits codificados). La imagen de mayor calidad a continuación (Q=100) está codificada a nueve bits por píxel de color, la imagen de calidad media (Q=25) utiliza un bit por píxel de color. Para la mayoría de las aplicaciones, el factor de calidad no debería ser inferior a 0,75 bits por píxel (Q=12,5), como lo demuestra la imagen de baja calidad. La imagen con la calidad más baja utiliza solo 0,13 bits por píxel y muestra un color muy pobre. Esto es útil cuando la imagen se mostrará en un tamaño significativamente reducido. En Minguillón & Pujol (2001).

Nota: Las imágenes anteriores no son imágenes de prueba IEEE / CCIR / EBU, y los ajustes de codificación no están especificados o disponibles.
ImagenCalidadTamaño (bytes)Tasa de compresiónComentario
JPEG example JPG RIP 100.jpgCalidad más alta (Q = 100) 81.447 2.7:1 Artefactos extremadamente menores
JPEG example JPG RIP 050.jpgAlta calidad (Q = 50) 14,679 15:1 Signos iniciales de artefactos subimage
JPEG example JPG RIP 025.jpgCalidad media (Q = 25) 9.407 23:1 artefactos más fuertes; pérdida de información de alta frecuencia
JPEG example JPG RIP 010.jpgBaja calidad (Q = 10) 4.787 46:1 La pérdida severa de alta frecuencia conduce a artefactos obvios en los límites de subimage ("macroblocking")
JPEG example JPG RIP 001.jpgCalidad más baja (Q = 1) 1,523 144:1 Extrema pérdida de color y detalle; las hojas son casi irreconocibles.

La foto de calidad media usa solo el 4,3% del espacio de almacenamiento requerido para la imagen sin comprimir, pero tiene poca pérdida de detalles o artefactos visibles. Sin embargo, una vez que se pasa un cierto umbral de compresión, las imágenes comprimidas muestran defectos cada vez más visibles. Consulte el artículo sobre la teoría de la distorsión de la velocidad para obtener una explicación matemática de este efecto de umbral. Una limitación particular de JPEG en este sentido es su estructura de transformación de bloque 8×8 no superpuesta. Los diseños más modernos, como JPEG 2000 y JPEG XR, exhiben una degradación de la calidad más elegante a medida que disminuye el uso de bits mediante el uso de transformaciones con una mayor extensión espacial para los coeficientes de frecuencia más bajos y mediante el uso de funciones de base de transformación superpuestas.

Compresión adicional sin pérdidas

De 2004 a 2008, surgieron nuevas investigaciones sobre formas de comprimir aún más los datos contenidos en imágenes JPEG sin modificar la imagen representada. Esto tiene aplicaciones en escenarios donde la imagen original solo está disponible en formato JPEG y su tamaño debe reducirse para archivarse o transmitirse. Las herramientas estándar de compresión de propósito general no pueden comprimir significativamente los archivos JPEG.

Por lo general, estos esquemas aprovechan las mejoras del esquema ingenuo para codificar los coeficientes DCT, que no tiene en cuenta:

Ya existen algunas opciones estándar pero poco utilizadas en JPEG para mejorar la eficiencia de la codificación de coeficientes DCT: la opción de codificación aritmética y la opción de codificación progresiva (que produce tasas de bits más bajas porque los valores para cada coeficiente se codifican de forma independiente y cada coeficiente tiene una distribución significativamente diferente). Los métodos modernos han mejorado estas técnicas al reordenar los coeficientes para agrupar los coeficientes de mayor magnitud; usar coeficientes y bloques adyacentes para predecir nuevos valores de coeficiente; dividir bloques o coeficientes entre un pequeño número de modelos codificados de forma independiente en función de sus estadísticas y valores adyacentes; y más recientemente, decodificando bloques, prediciendo bloques subsiguientes en el dominio espacial y luego codificándolos para generar predicciones para coeficientes DCT.

Por lo general, estos métodos pueden comprimir archivos JPEG existentes entre un 15 y un 25 por ciento, y para archivos JPEG comprimidos con configuraciones de baja calidad, pueden producir mejoras de hasta un 65%.

Una herramienta disponible gratuitamente llamada packJPG se basa en el documento de 2007 "Reducción de redundancia mejorada para archivos JPEG"

Formatos derivados para 3D estereoscópico

JPEG estereoscópico

Un ejemplo de estereoscópico. Archivo JPS

JPS es una imagen JPEG estereoscópica que se utiliza para crear efectos 3D a partir de imágenes 2D. Contiene dos imágenes estáticas, una para el ojo izquierdo y otra para el ojo derecho; codificado como dos imágenes una al lado de la otra en un solo archivo JPG. JPEG estereoscópico (JPS, extension.jps) es un formato basado en JPEG para imágenes estereoscópicas. Tiene una gama de configuraciones almacenadas en el campo de marcador JPEG APP3, pero generalmente contiene una imagen de doble ancho, que representa dos imágenes de tamaño idéntico en el lado bizco (es decir, el marco izquierdo en la mitad derecha de la imagen y viceversa). arreglo por lado. Este formato de archivo se puede ver como JPEG sin ningún software especial, o se puede procesar para renderizar en otros modos.

Formato de varias imágenes JPEG

El formato de varias imágenes JPEG (MPO, extension.mpo) es un formato basado en JPEG para almacenar varias imágenes en un solo archivo. Contiene dos o más archivos JPEG concatenados entre sí. También define un segmento de marcador JPEG APP2 para la descripción de la imagen. Varios dispositivos lo utilizan para almacenar imágenes en 3D, como Fujifilm FinePix Real 3D W1, HTC Evo 3D, JVC GY-HMZ1U videocámara de extensión AVCHD/MVC, Nintendo 3DS, Panasonic Lumix DMC-TZ20, DMC-TZ30, DMC-TZ60, DMC- TS4 (FT4) y Sony DSC-HX7V. Otros dispositivos lo usan para almacenar "imágenes de vista previa" que se puede mostrar en un televisor.

En los últimos años, debido al creciente uso de imágenes estereoscópicas, la comunidad científica se ha esforzado mucho por desarrollar algoritmos para la compresión de imágenes estereoscópicas.

Implementaciones

Una implementación muy importante de un códec JPEG es la biblioteca de programación gratuita libjpeg de Independent JPEG Group. Se publicó por primera vez en 1991 y fue clave para el éxito de la norma. Esta biblioteca o un derivado directo de la misma se utiliza en innumerables aplicaciones. Las versiones recientes introdujeron extensiones propietarias, rompiendo la compatibilidad ABI con versiones anteriores y que no están cubiertas por el estándar ITU|ISO/IEC.

En marzo de 2017, Google lanzó el proyecto de código abierto Guetzli, que compensa un tiempo de codificación mucho más largo por un tamaño de archivo más pequeño (similar a lo que hace Zopfli con PNG y otros formatos de datos sin pérdidas).

UIT|ISO/IEC formalizó implementaciones de referencia JPEG en la Recomendación ITU-T T.873 | ISO/IEC 10918-7 en 2021.

El grupo conjunto de expertos en fotografía de ISO/IEC mantiene una de las dos implementaciones de software de referencia que pueden codificar JPEG base (ISO/IEC 10918-1 y 18477–1) y extensiones JPEG XT (ISO/IEC 18477 Partes 2 y 6– 9), así como JPEG-LS (ISO/IEC 14495).

Una segunda implementación de referencia es libJPEG-turbo, que es un derivado de la implementación JPEG del Grupo JPEG Independiente ajustado hacia un alto rendimiento y cumplimiento del estándar JPEG.

JPEGXT

JPEG XT (ISO/IEC 18477) se publicó en junio de 2015; amplía el formato JPEG base con soporte para profundidades de bits enteros más altas (hasta 16 bits), imágenes de alto rango dinámico y codificación de punto flotante, codificación sin pérdidas y codificación de canal alfa. Las extensiones son compatibles con el formato de archivo base JPEG/JFIF y la imagen comprimida con pérdida de 8 bits. JPEG XT utiliza un formato de archivo extensible basado en JFIF. Las capas de extensión se utilizan para modificar la capa base JPEG de 8 bits y restaurar la imagen de alta resolución. El software existente es compatible con versiones posteriores y puede leer el flujo binario JPEG XT, aunque solo decodificaría la capa base de 8 bits.

JPEGXL

Desde agosto de 2017, JTC1/SC29/WG1 emitieron una serie de borradores de convocatorias de propuestas sobre JPEG XL, el estándar de compresión de imágenes de próxima generación con una eficiencia de compresión sustancialmente mejor (60 % de mejora) en comparación con JPEG. Se espera que el estándar supere el rendimiento de compresión de imágenes fijas mostrado por HEVC HM, Daala y WebP y, a diferencia de los esfuerzos anteriores que intentaron reemplazar JPEG, proporcione una opción de transporte y almacenamiento de recompresión más eficiente y sin pérdidas para las imágenes JPEG tradicionales. Los requisitos básicos incluyen soporte para imágenes de muy alta resolución (al menos 40 MP), 8–10 bits por componente, codificación de color RGB/YCbCr/ICtCp, imágenes animadas, codificación de canal alfa, Rec. 709 espacio de color (sRGB) y función gamma (2.4-power), Rec. Espacio de color de amplia gama de colores 2100 (Rec. 2020) y funciones de transferencia de alto rango dinámico (PQ y HLG), y compresión de alta calidad de imágenes sintéticas, como fuentes de mapa de bits y degradados. El estándar también debería ofrecer profundidades de bits más altas (entero de 12 a 16 bits y punto flotante), espacios de color adicionales y funciones de transferencia (como Log C de Arri), imágenes de vista previa incrustadas, codificación de canal alfa sin pérdidas, codificación de región de imagen y baja codificación de complejidad. Cualquier tecnología patentada se licenciaría sin regalías. Las propuestas se presentaron en septiembre de 2018, lo que llevó a un borrador del comité en julio de 2019, con formato de archivo y sistema de codificación central que se estandarizaron formalmente el 13 de octubre de 2021 y el 30 de marzo de 2022, respectivamente.