JPEG

JPEG ( / ˈdʒeɪpɛɡ / JAY -peg , abreviatura de Joint Photographic Experts Group ) ^[2] es un método de compresión con pérdida de uso común para imágenes digitales , en particular 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 poca pérdida 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 todos los días a partir de 2015. ^[6]

El Joint Photographic Experts Group creó el estándar en 1992. ^[7] JPEG fue en gran medida responsable de la proliferación de imágenes digitales 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 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 . ^[9] 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 versiones anteriores de Internet Explorer , que proporcionan un tipo MIME de "image/pjpeg" al cargar imágenes JPEG. ^[10] 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, ^[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 un sucesor, JPEG 2000 , pero no pudo reemplazar al JPEG original como el estándar de imagen dominante. ^[12]

La especificación JPEG original publicada en 1992 implementa procesos de varios artículos 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 sirvieron de base para su algoritmo de codificación aritmética . ^[1]

• IBM
  • Patente estadounidense 4.652.856 – 4 de febrero de 1986 – Kottappuram MA Mohiuddin y Jorma J. Rissanen – Código aritmético multialfabético sin multiplicación
  • Patente estadounidense 4.905.297 – 27 de febrero de 1990 – G. Langdon, JL Mitchell , WB Pennebaker y Jorma J. Rissanen – Sistema codificador y decodificador de codificación aritmética
  • Patente estadounidense 4.935.882 – 19 de junio de 1990 – WB Pennebaker y JL Mitchell – Adaptación de probabilidad para codificadores aritméticos
• Mitsubishi Eléctrico
  • JP H02202267  (1021672) – 21 de enero de 1989 – Toshihiro Kimura, Shigenori Kino, Fumitaka Ono, Masayuki Yoshida – Sistema de codificación
  • JP H03247123  (2-46275) – 26 de febrero de 1990 – Tomohiro Kimura, Shigenori Kino, Fumitaka Ono y Masayuki Yoshida – Aparato de codificación y método de codificación

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] No aparece en la lista 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 un algoritmo de compresión de imágenes basado en DCT y más tarde sería motivo de controversia en 2002 (véase la controversia sobre patentes a continuación). ^[13] Sin embargo, la especificación JPEG sí citó dos artículos de investigación anteriores de Wen-Hsiung Chen, publicados en 1977 y 1984. ^[1]

"JPEG" significa Joint Photographic Experts Group , el nombre del comité que creó el estándar JPEG y otros estándares de codificación de imágenes fijas. "Joint" significa 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. ^[4]

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 Mixto ISO / IEC 1 , Subcomité 29, Grupo de Trabajo 1 ( ISO/IEC JTC 1/SC 29 /WG 1), titulado Codificación de imágenes fijas . ^{[14] [15] [16]} En el lado de ITU-T, ITU-T SG16 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 ITU-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 en JPEG.

Las normas JPEG se denominan formalmente Tecnología de la información: compresión digital y codificación de imágenes fijas de tono continuo . La norma 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]

En 2002, Forgent Networks afirmó que poseía y haría cumplir los derechos de patente sobre la tecnología JPEG, que surgían de una patente que se había presentado el 27 de octubre de 1986 y concedida el 6 de octubre de 1987: la patente estadounidense 4.698.672 de Wen-Hsiung Chen y Daniel J. Klenke de Compression Labs . ^{[13] [24]} Si bien Forgent no era propietario de Compression Labs en ese momento, Chen vendió más tarde Compression Labs a Forgent, antes de que Chen pasara a trabajar para Cisco . Esto llevó a Forgent a adquirir la propiedad de la patente. ^[13] El anuncio de Forgent de 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 habían sido invalidadas por el estado de la técnica , ^[25] una opinión compartida por varios expertos. ^{[13] [26]}

Entre 2002 y 2004, Forgent logró obtener cerca de 105 millones de dólares estadounidenses al conceder licencias de su patente a unas 30 empresas. En abril de 2004, Forgent demandó a otras 31 empresas para exigir el pago de más 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 presentó una demanda por separado contra Forgent en abril de 2005. ^[27] En febrero de 2006, la Oficina de Patentes y Marcas de los Estados Unidos acordó volver a examinar la patente JPEG de Forgent a petición de la Public Patent Foundation. ^[28] El 26 de mayo de 2006, la USPTO declaró inválida la patente basándose en la técnica anterior. La USPTO también determinó que Forgent conocía la técnica anterior, pero evitó decírselo intencionalmente a la Oficina de Patentes. Esto hace que sea muy poco probable que prospere cualquier apelación para restablecer la patente. ^[29]

