JPEG

JPEG o JPG ( / dʒ eɪ p ɛ ɡ / JAY -PEG ) [2] es un método comúnmente usado de compresión con pérdida para imágenes digitales , en particular para aquellas imágenes producidas por la fotografía digital . El grado de compresión se puede ajustar, lo que permite una compensación seleccionable entre el tamaño de almacenamiento y la calidad de la imagen . JPEG generalmente 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] [6] 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. [7]

JPEG
Formato JPEG logo.svg
Felis silvestris silvestris pequeña disminución gradual de la calidad.png
Una foto de un gato montés europeo con la calidad en aumento, de izquierda a derecha
Extensión de nombre de archivo.jpg, .jpeg, .jpe
.jif, .jfif,.jfi
Tipo de medio de Internet
imagen / jpeg
Código de tipoJPEG
Identificador de tipo uniforme (UTI)public.jpeg
número mágicoff d8 ff
Desarrollado porGrupo Mixto de Expertos en Fotografía , IBM , Mitsubishi Electric , AT&T , Canon Inc. , [1] Comisión de Estudio 16 del UIT-T
Versión inicial18 de septiembre de 1992 ; Hace 28 años ( 18 de septiembre de 1992 )
Tipo de formato Formato de compresión de imágenes con pérdida
EstándarUIT-T T.81, UIT-T T.83, UIT-T T.84, UIT-T T.86, ISO / IEC 10918
Sitio webwww .jpeg .org / jpeg /
"> Archivo: Compresión JPEG continuamente variada para una tomografía computarizada abdominal - 1471-2342-12-24-S1.ogvReproducir medios
Compresión JPEG continuamente variada (entre Q = 100 y Q = 1) para una tomografía computarizada abdominal

El término "JPEG" es un acrónimo del Joint Photographic Experts Group , que creó el estándar en 1992. La base de JPEG es la transformada de coseno discreta (DCT), [1] una técnica de compresión de imágenes con pérdida que fue propuesta por primera vez por Nasir Ahmed en 1972. [8] JPEG fue en gran parte responsable de la proliferación de imágenes digitales y fotografías digitales en Internet y más tarde en las redes sociales . [9]

La compresión JPEG se utiliza en varios formatos de archivo de imagen . JPEG / Exif es el formato de imagen más común utilizado por 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 . [10] 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 las versiones anteriores de Internet Explorer , que proporciona un tipo MIME de imagen / pjpeg al cargar imágenes JPEG. [11] Los archivos JPEG suelen tener una extensión de nombre de archivo.jpg o .jpeg. JPEG / JFIF admite un tamaño de imagen máximo de 65.535 × 65.535 píxeles, [12] por lo tanto, hasta 4 gigapíxeles para una relación de aspecto de 1: 1. En 2000, el grupo JPEG introdujo un formato destinado a ser un sucesor, JPEG 2000 , pero no pudo reemplazar el JPEG original como estándar de imagen dominante. [13]

Fondo

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 UIT-T , a través de la Comisión de Estudio 16 del UIT-T ) y el Grupo Conjunto de Expertos Fotográficos. [1] La base principal del algoritmo de compresión con pérdida de JPEG es la transformada de coseno discreta (DCT), [1] [14] que fue propuesta por primera vez por Nasir Ahmed como una técnica de compresión de imágenes en 1972. [8] [14] Ahmed desarrolló una algoritmo DCT práctico con T. Natarajan de la Universidad Estatal de Kansas y KR Rao de la Universidad de Texas en Arlington en 1973. [8] Su artículo fundamental de 1974 [15] se cita en la especificación JPEG, junto con varios trabajos de investigación posteriores que hicieron más trabajo sobre DCT, incluido un artículo de 1977 de Wen-Hsiung Chen, CH Smith y SC Fralick que describía un algoritmo rápido de DCT, [1] [16] así como un artículo de 1978 de NJ Narasinha y SC Fralick, y un artículo de 1984 de BG Lee. [1] La especificación también cita un artículo de 1984 de Wen-Hsiung Chen y WK Pratt como una influencia en su algoritmo de cuantificación , [1] [17] y el artículo de 1952 de David A. Huffman para su algoritmo de codificación de Huffman . [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]

  • IBM
    • Patente de EE . UU . 4,652,856 - 4 de febrero de 1986 - Kottappuram MA Mohiuddin y Jorma J. Rissanen - Código aritmético de múltiples alfabetos sin multiplicación
    • Patente de Estados Unidos 4,905,297 - 27 de febrero de 1990 - G. Langdon, JL Mitchell, WB Pennebaker y Jorma J. Rissanen - Sistema de codificación y descodificación de codificación aritmética
    • Patente de Estados Unidos 4.935.882 - 19 de junio de 1990 - WB Pennebaker y JL Mitchell - Adaptación de probabilidad para codificadores aritméticos
  • Mitsubishi Electric
    • 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 - Fumitaka Ono, Tomohiro Kimura, Masayuki Yoshida y Shigenori Kino - 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] Ausente de 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 un Algoritmo de compresión de imágenes basado en DCT, y más tarde sería motivo de controversia en 2002 (ver Controversia de patentes a continuación). [18] Sin embargo, la especificación JPEG citó dos trabajos de investigación anteriores de Wen-Hsiung Chen, publicados en 1977 y 1984. [1]

Estándar JPEG

"JPEG" significa Joint Photographic Experts Group, el nombre del comité que creó el estándar JPEG y también otros estándares de codificación de imágenes fijas. El "Conjunto" significaba ISO TC97 WG8 y CCITT SGVIII. Fundado en 1986, el grupo desarrolló el estándar JPEG a fines de la década de 1980. Entre varias técnicas de codificación de transformadas que examinaron, seleccionaron la transformada de coseno discreta (DCT), ya que era, con mucho, la técnica de compresión práctica más eficiente. El grupo publicó el estándar JPEG en 1992. [5]

En 1987, ISO TC 97 se convirtió en ISO / IEC JTC1 y, en 1992, CCITT se convirtió en ITU-T. Actualmente en el lado de 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 . [19] [20] [21] En el lado del UIT-T, el SG16 del UIT-T es el organismo respectivo. El Grupo JPEG original se organizó en 1986 [22] y publicó el primer estándar JPEG en 1992, que fue aprobado en septiembre de 1992 como Recomendación UIT-T T.81 [23] y, en 1994, como ISO / CEI 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. [24] Los estándares Exif y JFIF definen los formatos de archivo comúnmente utilizados para el intercambio de imágenes comprimidas en JPEG.

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

