stringtranslate.com

JPEG

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

JPEG ( / ˈ p ɛ ɡ / JAY -peg , abreviatura de Joint Photographic Experts Group ) [2] es un método comúnmente utilizado 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 equilibrio seleccionable entre el tamaño de almacenamiento y la calidad de la imagen . JPEG normalmente logra una compresión de 10:1 con una pérdida poco perceptible en la calidad de la imagen. [3] Desde su introducción en 1992, JPEG ha sido el estándar de compresión de imágenes más utilizado en el mundo, [4] [5] y el formato de imagen digital más utilizado , con varios miles de millones de imágenes JPEG producidas cada día a partir de 2015. [6]

El Grupo Conjunto de Expertos en Fotografía creó el estándar en 1992. [7] JPEG fue en gran medida responsable de la proliferación de imágenes y fotografías digitales en Internet y más tarde en las redes sociales . [8] [ referencia circular ] La compresión JPEG se utiliza en varios formatos de archivos de imágenes . 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 . [9] Estas variaciones de formato a menudo no se distinguen y simplemente se denominan JPEG.

El tipo de medio MIME para JPEG es "imagen/jpeg", excepto en versiones anteriores de Internet Explorer , que proporcionan un tipo MIME de "imagen/pjpeg" al cargar imágenes JPEG. [10] Los archivos JPEG normalmente tienen una extensión de nombre de "jpg" o "jpeg". JPEG/JFIF admite un tamaño de imagen máximo de 65.535 × 65.535 píxeles, [11] por lo tanto, hasta 4 gigapíxeles para una relación de aspecto de 1:1. En 2000, el grupo JPEG introdujo un formato que pretendía ser su sucesor, JPEG 2000 , pero no pudo reemplazar al JPEG original como estándar de imagen dominante. [12]

Historia

Fondo

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 Joint Photographic Experts Group. [1]

La especificación JPEG cita patentes de varias empresas. Las siguientes patentes proporcionaron la base para su algoritmo de codificación aritmética . [1]

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. [1] Ausente en la lista está la patente estadounidense 4.698.672 , presentada por Wen-Hsiung Chen y Daniel J. Klenke de Compression Labs en octubre de 1986. La patente describe una Algoritmo de compresión de imágenes basado en DCT, y luego sería motivo de controversia en 2002 (ver Controversia de patentes a continuación). [13] Sin embargo, la especificación JPEG cita dos artículos de investigación anteriores de Wen-Hsiung Chen, publicados en 1977 y 1984. [1]

estándar JPEG

"JPEG" significa Grupo Conjunto de Expertos Fotográficos , el nombre del comité que creó el estándar JPEG y también otros estándares de codificación de imágenes fijas. La "Conjunta" significaba ISO TC97 WG8 y CCITT SGVIII. Fundado en 1986, el grupo desarrolló el estándar JPEG a finales de los años 80. El grupo publicó el estándar JPEG en 1992. [4]

En 1987, ISO TC 97 se convirtió en ISO/IEC JTC 1 y, en 1992, el 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), titulado Codificación de imágenes fijas . [14] [15] [16] Por parte del UIT-T, la CE 16 del UIT-T es el organismo respectivo. El Grupo JPEG original se organizó en 1986, [17] emitiendo el primer estándar JPEG en 1992, que fue aprobado en septiembre de 1992 como Recomendación UIT-T T.81 [18] 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. [19] Los estándares Exif y JFIF definen los formatos de archivo comúnmente utilizados para el intercambio de imágenes comprimidas JPEG.

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

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

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 había sido presentada el 27 de octubre de 1986 y concedida el 6 de octubre de 1987: patente estadounidense 4.698.672 de Wen- Hsiung Chen y Daniel J. Klenke. [13] [24] 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. [13] El anuncio de Forgent en 2002 creó un furor que recuerda a los intentos de Unisys de hacer valer sus derechos sobre el estándar de compresión de imágenes GIF.

El comité JPEG investigó las reivindicaciones de patente en 2002 y opinó que estaban invalidadas por el estado de la técnica , [25] una opinión compartida por varios expertos. [13] [26]

Entre 2002 y 2004, Forgent pudo obtener alrededor de 105 millones de dólares mediante la concesión de licencias de su patente a unas 30 empresas. En abril de 2004, Forgent demandó a otras 31 empresas para exigir pagos adicionales de licencias. 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 separada contra Forgent en abril de 2005. [27] En febrero de 2006, la Oficina de Patentes y Marcas de Estados Unidos acordó reexaminar la patente JPEG de Forgent a solicitud de la Public Patent Foundation. [28] 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 encontró que Forgent conocía el estado de la técnica, pero evitó intencionalmente informar a la Oficina de Patentes. Esto hace que sea muy poco probable que cualquier recurso para restablecer la patente tenga éxito. [29]

Forgent también posee una patente similar concedida por la Oficina Europea de Patentes en 1994, aunque no está claro qué tan ejecutable es. [30]

El 27 de octubre de 2006, el plazo de 20 años de la patente estadounidense 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. [31]

El comité JPEG tiene como uno de sus objetivos explícitos que sus estándares (en particular sus métodos básicos) sean implementables sin el pago de derechos de licencia, y ha obtenido los derechos de licencia adecuados 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 estadounidense 5.253.341 ), emitida en 1993, se infringe por la descarga de imágenes JPEG en un sitio web o por correo electrónico. Si no se invalida, esta patente podría aplicarse a cualquier sitio web que muestre imágenes JPEG. La patente estuvo bajo reexamen por parte de la Oficina de Patentes y Marcas de EE. UU. de 2000 a 2007; En julio de 2007, la Oficina de Patentes revocó todas las reivindicaciones originales de la patente, pero determinó que una reivindicación adicional propuesta por Global Patent Holdings (reivindicación 17) era válida. [32] Global Patent Holdings luego presentó una serie de demandas basadas en la reivindicación 17 de su patente.

En sus dos primeras demandas tras el reexamen, ambas presentadas en Chicago, Illinois, Global Patent Holdings demandó a los 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 buscaba una declaración judicial de que la patente '341 no es válida y no ha sido infringida.

Global Patent Holdings también había utilizado la patente '341 para demandar o amenazar a los críticos abiertos de las patentes de software en general, incluido Gregory Aharonian [33] y el operador anónimo de un blog web conocido como " Patent Troll Tracker ". [34] El 21 de diciembre de 2007, el abogado de patentes Vernon Francissen de Chicago pidió a la Oficina de Patentes y Marcas de Estados Unidos que reexaminara la única reivindicación restante de la patente '341 sobre la base del nuevo estado de la técnica. [35]

El 5 de marzo de 2008, la Oficina de Patentes y Marcas de EE. UU. acordó reexaminar la patente '341 y descubrió que el nuevo estado de la técnica planteaba nuevas cuestiones sustanciales con respecto a la validez de la patente. [36] A la luz del nuevo examen, los infractores acusados ​​en cuatro de los cinco juicios 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 de EE.UU. El 23 de abril de 2008, un juez que presidía las dos demandas en Chicago, Illinois, aceptó las mociones en esos casos. [37] El 22 de julio de 2008, la Oficina de Patentes emitió la primera "Acción de Oficina" del segundo reexamen, determinando que la reclamación era inválida basándose en diecinueve motivos distintos. [38] El 24 de noviembre de 2009, se emitió un Certificado de Reexamen cancelando todas las reclamaciones.