Forgent también posee una patente similar otorgada por la Oficina Europea de Patentes en 1994, aunque no está claro hasta qué punto es ejecutable. ^[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 patentes contra el uso del estándar JPEG. ^[31]

Uno de los objetivos explícitos del comité JPEG es que sus estándares (en particular sus métodos de referencia) se puedan implementar sin pago de licencias, y ha obtenido los derechos de licencia adecuados para su estándar JPEG 2000 de más de 20 grandes organizaciones.

A principios de agosto de 2007, otra empresa, Global Patent Holdings, LLC, afirmó que su patente ( patente estadounidense 5.253.341 ) concedida en 1993 se infringe al descargar 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 reexaminación por la Oficina de Patentes y Marcas de los Estados Unidos desde 2000 hasta 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 presentó entonces una serie de demandas basadas en la reivindicación 17 de su patente.

En sus dos primeras demandas tras la reexaminación, ambas presentadas en Chicago, Illinois, Global Patent Holdings demandó a los Green Bay Packers , CDW , Motorola , Apple , Orbitz , Officemax , Caterpillar , Kraft y Peapod como acusados. Una tercera demanda fue presentada 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 Boca Raton Resort & Club . Una quinta demanda fue presentada contra Global Patent Holdings en Nevada. Esa demanda fue presentada por Zappos.com , Inc., que supuestamente fue amenazada por Global Patent Holdings, y solicitó una declaración judicial de que la patente '341 es inválida y no infringida.

Global Patent Holdings también había utilizado la patente '341 para demandar o amenazar a críticos abiertos de patentes de software de amplio alcance, incluyendo a Gregory Aharonian ^[33] y al operador anónimo de un blog de un sitio 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 los Estados Unidos que reexaminara la única reivindicación restante de la patente '341 sobre la base de nueva técnica anterior. ^[35]

El 5 de marzo de 2008, la Oficina de Patentes y Marcas de los Estados Unidos acordó reexaminar la patente '341, y concluyó que la nueva técnica anterior planteaba nuevas cuestiones sustanciales con respecto a la validez de la patente. ^[36] A la luz de la reexaminación, los infractores acusados ​​en cuatro de las cinco demandas pendientes presentaron mociones para suspender (parar) sus casos hasta que se completara la revisión de la patente '341 por parte de la Oficina de Patentes y Marcas de los Estados Unidos. El 23 de abril de 2008, un juez que presidía las dos demandas en Chicago, Illinois, concedió las mociones en esos casos. ^[37] El 22 de julio de 2008, la Oficina de Patentes emitió la primera "Acción de Oficina" de la segunda reexaminación, y determinó que la reivindicación era inválida con base en diecinueve motivos separados. ^[38] El 24 de noviembre de 2009, se emitió un Certificado de Reexaminación que cancelaba todas las reivindicaciones.

A partir de 2011 y hasta 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 de cámaras y dispositivos y revendedores. 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 Princeton teóricamente podría haber seguido demandando a las empresas hasta diciembre de 2013). A 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]

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

Sin embargo, el formato 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. Es mejor guardar estas imágenes 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érdida, pero ese modo no es compatible con la mayoría de los productos.

Dado que 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 de procesamiento técnico de imágenes ).

El formato 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, en particular si se recorta o desplaza la imagen, o si se modifican los parámetros de codificación (consulte la sección Pérdida de generación digital para obtener más información). 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érdida, editar posteriormente en ese formato y, finalmente, publicar como JPEG para su distribución.

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 vídeo del dominio espacial (2D) al dominio de frecuencia (también conocido como dominio de la transformada). Un modelo perceptual basado libremente en el sistema psicovisual humano descarta la información de alta frecuencia, es decir, las transiciones bruscas en intensidad y tono de color. En el dominio de la transformada, el proceso de reducción de información se denomina 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 ocurrencias de cada número) en una más pequeña, y el dominio de la transformada 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 típicamente pequeños con alta compresibilidad. Luego, los coeficientes cuantificados se secuencian y se empaquetan sin pérdida 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 sacrificar 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 fijados para la aplicación.

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

También existe un formato JPEG progresivo entrelazado , en el que los datos se comprimen en múltiples pasadas de 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, lo que permite una vista previa razonable después de recibir solo una parte de los datos. Sin embargo, la compatibilidad con JPEG progresivos no es universal. Cuando los programas que no los admiten (como las versiones de Internet Explorer anteriores a Windows 7 ) reciben JPEG progresivos ^[41], el software muestra la imagen solo después de que se haya descargado por completo.

También existen muchas aplicaciones de imágenes médicas, de tráfico y de 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 está incluido 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]

Se pueden realizar varias modificaciones en 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 mínima codificada) (normalmente 16 píxeles en ambas direcciones, para submuestreo de croma 4:2:0 ). Las utilidades que implementan esto incluyen:

• jpegtran y su GUI, Jpegcrop.
• IrfanView utiliza "JPG Lossless Crop (PlugIn)" y "JPG Lossless Rotation (PlugIn)", que requieren la instalación del complemento JPG_TRANSFORM.
• Visor de imágenes FastStone que utiliza "Recorte a archivo sin pérdida" y "Rotación sin pérdida JPEG".
• XnViewMP utiliza "transformaciones sin pérdida JPEG".
• ACDSee admite la rotación sin pérdida (pero no el recorte sin pérdida) con su opción "Forzar operaciones JPEG sin pérdida".

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

El borde superior e izquierdo de una imagen JPEG debe 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 el borde inferior y derecho no necesitan estarlo. Esto limita las posibles operaciones de recorte sin pérdida y evita volteos 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érdida. Al rotar una imagen de este tipo, se vuelven a calcular los bloques, lo que da como resultado una pérdida de calidad. ^[43]

Al utilizar el recorte sin pérdida, si el lado inferior o derecho de la región de recorte no se encuentra en el límite de un bloque, el resto de los datos de los bloques parcialmente utilizados seguirán estando presentes en el archivo recortado y podrán recuperarse. También es posible realizar transformaciones entre formatos de línea base y progresivos sin ninguna pérdida de calidad, ya que la única diferencia es el orden en el 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.