Compresión y codificación digital de imágenes fijas de tono continuo - Partes [20] [22] [25]
Parte Estándar ISO / IEC Rec. UIT-T Primera fecha de lanzamiento público Última enmienda Título Descripción
Parte 1 ISO / IEC 10918-1: 1994 T.81 (09/92) 18 de septiembre de 1992 Requisitos y pautas
Parte 2 ISO / IEC 10918-2: 1995 T.83 (11/94) 11 de noviembre de 1994 Pruebas de conformidad Reglas y comprobaciones de conformidad del software (a la Parte 1).
Parte 3 ISO / IEC 10918-3: 1997 T.84 (07/96) 3 de julio de 1996 1 de abril de 1999 Extensiones Conjunto de extensiones para mejorar la Parte 1, incluido el formato de archivo de intercambio de imágenes fijas (SPIFF). [26]
Parte 4 ISO / IEC 10918-4: 1999 T.86 (06/98) 18 de junio de 1998 29 de junio de 2012 Registro de perfiles JPEG, perfiles SPIFF, etiquetas SPIFF, espacios de color SPIFF, marcadores APPn, tipos de compresión SPIFF y autoridades de registro (REGAUT) métodos para registrar algunos de los parámetros utilizados para ampliar JPEG
Parte 5 ISO / IEC 10918-5: 2013 T.871 (11/05) 14 de mayo de 2011 Formato de intercambio de archivos JPEG (JFIF) Un formato popular que ha sido el formato de archivo de facto para imágenes codificadas por el estándar JPEG. En 2009, el Comité JPEG estableció formalmente un Grupo Ad Hoc para estandarizar JFIF como JPEG Parte 5. [27]
Parte 6 ISO / IEC 10918-6: 2013 T.872 (12/06) Junio ​​de 2012 Aplicación a sistemas de impresión Especifica un subconjunto de funciones y herramientas de aplicación para el intercambio de imágenes codificadas de acuerdo con ISO / IEC 10918-1 para impresión.
Parte 7 ISO / IEC 10918-7: 2019 T.873 (19/05) Mayo de 2019 Compresión y codificación digital de imágenes fijas de tono continuo Proporciona software de referencia para la tecnología de codificación especificada en la Recomendación UIT-T T.81 - ISO / IEC 10918-1. Si bien las implementaciones de referencia también proporcionan un codificador, las pruebas de conformidad de su proceso de codificación están fuera del alcance de esta Especificación.

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

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 de EE . UU. 4.698.672 de Wen- Hsiung Chen y Daniel J. Klenke. [18] [29] Si bien Forgent no era propietario de Compression Labs en ese momento, Chen luego vendió Compression Labs a Forgent, antes de que Chen pasara a trabajar para Cisco . Esto llevó a Forgent a adquirir la propiedad de la patente. [18] El anuncio de Forgent en 2002 creó un furor que recuerda 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 la patente en 2002 y fueron de la opinión de que estaban invalidados por la técnica anterior , [30] un punto de vista compartido por varios expertos. [18] [31] La patente describe un algoritmo de compresión de imágenes basado en la transformada de coseno discreta (DCT), [18] una técnica de compresión de imágenes con pérdida que se originó a partir de un artículo de 1974 de Nasir Ahmed, T. Natarajan y KR Rao . [1] [14] [15] Wen-Hsiung Chen desarrolló aún más su técnica DCT, describiendo un algoritmo DCT rápido en un artículo de 1977 con CH Smith y SC Fralick. [16] [18] La especificación JPEG de 1992 cita tanto el artículo de Ahmed de 1974 como el artículo de Chen de 1977 para su algoritmo DCT, así como un artículo de 1984 de Chen y WK Pratt para su algoritmo de cuantificación . [1] [17] Compression Labs fue fundada por Chen y fue la primera empresa en comercializar la tecnología DCT. [32] Cuando Chen presentó su patente para un algoritmo de compresión de imágenes basado en DCT con Klenke en 1986, la mayor parte de lo que luego se convertiría en el estándar JPEG ya se había formulado en la literatura anterior. [18] El representante de JPEG, Richard Clark, también afirmó que el propio Chen se sentó en uno de los comités de JPEG, pero Forgent negó esta afirmación. [18]

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

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

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. [37]

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

A partir de agosto de 2007, otra empresa, Global Patent Holdings, LLC reclamó que su patente (patente de EE . UU. 5,253,341 ) emitida en 1993 se viola 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 siendo reexaminada por la Oficina de Patentes y Marcas Registradas de los Estados Unidos de 2000 a 2007; en julio de 2007, la Oficina de Patentes revocó todas las reivindicaciones originales de la patente, pero descubrió que una reivindicación adicional propuesta por Global Patent Holdings (reivindicación 17) era válida. [38] Global Patent Holdings luego presentó una serie de demandas basadas en la reivindicación 17 de su patente.

En sus dos primeras demandas después de la reexaminación, ambas presentadas en Chicago, Illinois, Global Patent Holdings demandó a Green Bay Packers , CDW , Motorola , Apple , Orbitz , Officemax , Caterpillar , Kraft y Peapod como demandados. Se presentó una tercera demanda el 5 de diciembre de 2007 en el sur de Florida contra ADT Security Services , AutoNation , Florida Crystals Corp., HearUSA, MovieTickets.com , Ocwen Financial Corp. y Tire Kingdom , y una cuarta demanda el 8 de enero de 2008 en South 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 es inválida y no infringida.

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

El 5 de marzo de 2008, la Oficina de Marcas y Patentes de los Estados Unidos acordó reexaminar la patente '341, y encontró que el nuevo estado de la técnica planteaba nuevas cuestiones sustanciales sobre la validez de la patente. [42] A la luz del nuevo examen, los infractores acusados ​​en cuatro de las cinco demandas pendientes han presentado mociones para suspender (suspender) sus casos hasta que se complete la revisión de la patente '341 de la Oficina de Patentes y Marcas de 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. [43] El 22 de julio de 2008, la Oficina de Patentes emitió la primera "Acción de la Oficina" del segundo reexamen, encontrando la reclamación inválida con base en diecinueve motivos distintos. [44] El 24 de noviembre de 2009, se emitió un Certificado de Reexamen cancelando todas las reclamaciones.

A partir de 2011 y hasta principios de 2013, una entidad conocida como Princeton Digital Image Corporation, [45] con sede en el este de Texas, comenzó a demandar a un gran número de empresas por presunta 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 fue originalmente propiedad y asignada a General Electric. La patente expiró en diciembre de 2007, pero Princeton ha demandado a un gran número de empresas por "infracciones pasadas" de esta patente. (Según las leyes de patentes de EE. UU., El propietario de una patente puede demandar por "infracción pasada" hasta seis años antes de la presentación de una demanda, por lo que, en teoría, Princeton podría haber seguido demandando a las empresas hasta diciembre de 2013). 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. [46]

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 de la web, donde reducir la cantidad de datos utilizados para una imagen es importante para una presentación receptiva, los beneficios de compresión de JPEG hacen que JPEG sea popular. JPEG / Exif es también el formato más común que guardan las cámaras digitales.

Sin embargo, JPEG no es adecuado para dibujos de líneas 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érdidas , como TIFF , GIF o PNG . [47] El estándar JPEG incluye un modo de codificación sin pérdidas, pero ese modo no es compatible con la mayoría de los productos.

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

JPEG tampoco es adecuado para archivos que se someterán a múltiples ediciones, ya que se pierde algo de calidad de imagen cada vez que se vuelve a comprimir la imagen, especialmente si la imagen se recorta o cambia, o si se cambian los parámetros de codificación; consulte la 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, posteriormente editar 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 video del dominio espacial (2D) al dominio de frecuencia (también conocido como dominio de transformación). Un modelo perceptivo basado libremente en el sistema psicovisual humano descarta información de alta frecuencia, es decir, transiciones bruscas en intensidad y matiz de color . En el dominio de la transformación, 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 transformación es una representación conveniente de la imagen porque los coeficientes de alta frecuencia, que contribuyen menos respecto a la imagen general que otros coeficientes, son valores característicamente pequeños con alta compresibilidad. A continuación, los coeficientes cuantificados se secuencian y 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 permite al usuario cambiar la calidad de la imagen por un tamaño de archivo más pequeño. En aplicaciones integradas (como miniDV, que utiliza un esquema de compresión DCT similar), los parámetros se preseleccionan y fijan para la aplicación.

El método de compresión suele tener pérdidas, lo que significa que parte de la información de la imagen original se pierde y no se puede restaurar, lo que posiblemente afecte a la calidad de la imagen. Hay un modo sin pérdida 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 de mayor detalle progresivamente. Esto es ideal para imágenes grandes que se mostrarán durante la descarga a través de una conexión lenta, lo que permite una vista previa razonable después de recibir solo una parte de los datos. Sin embargo, la compatibilidad con archivos JPEG progresivos no es universal. Cuando los archivos JPEG progresivos son recibidos por programas que no los admiten (como las versiones de Internet Explorer anteriores a Windows 7 ) [48], el software muestra la imagen solo después de que se haya descargado por completo.