A partir de 2011 y a principios de 2013, una entidad conocida como Princeton Digital Image Corporation, [39] con sede en el este de Texas, comenzó a demandar a un gran número de empresas por supuesta infracción de la patente estadounidense 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 originalmente era propiedad de General Electric y estaba asignada a ella. La patente expiró en diciembre de 2007, pero Princeton ha demandado a un gran número de empresas por "infracción pasada" 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). En marzo de 2013, Princeton tenía demandas 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 conserva ciertos derechos sobre la patente. [40]

Uso típico

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

Sin embargo, JPEG no es muy adecuado para dibujos lineales y otros gráficos textuales o icónicos, donde los fuertes contrastes entre píxeles adyacentes pueden provocar artefactos notables. Es mejor guardar estas imágenes en un formato de gráficos sin pérdidas, como TIFF , GIF , PNG o un formato de imagen sin formato . 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 , lo 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 parte de la calidad de la imagen se pierde cada vez que se recomprime la imagen, particularmente si la imagen se recorta o se desplaza, o si se cambian los parámetros de codificación; consulte Pérdida de generación digital para obtener más detalles. Para evitar la pérdida de información de la imagen durante la edición secuencial y repetitiva, la primera edición se puede guardar en un formato sin pérdidas, editarse posteriormente 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 discreto (DCT). Esta operación matemática convierte cada cuadro/campo de la fuente de vídeo 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 la información de alta frecuencia, es decir, transiciones bruscas de intensidad y tono de color. En el dominio de la transformación, el proceso de reducción de información se llama cuantificación. En términos más simples, la cuantificación es un método para reducir de manera óptima una escala de números grandes (con diferentes apariciones de cada número) a 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 Para el panorama general que otros coeficientes, se caracterizan por ser valores pequeños con alta compresibilidad. Luego, los coeficientes cuantificados se secuencian y se 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 le permite intercambiar calidad de 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 están preseleccionados y fijos para la aplicación.

El método de compresión suele tener pérdida , 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 múltiples pasadas con detalles progresivamente mayores. Esto es ideal para imágenes grandes que se mostrarán mientras se descargan a través de una conexión lenta, permitiendo 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 ) [41], el software muestra la imagen sólo después de que se haya descargado por completo.

También existen muchas aplicaciones de imágenes médicas, tráfico y cámaras 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. [42]

Edición sin pérdidas

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

Los bloques se pueden rotar 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 imagen modificada.

Los bordes superior e izquierdo de una imagen JPEG deben estar en un límite de bloque de 8 × 8 píxeles (o 16 × 16 píxeles para tamaños de MCU más grandes), 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 volteos y rotaciones de una imagen cuyo borde inferior o derecho no se encuentre 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 el límite del bloque es obligatorio).

Las rotaciones en las que la imagen no es múltiplo de 8 o 16, cuyo valor depende del submuestreo de croma, no son sin pérdidas. Al girar una imagen de este tipo, los bloques se vuelven a calcular, lo que provoca una pérdida de calidad. [43]

Cuando se utiliza el recorte sin pérdidas, si el lado inferior o derecho de la región de recorte no está en el límite de un bloque, el resto de los datos de los bloques utilizados parcialmente seguirán presentes en el archivo recortado y se podrán recuperar. También es posible transformar entre formato básico 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, se pueden unir varias imágenes JPEG sin pérdidas, siempre que se hayan guardado con la misma calidad y los bordes coincidan con los límites de los bloques.

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 formato de archivo "puro" rara vez se utiliza, 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 varias normas adicionales para abordar estas cuestiones. 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 archivos de imágenes intercambiables (Exif) y los perfiles de color ICC . Ambos formatos utilizan el diseño de bytes JIF real, que consta de 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 se dejaron 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, en algunos aspectos, 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 otros aspectos, es una extensión de JIF debido a la adición de metadatos. La documentación del estándar JFIF original establece: [44]

El formato de intercambio de archivos JPEG es un formato de archivo mínimo que permite intercambiar flujos de bits JPEG entre una amplia variedad de plataformas y aplicaciones. Este formato mínimo no incluye ninguna de las funciones avanzadas que se encuentran en la especificación TIFF JPEG ni ningún formato de archivo específico de la aplicación. Tampoco debería hacerlo, ya que 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 generan JPEG en realidad crean 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 de los programas de edición de imágenes almacenan JPEG en formato JFIF y también incluyen el segmento APP1 del archivo Exif para incluir los metadatos de forma casi compatible; El estándar JFIF se interpreta con cierta flexibilidad. [45]

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 de marcador JFIF que precede al encabezado Exif. Esto permite a los lectores más antiguos manejar 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 .jpgy .jpeg, aunque .jpe, .jfify .jiftambién se utilizan. [46] También es posible que los datos JPEG estén incrustados en otros tipos de archivos: los archivos codificados en TIFF a menudo incrustan una imagen JPEG como una miniatura de la imagen principal; y los archivos MP3 pueden contener un JPEG de la portada en la etiqueta ID3v2 .

perfil de color