El formato de archivo conocido como "JPEG Interchange Format" (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 de la norma y debido a ciertas deficiencias de la norma:

• Definición del espacio de color
• Registro de submuestreo de componentes
• Definición de relación de aspecto de píxeles.

Se han desarrollado varios estándares adicionales para abordar estas cuestiones. El primero de ellos, publicado 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 utilizan la disposición de bytes JIF real, que consta de diferentes marcadores , pero además, emplean uno de los puntos de extensión del estándar JIF, es decir, los marcadores de aplicación : JFIF utiliza APP0, mientras que Exif utiliza APP1. Dentro de estos segmentos del archivo que se dejaron para uso futuro en el estándar JIF y que no son leídos por él, estos estándares agregan metadatos específicos.

Por lo tanto, en algunos aspectos, JFIF es una versión reducida del estándar JIF, ya 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 los metadatos agregados. 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 secuencias 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 en ningún formato de archivo específico de la aplicación. Tampoco debería incluirlo, 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 del software de edición de imágenes almacena JPEG en formato JFIF e incluye el segmento APP1 del archivo Exif para incluir los metadatos de una manera casi compatible; el estándar JFIF se interpreta de manera algo flexible. ^[45]

En sentido estricto, 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 gestionen correctamente el segmento JFIF del formato más antiguo, mientras que los lectores más nuevos también decodifican el siguiente segmento Exif, siendo menos estrictos en cuanto a exigir que aparezca primero.

Las extensiones de nombre de archivo más comunes para archivos que emplean compresión JPEG son .jpgy , .jpegaunque también se utilizan y . ^[46] También es posible que los datos JPEG se incorporen en otros tipos de archivos: los archivos codificados TIFF a menudo incorporan una imagen JPEG como miniatura de la imagen principal; y los archivos MP3 pueden contener un JPEG de la carátula en la etiqueta ID3v2 . .jpe.jfif.jif

Muchos archivos JPEG incorporan un perfil de color ICC ( espacio de color ). Los perfiles de color más utilizados son 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 pasos ; consulte la curva gamma .

Si la imagen no especifica información de perfil de color ( sin etiqueta ), se supone que el espacio de color es sRGB para fines de visualización en páginas web. ^{[47] [48]}

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 solo de esos dos bytes; otros son seguidos por 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 para la longitud, pero no los dos bytes para el marcador). Algunos marcadores son seguidos por 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 para fines de relleno , aunque este relleno de bytes de relleno solo debe tener lugar 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 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 parezca que hay un marcador donde no se pretende que haya 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 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 por entropía para permitir la decodificación paralela, y los codificadores tienen la libertad de insertar estos marcadores de reinicio a intervalos regulares (aunque no todos los codificadores lo hacen).

Hay otros marcadores de inicio de cuadro que introducen otros tipos de codificaciones JPEG.

Dado que varios proveedores pueden usar 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 en el flujo de bits, como la transmisión a través de una red no confiable o la corrupción de un archivo. Dado que las ejecuciones de macrobloques entre marcadores de reinicio se pueden decodificar de forma independiente, estas ejecuciones se pueden decodificar en paralelo.

Aunque un archivo JPEG se puede codificar de varias maneras, la más común es 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′C _B C _R , que consta de un componente de luminancia (Y'), que representa el brillo, y dos componentes de croma (C _B y C _R ), que representan el color. Este paso a veces se omite.
2. La resolución de los datos de croma 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 discreta (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 una precisión menor que los 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 una configuración de calidad excesivamente baja, los componentes de alta frecuencia se descartan por completo.
5. Los datos resultantes de todos los bloques de 8×8 se comprimen aún más con un algoritmo sin pérdida, una variante de la codificación Huffman .

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

Muchas de las opciones del estándar JPEG no se utilizan comúnmente 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. Aquí se incluye 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 cada uno de los siguientes : rojo, verde y azul ). Esta opción en particular es un método de compresión de datos con pérdida . Se representan en las matrices a continuación.

En primer lugar, la imagen debe convertirse de RGB (por defecto sRGB, ^{[47] [48]} pero otros espacios de color son posibles) 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). Este es básicamente el mismo espacio de color que se utiliza en la televisión digital en color , así como en 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 perceptual (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 perceptual 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 del color también mejora la compresión mediante decorrelación estadística .

En el estándar JFIF se especifica una conversión particular a Y′C _B C _R , que debe realizarse para que el archivo JPEG resultante tenga la máxima compatibilidad. Sin embargo, algunas implementaciones de 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 utilizaría cuando el tamaño del archivo es especialmente importante.

Debido a la densidad de los receptores sensibles al color y al brillo en el ojo humano, los seres 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 (los componentes Cb y Cr). Con 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 (denominado " submuestreo de croma "). Las proporciones en las que se realiza habitualmente el submuestreo para imágenes JPEG son 4:4:4 (sin submuestreo), 4:2:2 (reducción por un factor de 2 en la dirección horizontal) o (lo más habitual) 4:2:0 (reducción por un factor de 2 tanto en la dirección horizontal como en la vertical). Para el resto del proceso de compresión, Y', Cb y Cr se procesan por separado y de una manera muy similar.

Después del submuestreo , cada canal debe dividirse en bloques de 8×8. Según el 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 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 rellenar 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 zumbido 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 elimina necesariamente) dichos artefactos, y también se pueden aplicar técnicas de relleno de bordes más sofisticadas.

A continuación, cada bloque 8×8 de cada componente (Y, Cb, Cr) se convierte en una representación en el dominio de la frecuencia , utilizando una transformada de coseno discreta (DCT) de tipo II normalizada y bidimensional (véase la cita 1 en la transformada de coseno discreta). A veces se hace referencia a la DCT como "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 denota como "DCT de tipo III".

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