Edición sin pérdidas

Se pueden realizar varias alteraciones 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 codificada mínima) (generalmente 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 usando "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 "Recortar sin pérdida a archivo" y "Girar sin pérdida JPEG".
  • XnViewMP usando "transformaciones JPEG sin pérdida".
  • 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 pueden rotarse en incrementos de 90 grados, voltearse 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.

El borde superior e izquierdo de una imagen JPEG debe estar en un límite de bloque de 8 × 8 píxeles, pero el borde inferior y derecho no necesitan hacerlo. Esto limita las posibles operaciones de recorte sin pérdidas y también evita volteretas 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, una el límite del bloque es obligatorio).

Las rotaciones en las que el ancho y la altura de la imagen no son múltiplos de 8 o 16 (dependiendo del submuestreo de croma), no son sin pérdida. La rotación de una imagen de este tipo hace que los bloques se vuelvan a calcular, lo que da como resultado una pérdida de calidad. [49]

Cuando se usa el recorte sin pérdida, si el lado inferior o derecho de la región de cultivo no está en el límite de un bloque, el resto de los datos de los bloques parcialmente usados ​​todavía estarán presentes en el archivo recortado y se pueden recuperar. También es posible transformar entre formatos de línea base y progresivos sin ninguna pérdida de calidad, ya que la única diferencia es el orden en que se colocan los coeficientes en el archivo.

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

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

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

Se han desarrollado varios estándares adicionales para abordar estos problemas. El primero de ellos, lanzado en 1992, fue el formato de intercambio de archivos JPEG (o JFIF), seguido en los últimos años por el formato de archivo de imagen intercambiable (Exif) y los perfiles de color ICC . Ambos formatos usan el diseño de bytes JIF real, que 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, de alguna manera, JFIF es una versión reducida del estándar JIF en el sentido de que especifica ciertas restricciones (como no permitir todos los diferentes modos de codificación), mientras que de otras maneras, es una extensión de JIF debido a la adición metadatos. La documentación de la norma JFIF original establece: [50]

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 o cualquier 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 JPEG comprimidas.

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 archivos JPEG en realidad están creando archivos en formato Exif, el formato que la industria de las cámaras ha estandarizado para el intercambio de metadatos. Por otro lado, dado que el estándar Exif no permite perfiles de color, la mayoría del software de edición de imágenes almacena JPEG en formato JFIF y también incluye el segmento APP1 del archivo Exif para incluir los metadatos de una manera casi compatible; el estándar JFIF se interpreta con cierta flexibilidad. [51]

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 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.

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, sin embargo .jpe, .jfify .jiftambién se usan. También es posible que los datos JPEG se incrusten en otros tipos de archivos: los archivos codificados en TIFF suelen incrustar una imagen JPEG como una miniatura de la imagen principal; y los archivos MP3 pueden contener un JPEG de la carátula 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 pasos ; ver curva gamma .

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 van seguidos de dos bytes (alto y luego bajo), lo que indica la longitud de los datos de carga útil específicos del marcador que siguen. (La longitud incluye los dos bytes para la longitud, pero no los dos bytes para el marcador). Algunos marcadores van seguidos de datos codificados en entropía ; la longitud de dicho marcador no incluye los datos codificados por entropía. Tenga en cuenta que los bytes 0xFF consecutivos se utilizan como bytes de relleno 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 exploración codificados en 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 los marcadores se agregan después de los datos comprimidos, los bytes de relleno 0xFF opcionales pueden preceder al marcador").

Dentro de los datos codificados en entropía, después de cualquier byte 0xFF, el codificador inserta un byte 0x00 antes del siguiente byte, de modo que no parece haber un marcador donde no se pretende ninguno, evitando errores de trama. Los decodificadores deben omitir este byte 0x00. Esta técnica, denominada relleno de bytes (consulte la sección F.1.2.3 de la especificación JPEG), solo se aplica a los datos codificados por entropía, no a los datos de carga útil 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 en entropía para permitir la decodificación paralela, y los codificadores pueden insertar estos marcadores de reinicio a intervalos regulares (aunque no todos los codificadores hacen esto).

Marcadores JPEG comunes [52]
Nombre corto Bytes Carga útil Nombre Comentarios
ASIQUE 0xFF, 0xD8ningunoInicio de imagen
SOF0 0xFF, 0xC0tamaño variableInicio de fotograma (línea de base DCT) Indica que se trata de un archivo JPEG basado en DCT de referencia y especifica el ancho, la altura, el número de componentes y el submuestreo de componentes (p. Ej., 4: 2: 0).
SOF2 0xFF, 0xC2tamaño variableInicio de fotograma (DCT progresivo) Indica que se trata de un JPEG progresivo basado en DCT y especifica el ancho, la altura, el número de componentes y el submuestreo de componentes (por ejemplo, 4: 2: 0).
DHT 0xFF, 0xC4tamaño variableDefinir tabla (s) de Huffman Especifica una o más tablas de Huffman.
DQT 0xFF, 0xDBtamaño variableDefinir tabla (s) de cuantificación Especifica una o más tablas de cuantificación.
DRI 0xFF, 0xDD4 bytesDefinir intervalo de reinicio Especifica el intervalo entre marcadores RST n , en unidades codificadas mínimas (MCU). Este marcador va seguido de dos bytes que indican el tamaño fijo para que pueda tratarse como cualquier otro segmento de tamaño variable.
llamada de socorro 0xFF, 0xDAtamaño variableInicio de escaneo Comienza un escaneo de arriba a abajo de la imagen. En las imágenes JPEG de DCT de línea de base, generalmente hay un solo escaneo. Las imágenes JPEG de DCT progresivas suelen contener varios escaneos. Este marcador especifica qué segmento de datos contendrá y es seguido inmediatamente por datos codificados por entropía.
RST n 0xFF, 0xD n ( n = 0..7)ningunoReanudar Se inserta cada r macrobloques, donde r es el intervalo de reinicio establecido por un marcador DRI. No se usa si no hay marcador DRI. Los tres bits inferiores del código de marcador tienen un ciclo de valor de 0 a 7.
APLICACIÓN n 0xFF, 0xE ntamaño variableEspecífico de la aplicación Por ejemplo, un archivo Exif JPEG utiliza un marcador APP1 para almacenar metadatos, dispuestos en una estructura basada en TIFF .
COM 0xFF, 0xFEtamaño variableComentario Contiene un comentario de texto.
EOI 0xFF, 0xD9ningunoFin de imagen

Hay otros marcadores de inicio de fotograma 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 reinician y el flujo de bits se sincroniza con un límite de bytes. Los marcadores de reinicio proporcionan un medio de recuperación después de un error de flujo de bits, como la transmisión a través de una red no confiable o la corrupción de archivos. Dado que las ejecuciones de macrobloques entre marcadores de reinicio pueden decodificarse de forma independiente, estas ejecuciones pueden decodificarse en paralelo.

Aunque un archivo JPEG se puede codificar de varias formas, la mayoría de las veces se realiza 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 en Y′C B C R , que consta de un componente de luminancia (Y '), que representa el brillo, y dos componentes de crominancia , (C B y C R ), que representan el color. Este paso a veces se omite.
  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 de color fino que a los detalles de brillo fino.
  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). Un 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 se cuantifican. La visión humana es mucho más sensible a las pequeñas variaciones de color o brillo en áreas grandes que a la fuerza 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 la de los componentes de baja frecuencia. El ajuste de calidad del codificador (por ejemplo, 50 o 95 en una escala de 0 a 100 en la biblioteca del Independent JPEG Group [53] ) afecta hasta qué punto se reduce la resolución de cada componente de frecuencia. Si se utiliza un ajuste de calidad excesivamente bajo, los componentes de alta frecuencia se descartan por completo.
  5. Los datos resultantes para todos los bloques de 8 × 8 se comprimen aún más con un algoritmo sin pérdidas, una variante de la codificación de Huffman .

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