Muchos archivos JPEG incorporan un perfil de color ICC ( espacio de color ). Los perfiles de color más utilizados incluyen sRGB y Adobe RGB . Debido a que estos espacios de color utilizan 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 información de perfil de color ( sin etiquetar ), se supone que el espacio de color es sRGB para fines de visualización en páginas web. [47] [48]

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 constan sólo de esos dos bytes; a otros les siguen dos bytes (alto y luego bajo), que indican la longitud de los datos de carga útil específicos del marcador que siguen. (La longitud incluye los dos bytes de longitud, pero no los dos bytes del marcador). Algunos marcadores van seguidos de datos codificados por 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 realizarse para los marcadores inmediatamente después de los datos de escaneo codificados por entropía (consulte la sección 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 añaden 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 parezca haber un marcador donde no se pretende ninguno, lo que evita errores de encuadre. 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 del marcador. 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 por entropía para permitir la decodificación paralela, y los codificadores son libres de insertar estos marcadores de reinicio a intervalos regulares (aunque no todos los codificadores lo hacen).

Hay otros marcadores de Inicio de fotograma que introducen otros tipos de codificaciones JPEG.

Dado que varios proveedores pueden utilizar el mismo tipo de marcador APP n , 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 una transmisión a través de una red no confiable o 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 que se realice con 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′C B C R , que consta de un componente luma (Y'), que representa el brillo, y dos componentes croma (C B y C R ), que representan el color. A veces se omite este paso.
  2. La resolución de los datos cromáticos se reduce, normalmente en un factor de 2 o 3. Esto refleja el hecho de que el ojo es menos sensible a los detalles finos de color que a los detalles finos de brillo.
  3. La imagen se divide en bloques de 8 × 8 píxeles y, para cada bloque, cada uno de los datos Y, C B y C R se somete a la transformada de coseno discreto (DCT). Una DCT es similar a una transformada de Fourier en el sentido de que produce una especie de espectro de frecuencia espacial.
  4. Las amplitudes de los componentes de frecuencia están cuantificadas . La visión humana es mucho más sensible a pequeñas variaciones de color o brillo en áreas grandes que a la intensidad de las variaciones de brillo de alta frecuencia. Por lo tanto, las magnitudes de los componentes de alta frecuencia se almacenan con menor precisión que las componentes de baja frecuencia. La configuración de calidad del codificador (por ejemplo, 50 o 95 en una escala de 0 a 100 en la biblioteca del Independent JPEG Group [50] ) afecta hasta qué punto se reduce la resolución de cada componente de frecuencia. Si se utiliza un ajuste de calidad demasiado bajo, los componentes de alta frecuencia se descartan por completo.
  5. Los datos resultantes para todos los bloques de 8×8 se comprimen aún más con un algoritmo sin pérdidas, una variante de la 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 utilizan habitualmente y, como se mencionó anteriormente, la mayoría del software de imágenes utiliza el formato JFIF más simple al crear un archivo JPEG, que, entre otras cosas, especifica el método de codificación. A continuación se ofrece 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, [47] [48] pero son posibles otros espacios de color ) a un espacio de color diferente llamado Y′C B C R (o, informalmente, YCbCr). Tiene tres componentes Y', C B y C R : el componente Y' representa el brillo de un píxel y los componentes C B y C R representan la crominancia (dividida en componentes azul y rojo). Se trata básicamente del mismo espacio de color utilizado por la televisión digital en color y por el vídeo digital, incluidos los DVD de vídeo . La conversión del espacio de color Y′C B C R permite una mayor compresión sin un efecto significativo en la calidad de la imagen perceptiva (o una mayor calidad de la imagen perceptual 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 calidad perceptiva final 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 descorrelación estadística .

En el estándar JFIF se especifica una conversión particular a Y′C B C R , y se debe realizar para que el archivo JPEG resultante tenga la máxima compatibilidad. Sin embargo, algunas implementaciones JPEG en modo de "máxima calidad" no aplican este paso y en su lugar mantienen la información de color en el modelo de color RGB, [51] 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 resolución

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

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

División de bloques

Después del submuestreo , cada canal debe dividirse en bloques de 8×8. Dependiendo del submuestreo de croma, esto produce bloques de Unidad Mínima Codificada (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 compresión de video, las MCU se denominan macrobloques .

Si los datos de un canal no representan un número entero de bloques, entonces el codificador debe llenar el área restante de los bloques incompletos con algún tipo 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) dichos artefactos, y también se pueden aplicar técnicas de relleno de bordes más sofisticadas.

Transformada de coseno discreta

La subimagen de 8×8 mostrada en escala de grises de 8 bits.

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

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

Antes de calcular la DCT del bloque de 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 se encuentra 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, de modo que el rango modificado sea . Este paso reduce los requisitos de rango dinámico en la etapa de procesamiento DCT que sigue.

Este paso da como resultado los siguientes valores:

El DCT transforma un bloque de 8×8 de valores de entrada en una combinación lineal de estos 64 patrones. Los patrones se denominan funciones básicas DCT bidimensionales y los valores de salida se denominan coeficientes de transformación . El índice horizontal es y el índice vertical es .

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):

Tenga en cuenta 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 de todo el bloque. Los 63 coeficientes restantes son los coeficientes AC (también llamados componentes alternos). [52] La ventaja del DCT es su tendencia a agregar la mayor parte de la señal en una esquina del resultado, como se puede ver arriba. El paso de cuantificación siguiente 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 DCT de una imagen de componente/8 bits requieren hasta 11 o más bits (dependiendo de la fidelidad del cálculo DCT) para almacenarse. Esto puede obligar al códec a utilizar 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 normalmente se reducen 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 JPEG, ya que normalmente sólo 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.

Cuantizació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 número entero más cercano. Esta operación de redondeo es la única operación con pérdidas 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, normalmente ocurre que muchos de los componentes de mayor frecuencia se redondean a cero y muchos del resto se convierten en pequeños números positivos o negativos, que requieren muchos menos bits para representar.

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

¿ Dónde están los coeficientes DCT no cuantificados? es la matriz de cuantificación anterior; y son los coeficientes DCT cuantificados.

El uso de esta matriz de cuantificación con la matriz de coeficientes DCT anterior da como resultado:

Izquierda: se construye una imagen final a partir de una serie de funciones básicas. Derecha: cada una de las funciones base DCT que componen la imagen, y el coeficiente de ponderación correspondiente. Medio: la función base, después de multiplicar por el coeficiente: este componente se agrega a la imagen final. Para mayor claridad, el macrobloque de 8×8 en este ejemplo se amplía 10x mediante 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 valores cero.

Codificación de entropía

Orden en zigzag de componentes de imágenes JPEG

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

El estándar JPEG también permite, pero no exige, que los decodificadores admitan el uso de codificación aritmética , que es matemáticamente superior a la codificación Huffman. Sin embargo, esta característica rara vez se ha utilizado, ya que históricamente estuvo cubierta por patentes que requerían licencias con derechos de autor y porque su codificación y decodificación es más lenta en comparación con la codificación de Huffman. La codificación aritmética normalmente hace que los archivos sean entre un 5% y un 7% más pequeños [ cita necesaria ] .

El coeficiente DC cuantificado anterior se utiliza para predecir el coeficiente DC 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.

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

Si el i -ésimo bloque está representado por y las posiciones dentro de cada bloque están representadas por donde y , entonces cualquier coeficiente en la imagen DCT se puede representar como . Por lo tanto, en el esquema anterior, el orden de codificación de los píxeles (para el i - ésimo bloque) es , , , , , , etc.

Procesos básicos de codificación y decodificación JPEG secuencial

Este modo de codificación se denomina codificación secuencial de referencia. Baseline JPEG también admite codificación progresiva . Mientras que la codificación secuencial codifica coeficientes de un solo bloque a la vez (en forma de zigzag), la codificación progresiva codifica lotes de coeficientes de todos los bloques en posiciones similares de una sola vez (llamado escaneo ) , seguido del siguiente lote de coeficientes de todos los bloques. , etcétera. Por ejemplo, si la imagen se divide en N bloques de 8×8 , entonces una codificación progresiva de 3 escaneos codifica el componente DC, para todos los bloques, es decir, para todos , en el primer escaneo. A esto le sigue el segundo escaneo que codifica algunos componentes más (suponiendo que haya cuatro componentes más, todavía en forma de 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 han codificado todos los coeficientes en posiciones similares, la siguiente posición a codificar es la que ocurre a continuación en el recorrido en zigzag como se indica en la figura anterior. Se ha descubierto que la codificación JPEG progresiva de referencia generalmente proporciona una mejor compresión en comparación con el JPEG secuencial de referencia debido a la capacidad de utilizar diferentes tablas de Huffman (ver más abajo) diseñadas para diferentes frecuencias en cada "escaneo" o "pase" (que incluye coeficientes posicionados), 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 Huffman de uso 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 vinieron antes del coeficiente AC anterior. Con esta información se crean dos símbolos:

Tanto RUNLENGTH como TAMAÑO descansan en el mismo byte, lo que significa que cada uno solo contiene cuatro bits de información. Los bits más altos se ocupan del número de ceros, mientras que los bits más bajos denotan el número 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 el caso en que se encuentren 16 ceros antes de un coeficiente AC distinto de cero, el símbolo 1 se codifica "especialmente" como: (15, 0)(0).

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

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);(0, 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);

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

A partir de aquí, los cálculos de frecuencia se realizan en función de la aparición de los coeficientes. En nuestro bloque de ejemplo, la mayoría de los coeficientes cuantificados son números pequeños que no están precedidos inmediatamente por un coeficiente cero. Estos casos más frecuentes estarán representados por palabras de código 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 comprimida con una configuración de calidad de 50. Más oscuro significa una diferencia mayor. Tenga en cuenta especialmente los cambios que se producen cerca de los bordes afilados y que tienen forma de bloque.
la imagen original
Los cuadrados comprimidos de 8×8 son visibles en la imagen ampliada, junto con otros artefactos visuales de la compresión con pérdida .

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 normalmente da como resultado una imagen que no se puede distinguir a simple vista del original. Generalmente es posible una relación de compresión de 100:1, pero se verá claramente alterada en comparación con el original. El nivel apropiado de compresión depende del uso que se le dará a la imagen.

Quienes utilizan 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 bordes contrastantes (especialmente curvas y esquinas) o imágenes en "bloques". Estos se deben al paso de cuantificación del algoritmo JPEG. Se notan especialmente alrededor de las esquinas pronunciadas entre colores contrastantes (el texto es un buen ejemplo, ya que contiene muchas de esas esquinas). Los artefactos análogos en el vídeo MPEG se conocen como ruido de mosquito , ya que el "ocupado de los bordes" resultante y los puntos espurios, que cambian con el tiempo, se parecen a los mosquitos que pululan alrededor del objeto. [53] [54]

Estos artefactos se pueden reducir eligiendo un nivel de compresión más bajo ; se pueden evitar por completo guardando una imagen usando un formato de archivo sin pérdidas, aunque esto dará como resultado un tamaño de archivo mayor. 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 pueden enfatizarse si la imagen se procesa posteriormente, lo que generalmente resulta en 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 .

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 manera es posible reducir manualmente el tamaño del archivo JPEG con menor pérdida de calidad.

Dado que la etapa de cuantificación siempre resulta en una pérdida de información, el estándar JPEG es siempre un códec de compresión con pérdidas. (La información se pierde tanto al cuantificar como al redondear 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.

Descodificación

Decodificar para visualizar la imagen consiste en hacer todo lo anterior a la inversa.

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

y tomando el producto entrada por entrada con la matriz de cuantificación de arriba se obtiene

que se parece mucho a la matriz de coeficientes 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 (aún desplazados hacia abajo en 128)

Se notan ligeras diferencias entre la imagen original (arriba) y la imagen descomprimida (abajo), que se ve más fácilmente en la esquina inferior izquierda.

y sumando 128 a cada entrada

Esta es la subimagen descomprimida. En general, el proceso de descompresión puede producir valores fuera del rango de entrada original de . Si esto ocurre, el decodificador necesita recortar los valores de salida para mantenerlos dentro de ese rango y evitar el desbordamiento al almacenar la imagen descomprimida con la profundidad de bits original.

La subimagen descomprimida se puede comparar con la subimagen original (ver también las imágenes a la derecha) tomando la diferencia (original - sin comprimir) y se obtienen los siguientes valores de error:

con un error absoluto promedio de aproximadamente 5 valores por píxel (es decir, ).

El error es más notable 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 mediante un error máximo tolerable de la DCT directa e inversa en el dominio DCT según lo determinado por la prueba de referencia. corrientes. Por ejemplo, la salida de una implementación de decodificador no debe exceder un error de una unidad de cuantificación en el dominio DCT cuando se aplica a los trenes codificados de prueba de referencia proporcionados como parte de la norma anterior. Si bien es inusual y diferente a 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 con fotografías con texturas detalladas no uniformes, lo que permite relaciones de compresión más altas. Observe cómo una relación de compresión más alta afecta primero a 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 muy alta relación de compresión 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 (en función de la luminancia). Esto justifica el hecho de que las imágenes deben transformarse primero en un modelo de color que separe 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 jpeg en Photoshop en una imagen de 4480x4480 píxeles

Para obtener información, la imagen de mapa de bits RGB de 24 bits sin comprimir que aparece a continuación (73 242 píxeles) requeriría 219 726 bytes (excluyendo todos los demás encabezados de información). Los tamaños de archivo indicados 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 aproximadamente 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 comparable Q=100 requiere alrededor de un 25% más de bits codificados). La imagen de mayor calidad a continuación (Q=100) está codificada con 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 debe bajar de 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 sólo 0,13 bits por píxel y muestra colores muy pobres. Esto es útil cuando la imagen se mostrará en un tamaño significativamente reducido. Minguillón y Pujol (2001) describen un método para crear mejores matrices de cuantificación para una calidad de imagen determinada utilizando PSNR en lugar del factor Q. [55]

La fotografía de calidad media utiliza sólo el 4,3% del espacio de almacenamiento requerido para la imagen sin comprimir, pero tiene poca pérdida notable de detalles o artefactos visibles. Sin embargo, una vez que se supera 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 tasa para obtener una explicación matemática de este efecto de umbral. Una limitación particular de JPEG a este respecto es su estructura de transformación de bloques de 8×8 no superpuesta. Los diseños más modernos, como JPEG 2000 y JPEG XR, exhiben una degradación de 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 el uso de funciones de base de transformación superpuestas.

Mayor compresión 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. [56] [57] [58] [59] Esto tiene aplicaciones en escenarios donde la imagen original solo está disponible en formato JPEG y es necesario reducir su tamaño para archivarla o transmitirla. Las herramientas de compresión estándar de uso general no pueden comprimir significativamente archivos JPEG.

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

Algunas opciones estándar pero raramente utilizadas ya existen 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 un significado significativamente diferente). distribución). Los métodos modernos han mejorado estas técnicas al reordenar los coeficientes para agrupar coeficientes de mayor magnitud; [56] utilizando coeficientes y bloques adyacentes para predecir nuevos valores de coeficientes; [58] 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; [57] [58] y más recientemente, decodificando bloques, prediciendo bloques posteriores en el dominio espacial y luego codificándolos para generar predicciones para coeficientes DCT. [59]