${\displaystyle \left[{\begin{array}{rrrrrrrr}52&55&61&66&70&61&64&73\\63&59&55&90&109&85&69&72\\62&59&68&113&144&104&66&73\\63&58&71&122&154&106&70&69\\67&61&68&104&126&88&68&70\\79&65&60&70&77&68&58&75\\85&71&64&59&55&61&65&83\\87&79&69&68&65&76&78&94\end{array}}\right].}$

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 del 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 que está centrado en cero, de modo que el rango modificado es . Este paso reduce los requisitos de rango dinámico en la etapa de procesamiento de DCT que sigue. ${\displaystyle [0,255]}$${\displaystyle [-128,127]}$

Este paso da como resultado los siguientes valores:

${\displaystyle g={\begin{array}{c}x\\\longrightarrow \\\left[{\begin{array}{rrrrrrrr}-76&-73&-67&-62&-58&-67&-64&-55\\-65&-69&-73&-38&-19&-43&-59&-56\\-66&-69&-60&-15&16&-24&-62&-55\\-65&-70&-57&-6&26&-22&-58&-59\\-61&-67&-60&-24&-2&-40&-60&-58\\-49&-63&-68&-58&-51&-60&-70&-53\\-43&-57&-64&-69&-73&-67&-63&-45\\-41&-49&-59&-60&-63&-52&-50&-34\end{array}}\right]\end{array}}{\Bigg \downarrow }y.}$

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

${\displaystyle \ G_{u,v}={\frac {1}{4}}\alpha (u)\alpha (v)\sum _{x=0}^{7}\sum _{y=0}^{7}g_{x,y}\cos \left[{\frac {(2x+1)u\pi }{16}}\right]\cos \left[{\frac {(2y+1)v\pi }{16}}\right]}$

dónde

• ${\displaystyle \ u}$es la frecuencia espacial horizontal , para los números enteros .${\displaystyle \ 0\leq u<8}$
• ${\displaystyle \ v}$es la frecuencia espacial vertical, para los números enteros .${\displaystyle \ 0\leq v<8}$
• ${\displaystyle \alpha (u)={\begin{cases}{\frac {1}{\sqrt {2}}},&{\mbox{if }}u=0\\1,&{\mbox{otherwise}}\end{cases}}}$es un factor de escala normalizador para hacer que la transformación sea ortonormal
• ${\displaystyle \ g_{x,y}}$es el valor del píxel en las coordenadas${\displaystyle \ (x,y)}$
• ${\displaystyle \ G_{u,v}}$es el coeficiente DCT en las coordenadas${\displaystyle \ (u,v).}$

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

${\displaystyle G={\begin{array}{c}u\\\longrightarrow \\\left[{\begin{array}{rrrrrrrr}-415.38&-30.19&-61.20&27.24&56.12&-20.10&-2.39&0.46\\4.47&-21.86&-60.76&10.25&13.15&-7.09&-8.54&4.88\\-46.83&7.37&77.13&-24.56&-28.91&9.93&5.42&-5.65\\-48.53&12.07&34.10&-14.76&-10.24&6.30&1.83&1.95\\12.12&-6.55&-13.20&-3.95&-1.87&1.75&-2.79&3.14\\-7.73&2.91&2.38&-5.94&-2.38&0.94&4.30&1.85\\-1.03&0.18&0.42&-2.42&-0.88&-3.02&4.12&-0.66\\-0.17&0.14&-1.07&-4.19&-1.17&-0.10&0.50&1.68\end{array}}\right]\end{array}}{\Bigg \downarrow }v.}$

Obsérvese la entrada de la esquina superior izquierda con la 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 alternantes). ^[52] La ventaja de la 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 a continuación acentúa este efecto al mismo tiempo que reduce el tamaño general de los coeficientes de la 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 8 bits/componente requieren hasta 11 bits o más (según la fidelidad del cálculo DCT) para almacenarse. Esto puede obligar al códec a utilizar temporalmente números de 16 bits para almacenar 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 en el paso de cuantificación. El aumento temporal del tamaño en esta etapa no es un problema de rendimiento para la mayoría de las implementaciones JPEG, ya que normalmente 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.

El ojo humano es bueno para ver pequeñas diferencias de brillo en un área relativamente grande, pero no tan bueno para distinguir la intensidad 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 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 de DCT se realiza con una precisión suficientemente alta. Como resultado de esto, es típico que muchos de los componentes de frecuencia más alta se redondeen a cero, y muchos del resto se conviertan en pequeños números positivos o negativos, que requieren muchos menos bits para representarse.

Los elementos de la matriz de cuantificación controlan la relación de compresión, y los valores más altos 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:

${\displaystyle Q={\begin{bmatrix}16&11&10&16&24&40&51&61\\12&12&14&19&26&58&60&55\\14&13&16&24&40&57&69&56\\14&17&22&29&51&87&80&62\\18&22&37&56&68&109&103&77\\24&35&55&64&81&104&113&92\\49&64&78&87&103&121&120&101\\72&92&95&98&112&100&103&99\end{bmatrix}}.}$

Los coeficientes DCT cuantificados se calculan con

${\displaystyle B_{j,k}=\mathrm {round} \left({\frac {G_{j,k}}{Q_{j,k}}}\right){\mbox{ for }}j=0,1,2,\ldots ,7;k=0,1,2,\ldots ,7}$