Codificación

Muchas de las opciones del estándar JPEG no se usan comúnmente y, como se mencionó anteriormente, la mayoría de los programas de imágenes usan 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 más comunes de codificación cuando se aplica a una entrada que tiene 24 bits por píxel (ocho de cada uno, rojo, verde y azul). Esta opción en 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 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 utilizado por la televisión en color digital , así como el video digital, incluidos los DVD de video , y es similar a la forma en que se representa el color en el video PAL analógico y MAC (pero no en NTSC analógico , que usa el espacio de color YIQ ). 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 perceptiva para la misma compresión). La compresión es más eficiente porque la información de brillo, que es más importante para la eventual calidad de percepción de la imagen, se limita a un solo canal. Esto se corresponde más de cerca 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 .

Una conversión particular a Y′C B C R se especifica en el estándar JFIF y 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, [54] 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.

Submuestreo

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

La transformación en la Y'C B C R modelo de color permite al siguiente paso habitual, que es reducir la resolución espacial de los componentes Cb y Cr (llamado " submuestreo " o "submuestreo de croma"). Las proporciones a 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 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 manera 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 codificada mínima (MCU) de tamaño 8 × 8 (4: 4: 4 - sin submuestreo), 16 × 8 (4: 2: 2), o más comúnmente 16 × 16 (4: 2: 0). En la compresión de video, las MCU se denominan macrobloques .

Si los datos de un canal no representan un número entero de bloques, el codificador debe llenar el área restante de los bloques incompletos con 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; la repetición de los píxeles del borde es una técnica común que reduce (pero no necesariamente elimina por completo) tales 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 en una representación de dominio de 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 denota como "DCT de tipo III".

Como ejemplo, una de esas subimágenes de 8 × 8 de 8 bits podría ser:

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

Este paso da como resultado los siguientes valores:

El DCT transforma un bloque de valores de entrada de 8 × 8 en una combinación lineal de estos 64 patrones. Los patrones se denominan funciones base 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

  • es la frecuencia espacial horizontal , para los enteros.
  • es la frecuencia espacial vertical, para los enteros .
  • es un factor de escala normalizador para hacer la transformación ortonormal
  • es el valor de píxel en las coordenadas
  • es el coeficiente DCT en las coordenadas

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 de CC (también llamado componente constante), que define el tono básico para todo el bloque. Los 63 coeficientes restantes son los coeficientes AC (también llamados componentes alternos). [55] 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 siguiente paso de cuantificación acentúa este efecto al tiempo que reduce el tamaño total 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.

El 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 (dependiendo de la fidelidad del cálculo de DCT) para almacenar. Esto puede obligar al códec a utilizar temporalmente números de 16 bits para mantener estos coeficientes, duplicando el tamaño de la representación de la imagen en este punto; estos valores se reducen normalmente de nuevo a valores de 8 bits mediante el paso de cuantificación. El aumento temporal de tamaño en esta etapa no es un problema de rendimiento para la mayoría de las implementaciones de JPEG, ya que normalmente solo una parte muy pequeña de la imagen se almacena en forma DCT completa 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, suele ocurrir que muchos de los componentes de frecuencia más alta se redondean a cero, y muchos del resto se convierten en pequeños números positivos o negativos, que requieren muchos menos bits para representarlos.

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:

Los coeficientes DCT cuantificados se calculan con

dónde son 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 de arriba da como resultado:

Izquierda: una imagen final se construye a partir de una serie de funciones básicas. Derecha: cada una de las funciones base DCT que componen la imagen, y el correspondiente coeficiente de ponderación. Medio: la función base, después de la multiplicación por el coeficiente: este componente se agrega a la imagen final. Para mayor claridad, el macrobloque de 8 × 8 en este ejemplo se amplía en 10x mediante interpolación bilineal.

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

Tenga en cuenta que la mayor parte de los elementos de mayor frecuencia de la sub-bloque (es decir, aquellos con un x o y mayor frecuencia espacial de 4) se cuantifican en valores cero.

Codificación de entropía

Orden en zigzag de componentes de imagen JPEG

La codificación de entropía es una forma especial de compresión de datos sin pérdidas . Implica disponer los componentes de la imagen en un orden en " 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 de Huffman en lo que queda.

El estándar JPEG también permite, pero no requiere, que los decodificadores admitan el uso de codificación aritmética, que es matemáticamente superior a la codificación de Huffman. Sin embargo, esta función rara vez se ha utilizado, ya que históricamente estaba cubierta por patentes que requerían licencias con derechos de autor y porque es más lenta de codificar y decodificar 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.

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

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

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

Si el bloque i -ésimo está representado por y las posiciones dentro de cada bloque están representadas por , dónde 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 píxeles (para el i -ésimo bloque) es, , , , , , , y así.

Procesos de codificación y decodificación secuenciales de JPEG de línea base

Este modo de codificación se denomina codificación secuencial básica. Baseline JPEG también admite la codificación progresiva . Mientras que la codificación secuencial codifica los coeficientes de un solo bloque a la vez (en 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. , y así. Por ejemplo, si la imagen se divide en N bloques de 8 × 8, luego una codificación progresiva de 3 escaneos codifica el componente de CC para todos los bloques (es decir, para todos , en el primer escaneo). A esto le sigue el segundo escaneo, que codifica (asumiendo cuatro componentes más) a , todavía en forma de zigzag. En este punto, la secuencia de coeficientes es:), seguido de los coeficientes restantes de todos los bloques en el último ciclo.

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 línea de base generalmente proporciona una mejor compresión en comparación con JPEG secuencial de línea de base debido a la capacidad de usar diferentes tablas de Huffman (ver más abajo) adaptadas para diferentes frecuencias en cada "escaneo" o "paso" (que incluye similares- coeficientes posicionados), aunque la diferencia no es demasiado grande.

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

Para codificar el patrón de coeficientes generado anteriormente, JPEG utiliza la codificación Huffman. El estándar JPEG proporciona tablas de Huffman de propósito general, aunque los codificadores también pueden optar por generar dinámicamente 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 zigzag comienza con una codificación de longitud de ejecución, donde:

  • x es el coeficiente de CA cuantificado distinto de cero.
  • RUNLENGTH es el número de ceros 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 de bits de x .

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

Símbolo 1Símbolo 2
(LONGITUD, TAMAÑO)(AMPLITUD)

Tanto RUNLENGTH como SIZE descansan en el mismo byte, lo que significa que cada uno solo contiene cuatro bits de información. Los bits más altos se refieren al 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 con respecto a los primeros 15 ceros que preceden al coeficiente de CA distinto de cero. Sin embargo, JPEG define dos palabras de código especiales de Huffman. Uno es para terminar la secuencia prematuramente cuando los coeficientes restantes son cero (llamado "Fin de bloque" o "EOB"), y otro para cuando la ejecución de ceros va más allá de 15 antes de alcanzar un coeficiente AC distinto de cero. En tal caso, en el que se encuentran 16 ceros antes de un coeficiente de CA distinto de cero, el símbolo 1 se codifica como (15, 0) (0).

El proceso general continúa hasta que se alcanza "EOB", denotado 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 de CC; no está codificado de la misma manera. Consulte más arriba).