Normalmente, estos métodos pueden comprimir archivos JPEG existentes entre un 15 y un 25 por ciento, y para los archivos JPEG comprimidos con configuraciones de baja calidad, pueden producir mejoras de hasta un 65 por ciento. [58] [59]

Una herramienta disponible gratuitamente llamada packJPG se basa en el artículo de 2007 "Reducción de redundancia mejorada para archivos JPEG". A partir de la versión 2.5k de 2016, informa una reducción típica del 20 % mediante transcodificación. [60] JPEG XL (ISO/IEC 18181) de 2018 informa una reducción similar en su transcodificación.

Formatos derivados para 3D estereoscópico

JPEG estereoscópico

Un ejemplo de un archivo .JPS estereoscópico

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, extensión .jps) es un formato basado en JPEG para imágenes estereoscópicas . [61] [62] Tiene una variedad de configuraciones almacenadas en el campo marcador JPEG APP3, pero generalmente contiene una imagen de doble ancho, que representa dos imágenes de idéntico tamaño en bizco (es decir, el marco izquierdo en la mitad derecha de la imagen). y viceversa) disposición lado a 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 imágenes múltiples JPEG (MPO, extensión .mpo) es un formato basado en JPEG para almacenar varias imágenes en un solo archivo. Contiene dos o más archivos JPEG concatenados. [64] [65] También define un segmento 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 , videocámara de extensión JVC GY-HMZ1U AVCHD/MVC, Nintendo 3DS , Panasonic Lumix DMC-TZ20 , DMC-TZ30 , DMC-TZ60 , DMC- TS4 (FT4) y Sony DSC-HX7V. Otros dispositivos lo utilizan para almacenar "imágenes de vista previa" que se pueden mostrar en un televisor.