donde son los coeficientes DCT no cuantificados; es la matriz de cuantificación anterior; y son los coeficientes DCT cuantificados. ${\displaystyle G}$${\displaystyle Q}$${\displaystyle B}$

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

${\displaystyle B=\left[{\begin{array}{rrrrrrrr}-26&-3&-6&2&2&-1&0&0\\0&-2&-4&1&1&0&0&0\\-3&1&5&-1&-1&0&0&0\\-3&1&2&-1&0&0&0&0\\1&0&0&0&0&0&0&0\\0&0&0&0&0&0&0&0\\0&0&0&0&0&0&0&0\\0&0&0&0&0&0&0&0\end{array}}\right].}$

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

${\displaystyle \mathrm {round} \left({\frac {-415.37}{16}}\right)=\mathrm {round} \left(-25.96\right)=-26.}$

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.

La codificación por entropía es una forma especial de compresión de datos sin pérdida . Implica la disposición de los componentes de la imagen en un orden en " zigzag " empleando el algoritmo de codificación por longitud de ejecución (RLE) que agrupa frecuencias similares, insertando ceros de codificación de longitud y luego utilizando la codificación de 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 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 aproximadamente un 5-7% más pequeños ^{[ cita requerida ]} .

El coeficiente de CC cuantificado anterior se utiliza para predecir el coeficiente de CC cuantificado actual. Se codifica la diferencia entre los dos en lugar del valor real. La codificación de los 63 coeficientes de CA cuantificados no utiliza dicha diferencia de predicción.

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

Si el bloque i -ésimo está representado por y las posiciones dentro de cada bloque están representadas por donde y , entonces cualquier coeficiente en la imagen DCT puede representarse como . Por lo tanto, en el esquema anterior, el orden de los píxeles de codificación (para el bloque i -ésimo) es , , , , , , , y así sucesivamente. ${\displaystyle B_{i}}$${\displaystyle (p,q)}$${\displaystyle p=0,1,...,7}$${\displaystyle q=0,1,...,7}$${\displaystyle B_{i}(p,q)}$${\displaystyle B_{i}(0,0)}$${\displaystyle B_{i}(0,1)}$${\displaystyle B_{i}(1,0)}$${\displaystyle B_{i}(2,0)}$${\displaystyle B_{i}(1,1)}$${\displaystyle B_{i}(0,2)}$${\displaystyle B_{i}(0,3)}$${\displaystyle B_{i}(1,2)}$

Este modo de codificación se denomina codificación secuencial de línea base . El JPEG de línea base también admite la codificación progresiva . Mientras que la codificación secuencial codifica los coeficientes de un solo bloque a la vez (en forma de zigzag), la codificación progresiva codifica un lote de coeficientes de todos los bloques en una posición similar de una sola vez (llamado escaneo ), seguido por el siguiente lote de coeficientes de todos los bloques, y así sucesivamente. 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 hay cuatro componentes más, son , 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. ${\displaystyle B_{0},B_{1},B_{2},...,B_{n-1}}$${\displaystyle B_{i}(0,0)}$${\displaystyle i=0,1,2,...,N-1}$${\displaystyle B_{i}(0,1)}$${\displaystyle B_{i}(1,1)}$${\displaystyle B_{0}(0,1),B_{0}(1,0),B_{0}(2,0),B_{0}(1,1),B_{1}(0,1),B_{1}(1,0),...,B_{N}(2,0),B_{N}(1,1)}$

Una vez que se han codificado todos los coeficientes en posiciones similares, la siguiente posición que se codificará es la que aparece 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 suele ofrecer una mejor compresión en comparación con la codificación JPEG secuencial de referencia debido a la capacidad de utilizar diferentes tablas de Huffman (ver a continuación) adaptadas a diferentes frecuencias en cada "escaneo" o "paso" (que incluye coeficientes en posiciones similares), 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 Huffman optimizadas para las distribuciones de frecuencia reales en las imágenes que se están codificando.

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

• x es el coeficiente de CA cuantificado y distinto de cero.
• RUNLENGTH es el número de ceros que vienen antes de este coeficiente de CA distinto de cero.
• TAMAÑO es el número de bits necesarios para representar x .
• AMPLITUD es la representación en bits de x .

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

Tanto RUNLENGTH como SIZE se encuentran en el mismo byte, lo que significa que cada uno contiene solo cuatro bits de información. Los bits más altos se ocupan de la cantidad de ceros, mientras que los bits más bajos 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. Una es para finalizar la secuencia prematuramente cuando los coeficientes restantes son cero (llamado "Fin de bloque" o "EOB"), y otra cuando la serie de ceros supera los 15 antes de alcanzar un coeficiente AC distinto de cero. En un caso como este, en el que se encuentran 16 ceros antes de un coeficiente AC distinto de cero dado, 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, 2)(-2);(0, 3)(-6);(0, 2)(2);( 0, 3)(-4);(0, 1)(1);(0, 2)(-3);(0, 1)(1);(0, 1)(1);

(0, 3)(5);(0, 1)(1);(0, 2)(2);(0, 1)(-1);(0, 1)(1);(0, 1 )(-1);(0, 2)(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. Véase más arriba).

A partir de aquí, se realizan cálculos de frecuencia 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 están precedidos inmediatamente por un coeficiente cero. Estos casos más frecuentes se representarán mediante palabras de código más cortas.