A partir de aquí, los cálculos de frecuencia se realizan en función de las ocurrencias de los coeficientes. En nuestro bloque de ejemplo, la mayoría de los coeficientes cuantificados son números pequeños que no 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 un ajuste de calidad de 50. Más oscuro significa una diferencia mayor. Tenga en cuenta especialmente los cambios que ocurren cerca de los bordes afilados y que tienen una 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 agresiva en los divisores utilizados en la fase de cuantificación. Una compresión de diez a uno generalmente da como resultado una imagen que no se puede distinguir a simple vista del original. Por lo general, es posible una relación de compresión de 100: 1, pero se verá claramente con artefactos en comparación con el original. El nivel de compresión adecuado depende del uso que se le dé a la imagen.

Imagen externa
image icon Ilustración del ajetreo del borde [56]

Aquellos que 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 bloque". Estos se deben al paso de cuantificación del algoritmo JPEG. Son especialmente notables alrededor de las esquinas afiladas entre colores contrastantes (el texto es un buen ejemplo, ya que contiene muchas de esas esquinas). Los artefactos análogos en el video MPEG se conocen como ruido de mosquito , como el "borde ocupado" resultante y los puntos espurios, que cambian con el tiempo, se asemejan a los mosquitos que pululan alrededor del objeto. [56] [57]

Estos artefactos se pueden reducir eligiendo un nivel más bajo de compresión; se pueden evitar por completo si se guarda una imagen con 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 se pueden enfatizar si la imagen se procesa posteriormente, lo que generalmente da como resultado una calidad inaceptable. Considere el ejemplo siguiente, que demuestra el efecto de la compresión con pérdida en un paso de procesamiento de detección de bordes .

ImagenCompresión sin perdidasCompresión con pérdida
Original Lossless-circle.png
Procesado por el
detector de bordes Canny 		Lossless-circle-canny.pngLossy-circle-canny.png

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

Dado que la etapa de cuantificación siempre resulta en una pérdida de información, el estándar JPEG es siempre 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 coma flotante). Incluso si la matriz de cuantificación es una matriz de unos , la información se perderá en el paso de redondeo.

Descodificación

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

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

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

que se parece mucho a la matriz de 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

  • es la fila de píxeles, para los enteros .
  • es la columna de píxeles, para los enteros .
  • se define como arriba, para los enteros .
  • es el coeficiente aproximado reconstruido en las coordenadas
  • es el valor de píxel reconstruido en las coordenadas

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 agregando 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 para 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 como resultado la diferencia (original - sin comprimir) en 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 a su derecha inmediata.

Precisión requerida

La conformidad de codificación y decodificación, y por tanto los requisitos de precisión, se especifican en ISO / IEC 10918-2, es decir, la parte 2 de la especificación JPEG. Esta especificación requiere, por ejemplo, que los coeficientes DCT (transformados hacia adelante) formados a partir de una imagen de una implementación JPEG bajo prueba tengan un error dentro de la precisión de un cubo de cuantificación en comparación con los coeficientes de referencia. Con este fin, ISO / CEI 10918-2 proporciona trenes de prueba, así como los coeficientes DCT que decodificará el tren codificado.

De manera similar, ISO / IEC 10918-2 define las precisiones del codificador en términos de un error máximo permitido en el dominio DCT. Esto es inusual en la medida en que muchas otras normas definen solo la conformidad del decodificador y solo requieren que el codificador genere un tren codificado sintácticamente correcto.

Las imágenes de prueba que se encuentran en ISO / IEC 10918-2 son patrones (pseudo) aleatorios, para verificar los peores casos. Como ISO / IEC 10918-1 no define espacios de color, y tampoco incluye la transformación YCbCr a RGB de JFIF (ahora ISO / IEC 10918-5), la precisión de esta última transformación no puede ser probada por ISO / IEC 10918-2.

Para admitir la precisión de 8 bits por salida de componente de píxel, las transformaciones de descuantificación y DCT inversa se implementan típicamente con una precisión de al menos 14 bits en decodificadores optimizados.

"> Reproducir medios
Compresión repetida de una imagen (opciones de calidad aleatorias)

Los artefactos de compresión JPEG se mezclan bien en 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 relación de compresión muy alta afecta gravemente a la calidad de la imagen, aunque los colores generales y la forma de la imagen aún son reconocibles. Sin embargo, la precisión de los colores sufre menos (para un ojo humano) que la precisión de los contornos (basada en 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 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 que se indican a continuación incluyen los encabezados de información JPEG internos y algunos metadatos . Para imágenes de la más alta calidad (Q = 100), se requieren aproximadamente 8,25 bits por píxel de color. [ cita requerida ] En imágenes en escala de grises, un mínimo de 6.5 bits por píxel es suficiente (una información de color de calidad Q = 100 comparable requiere aproximadamente un 25% más de bits codificados). La imagen de mayor calidad a continuación (Q = 100) está codificada a nueve bits por píxel de color, la imagen de calidad media (Q = 25) usa 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 solo 0,13 bits por píxel y muestra un color muy deficiente. Esto es útil cuando la imagen se mostrará en un tamaño significativamente reducido. Un método para crear mejores matrices de cuantificación para una calidad de imagen dada usando PSNR en lugar del factor Q se describe en Minguillón & Pujol (2001). [58]

Nota: Las imágenes anteriores no son imágenes de prueba IEEE / CCIR / EBU  y la configuración del codificador no está especificada ni disponible.
ImagenCalidadTamaño (bytes)Índice de compresiónComentario
Máxima calidad (Q = 100) 81,447 2,7: 1 Artefactos extremadamente menores
Alta calidad (Q = 50) 14,679 15: 1 Signos iniciales de artefactos de subimagen
Calidad media (Q = 25) 9.407 23: 1 Artefactos más fuertes; pérdida de información de alta frecuencia
Baja calidad (Q = 10) 4.787 46: 1 La pérdida severa de alta frecuencia conduce a artefactos obvios en los límites de las subimágenes ("macrobloqueo")
Calidad más baja (Q = 1) 1,523 144: 1 Pérdida extrema de color y detalle; las hojas son casi irreconocibles.

La foto de calidad media utiliza solo el 4,3% del espacio de almacenamiento necesario para la imagen sin comprimir, pero tiene poca pérdida de detalles o artefactos visibles. Sin embargo, una vez que se supera un cierto umbral de compresión, las imágenes comprimidas muestran defectos cada vez más visibles. Consulte el artículo sobre la teoría de la distorsión de la 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 superpuestos. Los diseños más modernos, como JPEG 2000 y JPEG XR, exhiben una degradación de la calidad más elegante a medida que disminuye el uso de bits, mediante el uso de transformaciones con una mayor extensión espacial para los coeficientes de frecuencia más bajos y el uso de funciones de base de transformación superpuestas.

De 2004 a 2008, surgieron nuevas investigaciones sobre formas de comprimir aún más los datos contenidos en las imágenes JPEG sin modificar la imagen representada. [59] [60] [61] [62] Esto tiene aplicaciones en escenarios donde la imagen original solo está disponible en formato JPEG y su tamaño debe reducirse para su archivo o transmisión. 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:

  • Correlaciones entre magnitudes de coeficientes adyacentes en el mismo bloque;
  • Correlaciones entre magnitudes del mismo coeficiente en bloques adyacentes;
  • Correlaciones entre magnitudes del mismo coeficiente / bloque en diferentes canales;
  • Los coeficientes de CC, cuando se toman en conjunto, se asemejan a una versión a escala reducida de la imagen original multiplicada por un factor de escala. Se pueden aplicar esquemas bien conocidos para la codificación sin pérdidas de imágenes de tono continuo , logrando una compresión algo mejor que el DPCM codificado por Huffman utilizado en JPEG.

Algunas opciones estándar, pero que rara vez se utilizan, ya existen en JPEG para mejorar la eficiencia de la codificación de los 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 de cada coeficiente se codifican de forma independiente y cada coeficiente tiene un valor significativamente diferente). distribución). Los métodos modernos han mejorado estas técnicas al reordenar los coeficientes para agrupar coeficientes de mayor magnitud; [59] utilizando coeficientes y bloques adyacentes para predecir nuevos valores de coeficientes; [61] dividir bloques o coeficientes entre un pequeño número de modelos codificados independientemente en función de sus estadísticas y valores adyacentes; [60] [61] y más recientemente, decodificando bloques, prediciendo bloques subsiguientes en el dominio espacial y luego codificándolos para generar predicciones para los coeficientes DCT. [62]

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