En los últimos años, debido al creciente uso de imágenes estereoscópicas, la comunidad científica ha dedicado muchos esfuerzos a desarrollar algoritmos para la compresión de imágenes estereoscópicas. [66] [67]

Implementaciones

Una implementación muy importante de un códec JPEG es la biblioteca de programación gratuita libjpeg del Independent JPEG Group. Se publicó por primera vez en 1991 y fue clave para el éxito de la norma. Esta biblioteca se utilizó en innumerables aplicaciones. [68] El desarrollo quedó en silencio en 1998; cuando libjpeg resurgió con la versión 7 de 2009, rompió la compatibilidad ABI con versiones anteriores. La versión 8 de 2010 introdujo extensiones no estándar, una decisión criticada por el líder original del IJG, Tom Lane. [69]

libjpeg-turbo , bifurcado del libjpeg 6b de 1998, mejora libjpeg con optimizaciones SIMD . Originalmente visto como una bifurcación mantenida de libjpeg, se ha vuelto más popular después de los cambios incompatibles de 2009. [70] [71] En 2019, se convirtió en la implementación de referencia ITU|ISO/IEC como ISO/IEC 10918-7 y ITU- T T.873. [72]

El Grupo Conjunto de Expertos en Fotografía ISO/IEC mantiene la otra implementación de software de referencia bajo el título JPEG XT . Puede codificar tanto JPEG base (ISO/IEC 10918-1 y 18477–1) como extensiones JPEG XT (ISO/IEC 18477 partes 2 y 6–9), así como JPEG-LS (ISO/IEC 14495). [73]

Existe un interés persistente en codificar JPEG de formas no convencionales que maximicen la calidad de la imagen para un tamaño de archivo determinado. En 2014, Mozilla creó mozjpeg a partir de libjpeg-turbo, un codificador más lento pero de mayor calidad destinado a imágenes web. [74] En 2016, se introdujo "JPEG con esteroides" como una opción para la implementación de referencia ISO JPEG XT. [75] En marzo de 2017, Google lanzó el proyecto de código abierto Guetzli , que intercambia 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érdida). [76]

Sucesores

El Grupo Conjunto de Expertos en Fotografía ha desarrollado varios estándares más nuevos destinados a complementar o reemplazar la funcionalidad del formato JPEG original.

JPEG LS

Originado en 1993 y publicado como ISO-14495-1/ITU-T.87, JPEG LS ofrece un formato de archivo sin pérdidas de baja complejidad que era más eficiente que la implementación sin pérdidas original de JPEG. También presenta un modo con pérdida casi sin pérdidas. Su funcionalidad se limita en gran medida a eso y comparte en gran medida las mismas limitaciones del JPEG original en otros aspectos.

JPG 2000

JPEG 2000 se publicó como ISO/IEC 15444 en diciembre de 2000. Se basa en una transformada wavelet discreta (DWT) y fue diseñado para reemplazar completamente el estándar JPEG original y superarlo en todos los sentidos. Permite hasta 38 bits por canal de color y 16384 canales, más que cualquier otro formato, con multitud de espacios de color y, por tanto, alto rango dinámico (HDR). Además, admite codificación de transparencia alfa, imágenes de miles de millones de millones de píxeles, que también es más que cualquier otro formato, y compresión sin pérdidas. Ha mejorado significativamente la relación de compresión con pérdidas con artefactos significativamente menos visibles en niveles de compresión fuertes. [77]

JPEG XT

JPEG XT (ISO/IEC 18477) se publicó en junio de 2015; Amplía el formato JPEG básico 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. [78]

JPEG-XL

JPEG XL (ISO/IEC 18181) se publicó en 2021-2022. Reemplaza el formato JPEG con un nuevo formato libre de regalías basado en DCT y permite una transcodificación eficiente como opción de almacenamiento para imágenes JPEG tradicionales. [79] El nuevo formato está diseñado para superar el rendimiento de compresión de imágenes fijas mostrado por HEVC HM, Daala y WebP . Admite imágenes de mil millones por mil millones de píxeles, alto rango dinámico de hasta 32 bits por componente con las funciones de transferencia apropiadas ( PQ y HLG ), codificación de parches de imágenes sintéticas como fuentes de mapa de bits y degradados, imágenes animadas, canal alfa. codificación y una selección de codificación de color RGB/YCbCr/ ICtCp . [80] [81] [82] [83]

Ver también