La relación de compresión resultante se puede variar según las necesidades, siendo más o menos agresivos los divisores utilizados en la fase de cuantificación. La compresión de diez a uno suele dar como resultado una imagen que no se puede distinguir a simple vista de la original. Normalmente es posible una relación de compresión de 100:1, pero se verá claramente distorsionada en comparación con la original. El nivel adecuado de compresión depende del uso que se le vaya a 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 los bordes contrastantes (especialmente curvas y esquinas), o imágenes "en bloques". Estos se deben al paso de cuantificación del algoritmo JPEG. Son especialmente notables alrededor de las esquinas agudas 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 , ya que la "ocupación de los bordes" resultante y los puntos espurios, que cambian con el tiempo, se asemejan a 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 utilizando un formato de archivo sin pérdida, 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 .

Algunos programas permiten al usuario variar la cantidad de compresión de 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 una menor pérdida de calidad.

Dado que la etapa de cuantificación siempre da como resultado 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 , se perderá información en el paso de redondeo.

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

Tomando la matriz de coeficientes DCT (después de agregar nuevamente la diferencia del coeficiente DC)

${\displaystyle \left[{\begin{array}{rrrrrrrr}-26&-3&-6&2&2&-1&0&0\\0&-2&-4&1&1&0&0&0\\-3&1&5&-1&-1&0&0&0\\-3&1&2&-1&0&0&0&0\\1&0&0&0&0&0&0&0\\0&0&0&0&0&0&0&0\\0&0&0&0&0&0&0&0\\0&0&0&0&0&0&0&0\end{array}}\right]}$

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

${\displaystyle \left[{\begin{array}{rrrrrrrr}-416&-33&-60&32&48&-40&0&0\\0&-24&-56&19&26&0&0&0\\-42&13&80&-24&-40&0&0&0\\-42&17&44&-29&0&0&0&0\\18&0&0&0&0&0&0&0\\0&0&0&0&0&0&0&0\\0&0&0&0&0&0&0&0\\0&0&0&0&0&0&0&0\end{array}}\right]}$

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 tipo III 2D), que viene dada por:

${\displaystyle f_{x,y}={\frac {1}{4}}\sum _{u=0}^{7}\sum _{v=0}^{7}\alpha (u)\alpha (v)F_{u,v}\cos \left[{\frac {(2x+1)u\pi }{16}}\right]\cos \left[{\frac {(2y+1)v\pi }{16}}\right]}$

dónde

• ${\displaystyle \ x}$es la fila de píxeles, para los números enteros .${\displaystyle \ 0\leq x<8}$
• ${\displaystyle \ y}$es la columna de píxeles, para los números enteros .${\displaystyle \ 0\leq y<8}$
• ${\displaystyle \ \alpha (u)}$es el factor de escala normalizador definido anteriormente para los números enteros .${\displaystyle \ 0\leq u<8}$
• ${\displaystyle \ F_{u,v}}$es el coeficiente DCT aproximado en las coordenadas${\displaystyle \ (u,v).}$
• ${\displaystyle \ f_{x,y}}$es el valor del píxel reconstruido en las coordenadas${\displaystyle \ (x,y)}$

Al redondear la salida a valores enteros (ya que el original tenía valores enteros), se obtiene una imagen con valores (aún desplazados hacia abajo en 128)

${\displaystyle \left[{\begin{array}{rrrrrrrr}-66&-63&-71&-68&-56&-65&-68&-46\\-71&-73&-72&-46&-20&-41&-66&-57\\-70&-78&-68&-17&20&-14&-61&-63\\-63&-73&-62&-8&27&-14&-60&-58\\-58&-65&-61&-27&-6&-40&-68&-50\\-57&-57&-64&-58&-48&-66&-72&-47\\-53&-46&-61&-74&-65&-63&-62&-45\\-47&-34&-53&-74&-60&-47&-47&-41\end{array}}\right]}$

y añadiendo 128 a cada entrada

${\displaystyle \left[{\begin{array}{rrrrrrrr}62&65&57&60&72&63&60&82\\57&55&56&82&108&87&62&71\\58&50&60&111&148&114&67&65\\65&55&66&120&155&114&68&70\\70&63&67&101&122&88&60&78\\71&71&64&70&80&62&56&81\\75&82&67&54&63&65&66&83\\81&94&75&54&68&81&81&87\end{array}}\right].}$

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 debe 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. ${\displaystyle [0,255]}$

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) que da como resultado los siguientes valores de error:

${\displaystyle \left[{\begin{array}{rrrrrrrr}-10&-10&4&6&-2&-2&4&-9\\6&4&-1&8&1&-2&7&1\\4&9&8&2&-4&-10&-1&8\\-2&3&5&2&-1&-8&2&-1\\-3&-2&1&3&4&0&8&-8\\8&-6&-4&-0&-3&6&2&-6\\10&-11&-3&5&-8&-4&-1&-0\\6&-15&-6&14&-3&-5&-3&7\end{array}}\right]}$

