El formato de intercambio de archivos JPEG ( JFIF ) es un estándar de formato de archivo de imagen publicado como Recomendación ITU-T T.871 e ISO/IEC 10918-5. Define especificaciones complementarias para el formato contenedor que contiene los datos de imagen codificados con el algoritmo JPEG . Las especificaciones básicas para un formato contenedor JPEG se definen en el Anexo B del estándar JPEG, conocido como Formato de intercambio JPEG (JIF). JFIF se basa en JIF para resolver algunas de las limitaciones de JIF, incluida la complejidad innecesaria, el registro de muestras de componentes, la resolución, la relación de aspecto y el espacio de color . Debido a que JFIF no es el estándar JPG original, se podría esperar otro tipo MIME . Sin embargo, todavía está registrado como "image/jpeg" (lo que indica su formato de datos primario en lugar de la información modificada).
JFIF es mutuamente incompatible con el nuevo formato de archivo de imagen intercambiable (Exif).
JFIF define una serie de detalles que no se especifican en el estándar JPEG Parte 1 ( ISO / IEC 10918-1, Recomendación ITU-T T.81). [1]
JPEG permite que varios componentes (como Y, Cb y Cr ) tengan diferentes resoluciones, pero no define cómo se deben alinear esas diferentes matrices de muestras (que representan mapas de bits). Esta información que produce píxeles se representa con la expectativa de indicar rectángulos por su centroide , en lugar de ser datos de píxeles directamente, o ser "primera esquina y inundación", etc., lo cual es poco común.
El estándar JPEG no incluye ningún método para codificar la resolución o la relación de aspecto de una imagen. JFIF proporciona información sobre la resolución o la relación de aspecto mediante una extensión de segmento de aplicación para JPEG. Utiliza el segmento de aplicación n.° 0, con un encabezado de segmento que consiste en la cadena terminada en cero que escribe "JFIF" en ASCII seguida de un byte igual a 0, y especifica que este debe ser el primer segmento del archivo, lo que facilita el reconocimiento de un archivo JFIF. Las imágenes Exif grabadas por cámaras digitales generalmente no incluyen este segmento, pero por lo general cumplen en todos los demás aspectos con el estándar JFIF.
El estándar JPEG utilizado para la codificación de compresión en archivos JFIF no define qué codificación de color se debe utilizar para las imágenes. JFIF define el modelo de color que se debe utilizar: Y para escala de grises o YCbCr derivado de los colores primarios RGB según se define en CCIR 601 (ahora conocido como Rec. ITU-R BT.601), excepto con una escala de "rango completo" diferente de los componentes Y, Cb y Cr. A diferencia del "rango de estudio" definido en CCIR 601, en el que el negro se representa por Y=16 y el blanco por Y=235 y los valores fuera de este rango están disponibles para el "margen de espacio" y "espacio libre" del procesamiento de señales, JFIF utiliza los 256 niveles de la representación de 8 bits, de modo que Y=0 para el negro e Y=255 para el blanco máximo. Los colores primarios RGB definidos en JFIF a través de CCIR 601 también difieren un poco de lo que se ha convertido en una práctica común en aplicaciones más nuevas (por ejemplo, difieren ligeramente de los colores primarios definidos en sRGB ). Además, CCIR 601 (antes de 2007) no proporcionaba una definición precisa de los colores primarios RGB; en cambio, se basaba en las prácticas subyacentes de la industria de la televisión.
La interpretación del color de una imagen JFIF se puede mejorar incorporando un perfil ICC , metadatos de espacio de color o una etiqueta sRGB y utilizando una aplicación que interprete esta información.
Un archivo JFIF consta de una secuencia de marcadores o segmentos de marcadores (para obtener más información, consulte JPEG, Sintaxis y estructura ). Los marcadores se definen en la parte 1 del estándar JPEG . [1] Cada marcador consta de dos bytes: un FFbyte seguido de un byte que no es igual a 00o FFy especifica el tipo de marcador. Algunos marcadores son independientes, pero la mayoría indican el comienzo de un segmento de marcador que contiene bytes de datos de acuerdo con el siguiente patrón:
FF xx s1 s2 [data bytes]
Los bytes s1 y s2 se toman juntos para representar un entero big-endian de 16 bits que especifica la longitud de los siguientes "bytes de datos" más los 2 bytes utilizados para representar la longitud. En otras palabras, s1 y s2 especifican la cantidad de los siguientes bytes de datos como .
De acuerdo con la parte 1 del estándar JPEG, las aplicaciones pueden utilizar segmentos de marcadores APP y definir un significado específico de los datos para cada aplicación. En el estándar JFIF, se definen los siguientes segmentos de marcadores APP:
Se describen a continuación.
El estándar JFIF requiere que el segmento marcador APP0 de JFIF siga inmediatamente al marcador SOI. Si se utiliza un segmento marcador APP0 de extensión JFIF, debe seguir inmediatamente al segmento marcador APP0 de JFIF. [2] Por lo tanto, un archivo JFIF tendrá la siguiente estructura:
En el segmento obligatorio del marcador JFIF APP0 se especifican los parámetros de la imagen. Opcionalmente, se puede incorporar una miniatura sin comprimir.
Inmediatamente después del segmento marcador APP0 de JFIF puede haber un segmento marcador APP0 de extensión de JFIF. Este segmento solo puede estar presente en las versiones 1.02 y posteriores de JFIF. Permite incrustar una imagen en miniatura en 3 formatos diferentes.
Los datos de la miniatura dependen del formato de la miniatura de la siguiente manera:
El nuevo formato de archivo de imagen intercambiable (Exif) es comparable a JFIF, pero ambos estándares son incompatibles entre sí. Esto se debe a que ambos estándares especifican que su segmento de aplicación particular (APP0 para JFIF, APP1 para Exif) debe seguir inmediatamente al marcador SOI. En la práctica, muchos programas y cámaras digitales producen archivos con ambos segmentos de aplicación incluidos. Esto no afectará la decodificación de imágenes de la mayoría de los decodificadores, pero los analizadores JFIF o Exif mal diseñados pueden no reconocer el archivo correctamente.
JFIF es compatible con las extensiones JPEG "Information Resource Block" de Adobe Photoshop y con los metadatos del modelo de intercambio de información IPTC , ya que JFIF no excluye otros segmentos de la aplicación y no es necesario que las extensiones de Photoshop sean las primeras en el archivo. Sin embargo, Photoshop generalmente guarda los buffers CMYK como "Adobe JPEG" de cuatro componentes que no son compatibles con JFIF. Dado que estos archivos no están en un espacio de color YCbCr, normalmente no son decodificables por los navegadores web y otro software de Internet.
El desarrollo del documento JFIF estuvo a cargo de Eric Hamilton de C-Cube Microsystems y el acuerdo sobre la primera versión se estableció a fines de 1991 en una reunión celebrada en C-Cube en la que participaron unos 40 representantes de varias empresas de computación, telecomunicaciones e imágenes. Poco después, se publicó una revisión menor: JFIF 1.01. [3] Durante casi 20 años, la última versión disponible fue la v1.02, publicada el 1 de septiembre de 1992. [2]
En 1996, la RFC 2046 especificó que el formato de imagen utilizado para transmitir imágenes JPEG a través de Internet debería ser JFIF. El tipo MIME de "image/jpeg" debe codificarse como JFIF. Sin embargo, en la práctica, prácticamente todo el software de Internet puede decodificar cualquier imagen JIF de referencia que utilice componentes Y o YCbCr, ya sea compatible con JFIF o no.
Con el paso del tiempo, C-Cube se reestructuró (y finalmente se transformó en Harmonic , LSI Logic , Magnum Semiconductor , Avago Technologies , Broadcom y GigOptix, GigPeak, etc.) y se perdió interés en el documento, y la especificación no tuvo un editor oficial hasta que fue retomada por Ecma International y el Grupo Mixto de Expertos en Fotografía ITU-T/ISO/IEC alrededor de 2009 para evitar que se perdiera en la historia y proporcionar una forma de citarla formalmente en publicaciones estándar y mejorar su calidad editorial. Fue publicada por ECMA en 2009 como Informe Técnico número 98 para evitar la pérdida del registro histórico, [3] y fue estandarizada formalmente por ITU-T en 2011 como su Recomendación T.871 [4] y por ISO/IEC en 2013 como ISO/IEC 10918-5, [5] Las publicaciones más nuevas incluyeron mejoras editoriales pero ningún cambio técnico sustancial.