Referencias

  1. ^ abcde "T.81 - COMPRESIÓN DIGITAL Y CODIFICACIÓN DE IMÁGENES FIJAS DE TONOS CONTINUOS - REQUISITOS Y DIRECTRICES" (PDF) . CCITT . Septiembre de 1992. Archivado (PDF) desde el original el 30 de diciembre de 2019 . Consultado el 12 de julio de 2019 .
  2. ^ "Definición de" JPEG"". Diccionario inglés Collins . Archivado desde el original el 21 de septiembre de 2013 . Consultado el 23 de mayo de 2013 .
  3. ^ Haines, Richard F.; Chuang, Sherry L. (1 de julio de 1992). Los efectos de la compresión de video en la aceptabilidad de imágenes para monitorear experimentos de ciencias biológicas (Informe técnico). NASA . NASA-TP-3239, A-92040, NAS 1.60:3239 . Consultado el 13 de marzo de 2016 . Los niveles de compresión de imágenes fijas JPEG, incluso con el amplio rango de 5:1 a 120:1 en este estudio, arrojaron niveles igualmente altos de aceptabilidad.
  4. ^ ab Hudson, Graham; Léger, Alain; Niss, Birger; Sebestyén, István; Vaaben, Jørgen (31 de agosto de 2018). "Estándar JPEG-1 25 años: razones pasadas, presentes y futuras de un éxito". Revista de imágenes electrónicas . 27 (4): 1. doi : 10.1117/1.JEI.27.4.040901 . S2CID  52164892.
  5. ^ Svetlik, Joe (31 de mayo de 2018). "Explicación del formato de imagen JPEG". BT.com . Grupo BT . Archivado desde el original el 5 de agosto de 2019 . Consultado el 5 de agosto de 2019 .
  6. ^ Baraniuk, Chris (15 de octubre de 2015). "Las protecciones contra copia podrían llegar a los archivos JPEG". Noticias de la BBC . BBC . Archivado desde el original el 9 de octubre de 2019 . Consultado el 13 de septiembre de 2019 .
  7. ^ Trinkwalder, Andrea (7 de octubre de 2016). "JPEG: 25 Jahre und kein bisschen alt" [JPEG: 25 años (antiguo) y nada viejo]. de: Heise en línea (en alemán). Archivado desde el original el 5 de septiembre de 2019 . Consultado el 5 de septiembre de 2019 .
  8. ^ Caplan, Paul (24 de septiembre de 2013). "¿Qué es un JPEG? El objeto invisible que ves todos los días" . El Atlántico . Archivado desde el original el 9 de octubre de 2019 . Consultado el 13 de septiembre de 2019 .
  9. ^ "Archivo HTTP: estadísticas interesantes". httparchive.org . Consultado el 6 de abril de 2016 .
  10. ^ "Detección de tipo MIME en Internet Explorer". Microsoft. 13 de julio de 2016. Archivado desde el original el 30 de octubre de 2022 . Consultado el 2 de noviembre de 2022 .
  11. ^ "Formato de intercambio de archivos JPEG" (PDF) . 3 de septiembre de 2014. Archivado desde el original el 3 de septiembre de 2014 . Consultado el 16 de octubre de 2017 .{{cite web}}: CS1 maint: bot: original URL status unknown (link)
  12. ^ "Por qué JPEG 2000 nunca despegó". Instituto Americano de Estándares Nacionales . 10 de julio de 2018. Archivado desde el original el 16 de diciembre de 2018 . Consultado el 13 de septiembre de 2019 .
  13. ^ abcd Lemos, Robert (23 de julio de 2002). "Encontrar la verdad patente en la reivindicación JPEG". CNET . Archivado desde el original el 13 de julio de 2019 . Consultado el 13 de julio de 2019 .
  14. ^ ISO/IEC JTC 1/SC 29 (7 de mayo de 2009). "ISO/IEC JTC 1/SC 29/WG 1 - Codificación de imágenes fijas (estructura SC 29/WG 1)". Archivado desde el original el 31 de diciembre de 2013 . Consultado el 11 de noviembre de 2009 .{{cite web}}: CS1 maint: numeric names: authors list (link)
  15. ^ ab ISO/IEC JTC 1/SC 29. "Programa de trabajo (asignado al SC 29/WG 1)". Archivado desde el original el 31 de diciembre de 2013 . Consultado el 7 de noviembre de 2009 .{{cite web}}: CS1 maint: numeric names: authors list (link)
  16. ^ ISO. "JTC 1/SC 29 - Codificación de información de audio, imagen, multimedia e hipermedia". Archivado desde el original el 3 de julio de 2010 . Consultado el 11 de noviembre de 2009 .
  17. ^ ab JPEG. "Grupo conjunto de expertos en fotografía, página de inicio de JPEG". Archivado desde el original el 27 de septiembre de 2009 . Consultado el 8 de noviembre de 2009 .
  18. ^ "T.81: Tecnología de la información - Compresión y codificación digital de imágenes fijas de tonos continuos - Requisitos y directrices". Itu.int . Archivado desde el original el 6 de noviembre de 2012 . Consultado el 7 de noviembre de 2009 .
  19. ^ William B. Pennebaker; Joan L. Mitchell (1993). Estándar de compresión de datos de imágenes fijas JPEG (3ª ed.). Saltador. pag. 291.ISBN _ 978-0-442-01272-4.
  20. ^ ISO. "JTC 1/SC 29 - Codificación de información de audio, imagen, multimedia e hipermedia". Archivado desde el original el 3 de julio de 2010 . Consultado el 7 de noviembre de 2009 .
  21. ^ "SPIFF, formato de archivo de intercambio de imágenes fijas". Biblioteca del Congreso . 30 de enero de 2012. Archivado desde el original el 31 de julio de 2018 . Consultado el 31 de julio de 2018 .
  22. ^ JPEG (24 de abril de 2009). "JPEG XR entra en estado FDIS: el formato de intercambio de archivos JPEG (JFIF) se estandarizará como JPEG Parte 5" (Comunicado de prensa). Archivado desde el original el 8 de octubre de 2009 . Consultado el 9 de noviembre de 2009 .
  23. ^ "Formato de intercambio de archivos JPEG (JFIF)". ECMA TR/98 1ª ed . ECMA Internacional . 2009. Archivado desde el original el 14 de enero de 2021 . Consultado el 1 de agosto de 2011 .
  24. ^ "Patente JPEG de Forgent". FuenteForge . 2002. Archivado desde el original el 13 de mayo de 2019 . Consultado el 13 de julio de 2019 .
  25. ^ "Sobre reclamaciones de patentes recientes". Jpeg.org . 19 de julio de 2002. Archivado desde el original el 14 de julio de 2007 . Consultado el 29 de mayo de 2011 .
  26. ^ "JPEG y JPEG2000: entre disputas de patentes y cambio de tecnología". Archivado desde el original el 17 de agosto de 2004 . Consultado el 16 de abril de 2017 .{{cite web}}: CS1 maint: bot: original URL status unknown (link)
  27. ^ Kawamoto, Amanecer (22 de abril de 2005). "La demanda por patentes gráficas responde a Microsoft". Noticias CNET . Archivado desde el original el 20 de enero de 2023 . Consultado el 20 de enero de 2023 .
  28. ^ "La Oficina de Marcas Vuelve a Examinar la Patente JPEG Forgent". Publicar.com . 3 de febrero de 2006. Archivado desde el original el 15 de mayo de 2016 . Consultado el 28 de enero de 2009 .
  29. ^ "USPTO: Las afirmaciones más amplias de Forgent contra el estándar JPEG no son válidas". Groklaw.net . 26 de mayo de 2006. Archivado desde el original el 16 de mayo de 2019 . Consultado el 21 de julio de 2007 .
  30. ^ "Sistema de codificación para reducir la redundancia". Gauss.ffii.org . Archivado desde el original el 12 de junio de 2011 . Consultado el 29 de mayo de 2011 .
  31. ^ "Reclamación de patente JPEG renunciada". Fundación Pública de Patentes. 2 de noviembre de 2006. Archivado desde el original el 2 de enero de 2007 . Consultado el 3 de noviembre de 2006 .
  32. ^ "Certificado de reexamen ex parte para la patente estadounidense nº 5.253.341". Archivado desde el original el 2 de junio de 2008.
  33. ^ Grupo de trabajo. "Rozmanith: uso de patentes de software para silenciar a los críticos". Eupat.ffii.org . Archivado desde el original el 16 de julio de 2011 . Consultado el 29 de mayo de 2011 .
  34. ^ "Una recompensa de 5.000 dólares por nombrar a Troll Tracker: Ray Niro quiere saber quién dice todas esas cosas desagradables sobre él". Ley.com . Archivado desde el original el 21 de noviembre de 2010 . Consultado el 29 de mayo de 2011 .
  35. ^ Reimer, Jeremy (5 de febrero de 2008). "Caza de trolls: la USPTO pidió reexaminar la patente de imagen amplia". Arstechnica.com . Archivado desde el original el 8 de diciembre de 2008 . Consultado el 29 de mayo de 2011 .
  36. ^ Oficina de Patentes de EE. UU.: concesión de reexamen en 5.253.341 C1
  37. ^ "El juez congela la patente JPEG". Techdirt.com . 30 de abril de 2008. Archivado desde el original el 14 de noviembre de 2011 . Consultado el 29 de mayo de 2011 .
  38. ^ "Reclamación única de la patente JPEG rechazada (y rechazada por si acaso)". Techdirt.com . 1 de agosto de 2008. Archivado desde el original el 28 de noviembre de 2019 . Consultado el 29 de mayo de 2011 .
  39. ^ Grupo de trabajo. "Página de inicio de Princeton Digital Image Corporation". Archivado desde el original el 11 de abril de 2013 . Consultado el 1 de mayo de 2013 .
  40. ^ Grupo de trabajo (3 de abril de 2013). "Artículo sobre el fallo del tribunal de Princeton sobre el acuerdo de licencia de GE". Archivado desde el original el 9 de marzo de 2016 . Consultado el 1 de mayo de 2013 .
  41. ^ "Descripción general de la decodificación progresiva". Red de desarrolladores de Microsoft . Microsoft. Archivado desde el original el 19 de noviembre de 2012 . Consultado el 23 de marzo de 2012 .
  42. ^ Vídeo rápido (mayo de 2019). "Codificador JPEG de 12 bits en GPU". Archivado desde el original el 6 de mayo de 2019 . Consultado el 6 de mayo de 2019 .
  43. ^ "Por qué siempre debería rotar las fotos JPEG originales sin pérdidas". Petapixel.com . 14 de agosto de 2012. Archivado desde el original el 17 de octubre de 2017 . Consultado el 16 de octubre de 2017 .
  44. ^ "Formato de archivo JFIF como PDF" (PDF) . Archivado (PDF) desde el original el 13 de enero de 2021 . Consultado el 19 de junio de 2006 .
  45. ^ Tom Lane (29 de marzo de 1999). "Preguntas frecuentes sobre la compresión de imágenes JPEG". Archivado desde el original el 10 de noviembre de 2010 . Consultado el 11 de septiembre de 2007 .(Pr. 14: "¿Por qué toda esta discusión sobre los formatos de archivos?")
  46. ^ "Todo lo que necesita saber sobre archivos JPEG | Adobe". www.adobe.com . Consultado el 18 de agosto de 2023 .
  47. ^ ab "Un espacio de color predeterminado estándar para Internet: sRGB". www.w3.org . Archivado desde el original el 18 de febrero de 2022 . Consultado el 18 de febrero de 2022 .
  48. ^ ab "IEC 61966-2-1:1999/AMD1:2003 | Tienda web IEC". tienda web.iec.ch. Archivado desde el original el 18 de febrero de 2022 . Consultado el 18 de febrero de 2022 .
  49. ^ "ISO/IEC 10918-1: 1993 (E) p.36". Archivado desde el original el 1 de agosto de 2011 . Consultado el 30 de noviembre de 2007 .
  50. ^ Thomas G. carril. "Funciones avanzadas: selección de parámetros de compresión". Usando la biblioteca IJG JPEG . Archivado desde el original el 26 de noviembre de 2001 . Consultado el 8 de octubre de 2008 .
  51. ^ Ryan, Dan (20 de junio de 2012). E - Módulos de aprendizaje: Serie Dlr Associates. Casa de Autor. ISBN 978-1-4685-7520-0.
  52. ^ "Preguntas sobre frecuencias de CC / CA: foro de Doom9". foro.doom9.org . Archivado desde el original el 17 de octubre de 2017 . Consultado el 16 de octubre de 2017 .
  53. ^ ab Phuc-Tue Le Dinh y Jacques Patry. Artefactos de compresión de vídeo y reducción de ruido MPEG Archivado el 14 de marzo de 2006 en Wayback Machine . Línea de diseño de imágenes de vídeo. 24 de febrero de 2006. Consultado el 28 de mayo de 2009.
  54. ^ " 3.9 ruido de mosquito: forma de distorsión del borde de actividad a veces asociada con el movimiento, caracterizada por artefactos en movimiento y/o patrones de ruido con manchas superpuestos sobre los objetos (que se asemeja a un mosquito volando alrededor de la cabeza y los hombros de una persona)". Rec. UIT-T. P.930 (08/96) Principios de un sistema de degradación de referencia para vídeo Archivado el 16 de febrero de 2010 en Wayback Machine.
  55. ^ Julià Minguillón, Jaume Pujol (abril de 2001). "Modelado de errores de cuantificación uniforme estándar JPEG con aplicaciones a modos de operación secuencial y progresivo" (PDF) . Imágenes electrónicas . 10 (2): 475–485. Código Bib : 2001JEI....10..475M. doi :10.1117/1.1344592. hdl :10609/6263. S2CID  16629522. Archivado (PDF) desde el original el 3 de agosto de 2020 . Consultado el 23 de septiembre de 2019 .
  56. ^ ab I. Bauermann y E. Steinbacj. Mayor compresión sin pérdidas de imágenes JPEG. Proc. of Picture Coding Symposium (PCS 2004), San Francisco, EE. UU., 15 al 17 de diciembre de 2004.
  57. ^ ab N. Ponomarenko, K. Egiazarian, V. Lukin y J. Astola. Compresión adicional sin pérdidas de imágenes JPEG, Proc. del 4to Internacional. Simposio sobre procesamiento y análisis de imágenes y señales (ISPA 2005), Zagreb, Croacia, págs. 117–120, 15–17 de septiembre de 2005.
  58. ^ abcd M. Stirner y G. Seelmann. Reducción de redundancia mejorada para archivos JPEG. Proc. of Picture Coding Symposium (PCS 2007), Lisboa, Portugal, 7 al 9 de noviembre de 2007
  59. ^ a b C Ichiro Matsuda, Yukio Nomoto, Kei Wakabayashi y Susumu Itoh. Recodificación sin pérdidas de imágenes JPEG mediante intrapredicción adaptable a bloques. Actas de la 16ª Conferencia Europea de Procesamiento de Señales (EUSIPCO 2008).
  60. ^ Stirner, Matthias (19 de febrero de 2023). "paquetejpg/paqueteJPG". GitHub . Archivado desde el original el 2 de marzo de 2023 . Consultado el 2 de marzo de 2023 .
  61. ^ J. Siragusa; DC Rápido (1997). "Descriptor de datos estereoscópicos de uso general" (PDF) . VRex, Inc., Elmsford, Nueva York, EE. UU . Archivado desde el original (PDF) el 30 de octubre de 2011.
  62. ^ Tim Kemp, archivos JPS Archivado el 18 de enero de 2009 en Wayback Machine.
  63. ^ "CGImageSource.Tipos compatibles". Complemento Claris FileMaker MBS . Software MonkeyBread. Archivado desde el original el 30 de diciembre de 2020 . Consultado el 21 de mayo de 2023 .
  64. ^ "Formato de varias imágenes" (PDF) . 2009. Archivado desde el original (PDF) el 5 de abril de 2016 . Consultado el 30 de diciembre de 2015 .
  65. ^ "MPO2Stereo: convierta archivos Fujifilm MPO a pares estéreo JPEG", Mtbs3d.com , archivado desde el original el 31 de mayo de 2010 , consultado el 12 de enero de 2010
  66. ^ Alejandro Ortis; Sebastiano Battiato (2015), Sitnik, Robert; Puech, William (eds.), "Un nuevo método de coincidencia rápida para la compresión adaptativa de imágenes estereoscópicas", Procesamiento de imágenes tridimensionales , Procesamiento, medición y aplicaciones de imágenes tridimensionales (3DIPM) 2015, SPIE - Procesamiento de imágenes tridimensionales , Medición (3DIPM) y Aplicaciones 2015, 9393 : 93930K, Bibcode :2015SPIE.9393E..0KO, doi :10.1117/12.2086372, S2CID  18879942, archivado desde el original el 3 de marzo de 2016 , recuperado 30 de abril 2015
  67. ^ Alejandro Ortis; Francisco Rundo; Giuseppe Di Giore; Sebastiano Battiato, Compresión adaptativa de imágenes estereoscópicas, Conferencia internacional sobre análisis y procesamiento de imágenes (ICIAP) 2013, archivado desde el original el 3 de marzo de 2016 , recuperado 30 de abril 2015
  68. ^ "Descripción general de JPEG". jpeg.org . Archivado desde el original el 21 de octubre de 2017 . Consultado el 16 de octubre de 2017 .
  69. ^ Tom Lane, 16 de enero de 2013: jpeg-9, compatibilidad API/ABI y el papel futuro de este proyecto Archivado el 4 de diciembre de 2018 en Wayback Machine.
  70. ^ Software que utiliza o proporciona libjpeg-turbo Archivado el 18 de marzo de 2017 en Wayback Machine . 9 de febrero de 2012.
  71. ^ Número 48789 – cromo – Utilice libjpeg-turbo en lugar de libjpeg Archivado el 1 de agosto de 2015 en Wayback Machine . 14 de abril de 2011.
  72. ^ "ISO/IEC 10918-7: 2019 Tecnología de la información - Compresión digital y codificación de imágenes fijas de tonos continuos - Parte 7: Software de referencia". YO ASI . Archivado desde el original el 7 de mayo de 2022 . Consultado el 7 de mayo de 2022 ."T.873 (19/05): Tecnología de la información - Compresión y codificación digital de imágenes fijas de tonos continuos: software de referencia". www.itu.int . Archivado desde el original el 2 de junio de 2022 . Consultado el 1 de marzo de 2023 .
  73. ^ "JPEG - JPEG XT". jpeg.org . Archivado desde el original el 4 de marzo de 2018 . Consultado el 3 de marzo de 2018 .
  74. ^ "Presentación del proyecto 'mozjpeg'". Investigación de Mozilla . 5 de marzo de 2014. Archivado desde el original el 1 de marzo de 2023 . Consultado el 1 de marzo de 2023 .
  75. ^ Richter, Thomas (septiembre de 2016). "JPEG en ESTEROIDES: técnicas de optimización comunes para la compresión de imágenes JPEG". Conferencia internacional IEEE 2016 sobre procesamiento de imágenes (ICIP) . págs. 61–65. doi :10.1109/ICIP.2016.7532319. ISBN 978-1-4673-9961-6. S2CID  14922251.
  76. ^ "Anuncio de Guetzli: un nuevo codificador JPEG de código abierto". Investigación.googleblog.com . 16 de marzo de 2017. Archivado desde el original el 6 de octubre de 2017 . Consultado el 16 de octubre de 2017 .
  77. ^ Sneyers, Jon (22 de febrero de 2021). "Ya es hora de reemplazar JPEG con un códec de imagen de próxima generación". Nublado . Consultado el 14 de noviembre de 2023 .
  78. ^ "JPEG - JPEG XT". jpeg.org . Archivado desde el original el 4 de marzo de 2018 . Consultado el 3 de marzo de 2018 .
  79. ^ Alakuijala, Jyrki; van Asseldonk, Ruud; Boukortt, Sami; Bruse, Martín; Comșa, Iulia-Maria; Firsching, Moritz; Fischbacher, Thomas; Kliuchnikov, Evgenii; Gómez, Sebastián; Obryk, Robert; Potempa, Krzysztof; Rhatushnyak, Alejandro; Sneyers, Jon; Szabadka, Zoltan; Vandervenne, Lode; Versari, Luca; Wassenberg, enero (6 de septiembre de 2019). "Herramientas de codificación y arquitectura de compresión de imágenes de próxima generación JPEG XL". En Tescher, Andrew G; Ebrahimi, Touradj (eds.). Aplicaciones del Procesamiento Digital de Imágenes XLII . vol. 11137. pág. 20. Código Bib : 2019SPIE11137E..0KA. doi :10.1117/12.2529237. ISBN 978-1-5106-2967-7. S2CID  202785129. Archivado desde el original el 26 de diciembre de 2021 . Consultado el 26 de diciembre de 2021 .
  80. ^ Rhatushnyak, Alejandro; Wassenberg, enero; Sneyers, Jon; Alakuijala, Jyrki; Vandevenne, Lode; Versari, Luca; Obryk, Robert; Szabadka, Zoltan; Kliuchnikov, Evgenii; Comsa, Iulia-Maria; Potempa, Krzysztof; Bruse, Martín; Firsching, Moritz; Khasanova, Renata; Ruud van Asseldonk; Boukortt, Sami; Gómez, Sebastián; Fischbacher, Thomas (2019). "Borrador del comité del sistema de codificación de imágenes JPEG XL". arXiv : 1908.03565 [eess.IV].
  81. ^ "N79010 Convocatoria final de propuestas para un estándar de codificación de imágenes de próxima generación (JPEG XL)" (PDF) . ISO/CEI JTC 1/SC 29/WG 1 (UIT-T CE16) . Archivado (PDF) desde el original el 31 de octubre de 2022 . Consultado el 29 de mayo de 2018 .
  82. ^ ISO/IEC 18181-1:2022 Tecnología de la información - Sistema de codificación de imágenes JPEG XL - Parte 1: Sistema de codificación central.
  83. ^ ISO/IEC 18181-2:2021 Tecnología de la información - Sistema de codificación de imágenes JPEG XL - Parte 2: Formato de archivo.

enlaces externos