Una herramienta disponible de forma gratuita llamada packJPG se basa en el documento de 2007 "Reducción de redundancia mejorada para archivos JPEG". [63] Un artículo de 2016 titulado "JPEG con esteroides" utilizando ISO libjpeg muestra que las técnicas actuales, con pérdida o no, pueden hacer que JPEG sea casi tan eficiente como JPEG XR ; mozjpeg usa técnicas similares. [64] JPEG XL es un nuevo formato de archivo que puede volver a codificar un JPEG sin pérdidas con una conversión posterior eficiente a JPEG.

Para 3D estereoscópico

JPEG estereoscópico

Un ejemplo de un archivo .JPS estereoscópico

JPEG estereoscópico (JPS, extensión .jps) es un formato basado en JPEG para imágenes estereoscópicas . [65] [66] Tiene una variedad de configuraciones almacenadas en el campo de marcador JPEG APP3, pero generalmente contiene una imagen de doble ancho, que representa dos imágenes de tamaño idéntico en bizco (es decir, marco izquierdo en la mitad derecha de la imagen y viceversa) disposición de 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 imagen múltiple JPEG

El formato JPEG de múltiples imágenes (MPO, extensión .mpo) es un formato basado en JPEG para almacenar múltiples imágenes en un solo archivo. Contiene dos o más archivos JPEG concatenados juntos. [67] [68] También define un segmento de marcador JPEG APP2 para la descripción de la imagen. Varios dispositivos lo utilizan para almacenar imágenes en 3D, como Fujifilm FinePix Real 3D W1 , HTC Evo 3D , videocámara de extensión JVC GY-HMZ1U AVCHD / MVC, Nintendo 3DS , Sony PlayStation 3 , [69] Sony PlayStation Vita , [70] 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 uso creciente de imágenes estereoscópicas, la comunidad científica ha realizado muchos esfuerzos para desarrollar algoritmos para la compresión de imágenes estereoscópicas. [71] [72]

JPEG XT

JPEG XT (ISO / IEC 18477) se publicó en junio de 2015; amplía el formato JPEG base con soporte para profundidades de bits enteras 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. [73]

JPEG XL

Desde agosto de 2017, JTC1 / SC29 / WG1 emitió una serie de proyectos de convocatorias de propuestas sobre JPEG XL, el estándar de compresión de imágenes de próxima generación con una eficiencia de compresión sustancialmente mejor (mejora del 60%) en comparación con JPEG. [74] Se espera que el estándar supere el rendimiento de compresión de imágenes fijas mostrado por HEVC HM, Daala y WebP y , a diferencia de los esfuerzos anteriores que intentaban reemplazar JPEG, para proporcionar una opción de almacenamiento y transporte de recompresión más eficiente sin pérdidas para imágenes JPEG tradicionales. [75] [76] [77] Los requisitos básicos incluyen soporte para imágenes de muy alta resolución (al menos 40 MP), 8-10 bits por componente, codificación de color RGB / YCbCr / ICtCp, imágenes animadas, codificación de canal alfa, Rec. . 709 espacio de color ( sRGB ) y función gamma (potencia 2.4), Rec. Espacio de color con una amplia gama de colores de 2100 (Rec. 2020) y funciones de transferencia de alto rango dinámico ( PQ y HLG ), y compresión de alta calidad de imágenes sintéticas, como fuentes de mapa de bits y degradados. El estándar también debe ofrecer profundidades de bits más altas (entero de 12-16 bits y punto flotante), espacios de color adicionales y funciones de transferencia (como Log C de Arri ), imágenes de vista previa integradas, codificación de canal alfa sin pérdidas, codificación de región de imagen y baja frecuencia. codificación de complejidad. Todas las tecnologías patentadas recibirían una licencia libre de regalías . Las propuestas se presentaron en septiembre de 2018, lo que dio lugar a un borrador del comité en julio de 2019, con la fecha de publicación prevista actual en octubre de 2019. [78] [77] El formato de archivo (bitstream) se congeló el 25 de diciembre de 2020, lo que significa que el formato ahora se garantiza que se podrá decodificar en futuras versiones. [79]

Estándares JPEG incompatibles

El Grupo Conjunto de Expertos en Fotografía también es responsable de algunos otros formatos que llevan el nombre JPEG, incluidos JPEG 2000 , JPEG XR y JPEG XS .

Una implementación muy importante de un códec JPEG fue 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. [80] Las versiones recientes introducen extensiones propietarias que rompieron la compatibilidad ABI con versiones anteriores . En muchos proyectos de software destacados, libjpeg ha sido reemplazado por libjpeg-turbo , que ofrece un mayor rendimiento, compatibilidad SIMD y compatibilidad con versiones anteriores de las versiones originales de libjpeg. [81]

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 para PNG y otros formatos de datos sin pérdida). [82]