con un error absoluto promedio de aproximadamente 5 valores por píxel (es decir, ). ${\displaystyle {\frac {1}{64}}\sum _{x=0}^{7}\sum _{y=0}^{7}|e(x,y)|=4.8750}$

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 situado inmediatamente a su derecha.

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 de la norma JPEG. Estos requisitos se especifican en la Recomendación ITU.T T.83 | ISO/IEC 10918-2. A diferencia de las normas MPEG y muchas normas JPEG posteriores, el documento anterior define tanto las precisiones de implementación requeridas para el proceso de codificación como de decodificación de un códec JPEG por medio de un error máximo tolerable de la DCT directa e inversa en el dominio DCT según lo determinado por los flujos de prueba de referencia. Por ejemplo, la salida de una implementación de decodificador no debe superar un error de una unidad de cuantificación en el dominio DCT cuando se aplica a los flujos de código de prueba de referencia proporcionados como parte de la norma anterior. Si bien es inusual, y a diferencia de muchas otras normas más modernas, la Recomendación ITU.T T.83 | ISO/IEC 10918-2 no formula límites de error en el dominio de la imagen.

Los artefactos de compresión JPEG se combinan bien con fotografías con texturas no uniformes y detalladas, lo que permite mayores índices de compresión. Observe cómo un índice de compresión más alto 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. El índice de compresión muy alto afecta gravemente la calidad de la imagen, aunque los colores generales y la forma de la imagen aún son reconocibles. Sin embargo, la precisión de los colores se ve menos afectada (para un ojo humano) que la precisión de los contornos (basada en la luminancia). Esto justifica el hecho de que las imágenes se deban transformar primero en un modelo de color que separe la luminancia de la información cromática, antes de realizar un submuestreo de 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.

For information, the uncompressed 24-bit RGB bitmap image below (73,242 pixels) would require 219,726 bytes (excluding all other information headers). The filesizes indicated below include the internal JPEG information headers and some metadata. For highest quality images (Q=100), about 8.25 bits per color pixel is required. On grayscale images, a minimum of 6.5 bits per pixel is enough (a comparable Q=100 quality color information requires about 25% more encoded bits). The highest quality image below (Q=100) is encoded at nine bits per color pixel, the medium quality image (Q=25) uses one bit per color pixel. For most applications, the quality factor should not go below 0.75 bit per pixel (Q=12.5), as demonstrated by the low quality image. The image at lowest quality uses only 0.13 bit per pixel, and displays very poor color. This is useful when the image will be displayed in a significantly scaled-down size. A method for creating better quantization matrices for a given image quality using PSNR instead of the Q factor is described in Minguillón & Pujol (2001).^[55]

The medium quality photo uses only 4.3% of the storage space required for the uncompressed image, but has little noticeable loss of detail or visible artifacts. However, once a certain threshold of compression is passed, compressed images show increasingly visible defects. See the article on rate–distortion theory for a mathematical explanation of this threshold effect. A particular limitation of JPEG in this regard is its non-overlapped 8×8 block transform structure. More modern designs such as JPEG 2000 and JPEG XR exhibit a more graceful degradation of quality as the bit usage decreases – by using transforms with a larger spatial extent for the lower frequency coefficients and by using overlapping transform basis functions.

From 2004 to 2008, new research emerged on ways to further compress the data contained in JPEG images without modifying the represented image.^{[56][57][58][59]} This has applications in scenarios where the original image is only available in JPEG format, and its size needs to be reduced for archiving or transmission. Standard general-purpose compression tools cannot significantly compress JPEG files.

Typically, such schemes take advantage of improvements to the naive scheme for coding DCT coefficients, which fails to take into account:

• Correlations between magnitudes of adjacent coefficients in the same block;
• Correlations between magnitudes of the same coefficient in adjacent blocks;
• Correlations between magnitudes of the same coefficient/block in different channels;
• The DC coefficients when taken together resemble a downscale version of the original image multiplied by a scaling factor. Well-known schemes for lossless coding of continuous-tone images can be applied, achieving somewhat better compression than the Huffman coded DPCM used in JPEG.

Some standard but rarely used options already exist in JPEG to improve the efficiency of coding DCT coefficients: the arithmetic coding option, and the progressive coding option (which produces lower bitrates because values for each coefficient are coded independently, and each coefficient has a significantly different distribution). Modern methods have improved on these techniques by reordering coefficients to group coefficients of larger magnitude together;^[56] using adjacent coefficients and blocks to predict new coefficient values;^[58] dividing blocks or coefficients up among a small number of independently coded models based on their statistics and adjacent values;^[57][58] and most recently, by decoding blocks, predicting subsequent blocks in the spatial domain, and then encoding these to generate predictions for DCT coefficients.^[59]

Typically, such methods can compress existing JPEG files between 15 and 25 percent, and for JPEGs compressed at low-quality settings, can produce improvements of up to 65%.^[58][59]

A freely available tool called packJPG is based on the 2007 paper "Improved Redundancy Reduction for JPEG Files." As of version 2.5k of 2016, it reports a typical 20% reduction by transcoding.^[60] JPEG XL (ISO/IEC 18181) of 2018 reports a similar reduction in its transcoding.

JPS is a stereoscopic JPEG image used for creating 3D effects from 2D images. It contains two static images, one for the left eye and one for the right eye; encoded as two side-by-side images in a single JPG file. JPEG Stereoscopic (JPS, extension .jps) is a JPEG-based format for stereoscopic images.^[61][62] It has a range of configurations stored in the JPEG APP3 marker field, but usually contains one image of double width, representing two images of identical size in cross-eyed (i.e. left frame on the right half of the image and vice versa) side-by-side arrangement. This file format can be viewed as a JPEG without any special software, or can be processed for rendering in other modes.

JPEG Multi-Picture Format (MPO, extension .mpo) is a JPEG-based format for storing multiple images in a single file. It contains two or more JPEG files concatenated together.^[64][65] It also defines a JPEG APP2 marker segment for image description. Various devices use it to store 3D images, such as Fujifilm FinePix Real 3D W1, HTC Evo 3D, JVC GY-HMZ1U AVCHD/MVC extension camcorder, Nintendo 3DS, Panasonic Lumix DMC-TZ20, DMC-TZ30, DMC-TZ60, DMC-TS4 (FT4), and Sony DSC-HX7V. Other devices use it to store "preview images" that can be displayed on a TV.

In the last few years, due to the growing use of stereoscopic images, much effort has been spent by the scientific community to develop algorithms for stereoscopic image compression.^[66][67]

A very important implementation of a JPEG codec is the free programming library libjpeg of the Independent JPEG Group. It was first published in 1991 and was key for the success of the standard. This library was used in countless applications.^[68] The development went quiet in 1998; when libjpeg resurfaced with the 2009 version 7, it broke ABI compatibility with previous versions. Version 8 of 2010 introduced non-standard extensions, a decision criticized by the original IJG leader Tom Lane.^[69]

libjpeg-turbo, forked from the 1998 libjpeg 6b, improves on libjpeg with SIMD optimizations. Originally seen as a maintained fork of libjpeg, it has become more popular after the incompatible changes of 2009.^[70][71] In 2019, it became the ITU|ISO/IEC reference implementation as ISO/IEC 10918-7 and ITU-T T.873.^[72]

ISO/IEC Joint Photography Experts Group maintains the other reference software implementation under the JPEG XT heading. It can encode both base JPEG (ISO/IEC 10918-1 and 18477–1) and JPEG XT extensions (ISO/IEC 18477 Parts 2 and 6–9), as well as JPEG-LS (ISO/IEC 14495).^[73] In 2016, "JPEG on steroids" was introduced as an option for the ISO JPEG XT reference implementation.^[74]

There is persistent interest in encoding JPEG in unconventional ways that maximize image quality for a given file size. In 2014, Mozilla created MozJPEG from libjpeg-turbo, a slower but higher-quality encoder intended for web images.^[75] In March 2017, Google released the open source project Guetzli, which trades off a much longer encoding time for smaller file size (similar to what Zopfli does for PNG and other lossless data formats).^[76]

In April 2024, Google introduced Jpegli, a new JPEG coding library that offers enhanced capabilities and a 35% compression ratio improvement at high quality compression settings, while the coding speed is comparable with MozJPEG.^[77]

The Joint Photographic Experts Group has developed several newer standards meant to complement or replace the functionality of the original JPEG format.

Originating in 1993 and published as ISO-14495-1/ITU-T.87, JPEG LS offers a low-complexity lossless file format which was more efficient than JPEG's original lossless implementation. It also features a lossy mode close to lossless. Its functionality is largely limited to that, and largely shares the same limitations of the original JPEG in other aspects.

JPEG 2000 was published as ISO/IEC 15444 in December 2000. It is based on a discrete wavelet transform (DWT) and was designed to completely replace the original JPEG standard and exceed it in every way. It allows up to 38 bits per colour channel and 16384 channels, more than any other format, with a multitude of colour spaces, and thus high dynamic range (HDR). Furthermore, it supports alpha transparency coding, billions-by-billions pixel images, which is also more than any other format, and lossless compression. It has significantly improved lossy compression ratio with significantly less visible artefacts at strong compression levels.^[78]

JPEG XT (ISO/IEC 18477) was published in June 2015; it extends base JPEG format with support for higher integer bit depths (up to 16 bit), high dynamic range imaging and floating-point coding, lossless coding, and alpha channel coding. Extensions are backward compatible with the base JPEG/JFIF file format and 8-bit lossy compressed image. JPEG XT uses an extensible file format based on JFIF. Extension layers are used to modify the JPEG 8-bit base layer and restore the high-resolution image. Existing software is forward compatible and can read the JPEG XT binary stream, though it would only decode the base 8-bit layer.^[79]

JPEG XL (ISO/IEC 18181) was published in 2021–2022. It replaces the JPEG format with a new DCT-based royalty-free format and allows efficient transcoding as a storage option for traditional JPEG images.^[80] The new format is designed to exceed the still image compression performance shown by HEIF HM, Daala and WebP. It supports billion-by-billion pixel images, up to 32-bit-per-component high dynamic range with the appropriate transfer functions (PQ and HLG), patch encoding of synthetic images such as bitmap fonts and gradients, animated images, alpha channel coding, and a choice of RGB/YCbCr/ICtCp color encoding.^{[81][82][83][84]}

• AVIF
• Better Portable Graphics, a format based on intra-frame encoding of the HEVC
• C-Cube, an early implementer of JPEG in chip form
• Comparison of graphics file formats
• Deblocking filter (video), the similar deblocking methods could be applied to JPEG
• Design rule for Camera File system (DCF)
• FELICS, a lossless image codec
• File extensions
• Graphics editing program
• High Efficiency Image File Format, image container format for HEVC and other image coding formats
• Lenna (test image), the traditional standard image used to test image processing algorithms
• Motion JPEG
• WebP

• Official website
• JPEG Standard (JPEG ISO/IEC 10918-1 ITU-T Recommendation T.81) at W3.org
• JFIF File Format at W3.org
• Example images over the full range of quantization levels from 1 to 100 at visengi.com
• JPEG decoder open source code, copyright (C) 1995–1997, Thomas G. Lane