ISO / IEC Joint Photography Experts Group mantiene una implementación de software de referencia que puede codificar las extensiones JPEG base (ISO / IEC 10918-1 y 18477-1) y JPEG XT (ISO / IEC 18477 Partes 2 y 6-9), así como JPEG-LS (ISO / IEC 14495). [83]

  • AVIF
  • Mejores gráficos portátiles , un formato basado en la codificación intracuadro de HEVC
  • C-Cube , uno de los primeros en implementar JPEG en forma de chip
  • Comparación de formatos de archivos gráficos
  • Comparación de motores de diseño (gráficos)
  • Filtro de desbloqueo (video) , los métodos de desbloqueo similares podrían aplicarse a JPEG
  • Regla de diseño para el sistema de archivos de cámara (DCF)
  • Extensiones de archivo
  • Programa de edición de gráficos
  • Formato de archivo de imagen de alta eficiencia , formato de contenedor de imagen para HEVC y otros formatos de codificación de imágenes
  • Formato de intercambio de archivos JPEG
  • Lenna (imagen de prueba) , la imagen estándar tradicional utilizada para probar los algoritmos de procesamiento de imágenes
  • Códec de imagen sin pérdida FELICS
  • Motion JPEG

  1. ^ a b c d e f g h i j k l m "T.81 - COMPRESIÓN DIGITAL Y CODIFICACIÓN DE IMÁGENES FIJAS EN TONO CONTINUO - REQUISITOS Y DIRECTRICES" (PDF) . CCITT . Septiembre de 1992 . Consultado el 12 de julio de 2019 .
  2. ^ "Definición de 'JPEG ' " . Diccionario inglés Collins . 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 de la vida (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. ^ UIT (4 de octubre de 2019). "Cómo JPEG, lanzado en 1992, ganó fama Emmy en 2019" . Actualidades de la UIT . Archivado desde el original el 20 de junio de 2021 . Consultado el 20 de junio de 2021 .
  5. ^ a b Hudson, Graham; Léger, Alain; Niss, Birger; Sebestyén, István; Vaaben, Jørgen (31 de agosto de 2018). "Estándar JPEG-1 de 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 .
  6. ^ "Explicación del formato de imagen JPEG" . BT.com . BT Group . 31 de mayo de 2018. Archivado desde el original el 5 de agosto de 2019 . Consultado el 5 de agosto de 2019 .
  7. ^ Baraniuk, Chris (15 de octubre de 2015). "Las protecciones de copia podrían llegar a JPegs" . BBC News . BBC . Consultado el 13 de septiembre de 2019 .
  8. ^ a b c Ahmed, Nasir (enero de 1991). "Cómo se me ocurrió la transformada discreta del coseno" . Procesamiento de señales digitales . 1 (1): 4–5. doi : 10.1016 / 1051-2004 (91) 90086-Z .
  9. ^ "¿Qué es un JPEG? El objeto invisible que ves todos los días" . El Atlántico . 24 de septiembre de 2013 . Consultado el 13 de septiembre de 2019 .
  10. ^ "Archivo HTTP - Estadísticas interesantes" . httparchive.org . Consultado el 6 de abril de 2016 .
  11. ^ Detección de tipo MIME en Internet Explorer: tipos MIME cargados (msdn.microsoft.com)
  12. ^ Hamilton, Eric (1 de septiembre de 1992). "Formato de intercambio de archivos JPEG" (PDF) . jpeg.org . Milpitas, California . Archivado desde el original (PDF) el 3 de septiembre de 2014 . Consultado el 11 de abril de 2020 .
  13. ^ "Por qué JPEG 2000 nunca despegó" . Instituto Nacional Estadounidense de Estándares . 10 de julio de 2018 . Consultado el 13 de septiembre de 2019 .
  14. ^ a b c "JPEG: 25 Jahre und kein bisschen alt" . Heise online (en alemán). Octubre de 2016 . Consultado el 5 de septiembre de 2019 .
  15. ^ a b Ahmed, Nasir ; Natarajan, T .; Rao, KR (enero de 1974), "Discrete Cosine Transform", IEEE Transactions on Computers , C-23 (1): 90–93, doi : 10.1109 / TC.1974.223784
  16. ^ a b Chen, Wen-Hsiung; Smith, C .; Fralick, S. (1977). "Un algoritmo computacional rápido para la transformada discreta del coseno". Transacciones IEEE sobre comunicaciones . 25 (9): 1004–1009. doi : 10.1109 / TCOM.1977.1093941 . ISSN  0090-6778 .
  17. ^ a b Chen, Wen-Hsiung; Pratt, WK (1984). "Codificador adaptativo de escena". Transacciones IEEE sobre comunicaciones . 32 (3): 225–232. doi : 10.1109 / TCOM.1984.1096066 . ISSN  0090-6778 .
  18. ^ a b c d e f g h Lemos, Robert (23 de julio de 2002). "Encontrar la verdad patente en la reivindicación JPEG" . CNET . Consultado el 13 de julio de 2019 .
  19. ^ 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 .
  20. ^ a b ISO / IEC JTC 1 / SC 29. "Programa de trabajo, (Asignado a SC 29 / WG 1)" . Archivado desde el original el 31 de diciembre de 2013 . Consultado el 7 de noviembre de 2009 .
  21. ^ YO ASI. "JTC 1 / SC 29 - Codificación de información de audio, imagen, multimedia e hipermedia" . Consultado el 11 de noviembre de 2009 .
  22. ^ a b JPEG. "Grupo conjunto de expertos en fotografía, página de inicio JPEG" . Consultado el 8 de noviembre de 2009 .
  23. ^ "T.81: Tecnología de la información - Compresión digital y codificación de imágenes fijas de tono continuo - Requisitos y directrices" . Itu.int . Consultado el 7 de noviembre de 2009 .
  24. ^ 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.
  25. ^ YO ASI. "JTC 1 / SC 29 - Codificación de información de audio, imagen, multimedia e hipermedia" . Consultado el 7 de noviembre de 2009 .
  26. ^ "SPIFF, formato de archivo de intercambio de imágenes fijas" . Biblioteca del Congreso . 2012-01-30. Archivado desde el original el 31 de julio de 2018 . Consultado el 31 de julio de 2018 .
  27. ^ JPEG (24 de abril de 2009). "JPEG XR entra en estado FDIS: Formato de intercambio de archivos JPEG (JFIF) para estandarizarlo como JPEG Parte 5" (Comunicado de prensa). Archivado desde el original el 8 de octubre de 2009 . Consultado el 9 de noviembre de 2009 .
  28. ^ "Formato de intercambio de archivos JPEG (JFIF)" . ECMA TR / 98 1ª ed . Ecma International . 2009 . Consultado el 1 de agosto de 2011 .
  29. ^ "Patente JPEG de Forgent" . SourceForge . 2002 . Consultado el 13 de julio de 2019 .
  30. ^ "Sobre las recientes reivindicaciones de patentes" . Jpeg.org . 2002-07-19. Archivado desde el original el 14 de julio de 2007 . Consultado el 29 de mayo de 2011 .
  31. ^ "JPEG y JPEG2000 - Entre la disputa de patentes y el cambio de tecnología" . Archivado desde el original el 17 de agosto de 2004 . Consultado el 16 de abril de 2017 .
  32. ^ Stanković, Radomir S .; Astola, Jaakko T. (2012). "Reminiscencias de los primeros trabajos en DCT: Entrevista con KR Rao" (PDF) . Reimpresiones de los primeros días de las ciencias de la información . 60 . Consultado el 13 de octubre de 2019 .
  33. ^ Kawamoto, Dawn (22 de abril de 2005). "La demanda de patentes de gráficos dispara contra Microsoft" . Noticias CNET . Consultado el 28 de enero de 2009 .
  34. ^ "La Oficina de Marcas Reexamina la Patente JPEG Forgente" . Publish.com . 3 de febrero de 2006. Archivado desde el original el 15 de mayo de 2016 . Consultado el 28 de enero de 2009 .
  35. ^ "USPTO: afirmaciones más amplias afirmaciones forzadas contra estándar JPEG no válido" . Groklaw.net . 26 de mayo de 2006 . Consultado el 21 de julio de 2007 .
  36. ^ "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 .
  37. ^ "Reclamación de patente JPEG renunciada" . Fundación de Patentes Públicas . 2 de noviembre de 2006. Archivado desde el original el 2 de enero de 2007 . Consultado el 3 de noviembre de 2006 .
  38. ^ "Certificado de reexamen ex parte de la patente estadounidense nº 5.253.341" . Archivado desde el original el 2 de junio de 2008.
  39. ^ 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 .
  40. ^ "Una recompensa de $ 5,000 para nombrar a Troll Tracker: Ray Niro quiere saber quién está diciendo todas esas cosas desagradables sobre él" . Law.com . Consultado el 29 de mayo de 2011 .
  41. ^ Reimer, Jeremy (5 de febrero de 2008). "Caza de trolls: la USPTO pidió reexaminar la patente de imagen amplia" . Arstechnica.com . Consultado el 29 de mayo de 2011 .
  42. ^ Oficina de Patentes de EE. UU. - Concesión de reexamen en 5.253.341 C1
  43. ^ "Juez pone patente JPEG sobre hielo" . Techdirt.com . 2008-04-30 . Consultado el 29 de mayo de 2011 .
  44. ^ "Reclamación única de la patente JPEG rechazada (y golpeada por una buena medida)" . Techdirt.com . 2008-08-01 . Consultado el 29 de mayo de 2011 .
  45. ^ 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 .
  46. ^ Grupo de trabajo. "Artículo sobre el fallo de la corte de Princeton sobre el contrato de licencia de GE" . Archivado desde el original el 9 de marzo de 2016 . Consultado el 1 de mayo de 2013 .
  47. ^ "2 razones para utilizar PNG sobre JPEG" . Luna de recursos .
  48. ^ "Resumen de decodificación progresiva" . Red de desarrolladores de Microsoft . Microsoft . Consultado el 23 de marzo de 2012 .
  49. ^ "Por qué siempre debería rotar fotos JPEG originales sin pérdida" . Petapixel.com . Consultado el 16 de octubre de 2017 .
  50. ^ "Formato de archivo JFIF como PDF" (PDF) .
  51. ^ Tom Lane (29 de marzo de 1999). "Preguntas frecuentes sobre la compresión de imágenes JPEG" . Consultado el 11 de septiembre de 2007 . (q. 14: "¿Por qué toda la discusión sobre los formatos de archivo?")
  52. ^ "ISO / IEC 10918-1: 1993 (S) p . 36" .
  53. ^ Thomas G. Lane. "Funciones avanzadas: selección de parámetros de compresión" . Usando la biblioteca JPEG de IJG .
  54. ^ Ryan, Dan (20 de junio de 2012). Módulos de aprendizaje electrónico: Serie Dlr Associates . AuthorHouse. ISBN 978-1-4685-7520-0.
  55. ^ "Preguntas de frecuencia CC / CA - Foro de Doom9" . forum.doom9.org . Consultado el 16 de octubre de 2017 .
  56. ^ a b Phuc-Tue Le Dinh y Jacques Patry. Artefactos de compresión de video y reducción de ruido MPEG [ enlace muerto permanente ] . Línea de diseño de imágenes de vídeo. 24 de febrero de 2006. Consultado el 28 de mayo de 2009.
  57. ^ " 3.9 ruido de mosquito: forma de distorsión de los bordes ocupados 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 video Archivado el 16 de febrero de 2010 en la Wayback Machine.
  58. ^ 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 secuenciales y progresivos" (PDF) . Imágenes electrónicas . 10 (2): 475–485. Código bibliográfico : 2001JEI .... 10..475M . doi : 10.1117 / 1.1344592 . hdl : 10609/6263 .
  59. ^ a b I. Bauermann y E. Steinbacj. Mayor compresión sin pérdida de imágenes JPEG. Proc. of Picture Coding Symposium (PCS 2004), San Francisco, EE. UU., 15-17 de diciembre de 2004.
  60. ↑ a b N. Ponomarenko, K. Egiazarian, V. Lukin y J. Astola. Compresión adicional sin pérdida de imágenes JPEG, Proc. del 4º Intl. 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.
  61. ^ a b c d M. Stirner y G. Seelmann. Reducción de redundancia mejorada para archivos JPEG. Proc. del Simposio de Codificación de Imágenes (PCS 2007), Lisboa, Portugal, 7 al 9 de noviembre de 2007
  62. ^ a b c Ichiro Matsuda, Yukio Nomoto, Kei Wakabayashi y Susumu Itoh. Recodificación sin pérdida de imágenes JPEG mediante predicción intra adaptativa por bloques. Actas de la XVI Conferencia Europea de Procesamiento de Señales (EUSIPCO 2008).
  63. ^ "Últimas versiones binarias de packJPG: V2.3a" . 3 de enero de 2008. Archivado desde el original el 23 de enero de 2009.
  64. ^ Richter, Thomas (septiembre de 2016). "JPEG en ESTEROIDES: técnicas de optimización comunes para la compresión de imágenes JPEG". Conferencia internacional de IEEE sobre procesamiento de imágenes (ICIP) de 2016 : 61–65. doi : 10.1109 / ICIP.2016.7532319 . ISBN 978-1-4673-9961-6. S2CID  14922251 . Lay resumen .
  65. ^ J. Siragusa; DC Swift (1997). "Descriptor de datos estereoscópicos de propósito general" (PDF) . VRex, Inc., Elmsford, Nueva York . Archivado desde el original (PDF) el 30 de octubre de 2011.
  66. ^ Tim Kemp, archivos JPS
  67. ^ "Formato de múltiples imágenes" (PDF) . 2009 . Consultado el 26 de diciembre de 2019 .
  68. ^ "MPO2Stereo: Convertir archivos MPO de Fujifilm a pares estéreo JPEG" , Mtbs3d.com , consultado el 12 de enero de 2010
  69. ^ "Tipos de archivos de PS3 que se pueden visualizar" . 2019 . Consultado el 29 de febrero de 2020 .
  70. ^ "Tipos de archivos que puede ver con la aplicación Fotos" . 2019 . Consultado el 29 de febrero de 2020 .
  71. ^ Alessandro Ortis; Sebastiano Battiato (2015), Sitnik, Robert; Puech, William (eds.), "Un nuevo método de coincidencia rápido para la compresión adaptativa de imágenes estereoscópicas" , Procesamiento de imágenes tridimensionales, Procesamiento de imágenes tridimensionales, medición (3DIPM) y Aplicaciones 2015, SPIE - Procesamiento de imágenes tridimensionales , Measurement (3DIPM), and Applications 2015, 9393 : 93930K, Bibcode : 2015SPIE.9393E..0KO , doi : 10.1117 / 12.2086372 , S2CID  18879942 , consultado el 30 de abril de 2015
  72. ^ Alessandro Ortis; Francesco Rundo; Giuseppe Di Giore; Sebastiano Battiato, Adaptive Compression of Stereoscopic Images , International Conference on Image Analysis and Processing (ICIAP) 2013 , consultado el 30 de abril de 2015
  73. ^ "JPEG - JPEG XT" . jpeg.org .
  74. ^ "JPEG - Convocatoria de propuestas de borrador final de compresión de imágenes de próxima generación (JPEG XL)" . Jpeg.org . Consultado el 29 de mayo de 2018 .
  75. ^ Alakuijala, Jyrki; van Asseldonk, Ruud; Boukortt, Sami; Bruse, Martin; Comșa, Iulia-Maria; Firsching, Moritz; Fischbacher, Thomas; Kliuchnikov, Evgenii; Gómez, Sebastián; Obryk, Robert; Potempa, Krzysztof; Rhatushnyak, Alexander; 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". Aplicaciones del procesamiento de imágenes digitales XLII . pag. 20. doi : 10.1117 / 12.2529237 . ISBN 978-1-5106-2967-7. S2CID  202785129 .
  76. ^ "Google Pik 試 し て み た" . Archivado desde el original el 22 de agosto de 2019 . Consultado el 22 de agosto de 2019 .
  77. ^ a b Rhatushnyak, Alexander; Wassenberg, Jan; Sneyers, Jon; Alakuijala, Jyrki; Vandevenne, Lode; Versari, Luca; Obryk, Robert; Szabadka, Zoltan; Kliuchnikov, Evgenii; Comsa, Iulia-Maria; Potempa, Krzysztof; Bruse, Martin; 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 ].
  78. ^ "N79010 Final Call for Proposals for a Next-Generation Image Coding Standard (JPEG XL)" (PDF) . ISO / IEC JTC 1 / SC 29 / WG 1 (ITU-T SG16) . Consultado el 29 de mayo de 2018 .
  79. ^ "v0.2 · Etiquetas · Software de referencia jpeg / JPEG XL" . GitLab .
  80. ^ "Descripción general de JPEG" . jpeg.org . Consultado el 16 de octubre de 2017 .
  81. ^ Software que utiliza o proporciona libjpeg-turbo . 9 de febrero de 2012.
  82. ^ "Anuncio de Guetzli: un nuevo codificador JPEG de código abierto" . Research.googleblog.com . Consultado el 16 de octubre de 2017 .
  83. ^ "JPEG - JPEG XT" . jpeg.org .

  • Estándar JPEG (JPEG ISO / IEC 10918-1 Recomendación UIT-T T.81) en W3.org
  • Sitio oficial del Joint Photographic Experts Group (JPEG)
  • Formato de archivo JFIF en W3.org
  • Visor de JPEG en 250 líneas de código Python fácil de entender
  • Compresor JPEG de dominio público en un solo archivo fuente de C ++, junto con un descompresor coincidente en code.google.com
  • Código fuente abierto del decodificador JPEG, derechos de autor (C) 1995–1997, Thomas G. Lane