Формат обмена файлами JPEG ( JFIF ) — это стандарт формата файла изображения, опубликованный как Рекомендация ITU-T T.871 и ISO/IEC 10918-5. Он определяет дополнительные спецификации для формата контейнера , который содержит данные изображения, закодированные с помощью алгоритма JPEG . Базовые спецификации для формата контейнера JPEG определены в Приложении B стандарта JPEG, известном как Формат обмена файлами JPEG (JIF). JFIF надстраивается над JIF, чтобы устранить некоторые ограничения JIF, включая ненужную сложность, регистрацию выборки компонентов, разрешение, соотношение сторон и цветовое пространство . Поскольку JFIF не является исходным стандартом JPG, можно было бы ожидать другой тип MIME . Однако он по-прежнему зарегистрирован как «image/jpeg» (что указывает на его основной формат данных, а не на измененную информацию).
Формат JFIF несовместим с более новым форматом файлов изображений Exchangeable (Exif).
JFIF определяет ряд деталей, которые не указаны в стандарте JPEG Часть 1 ( ISO / IEC 10918-1, Рекомендация ITU-T T.81.) [1]
JPEG позволяет нескольким компонентам (таким как Y, Cb и Cr ) иметь разные разрешения, но он не определяет, как должны быть выровнены эти отличающиеся массивы выборок (которые визуализируют битовые карты). Эта информация, производящая пиксели, визуализируется с ожиданием указания прямоугольников их центроидом , а не является данными пикселей напрямую или 'первым углом и заливкой' и т. д., что встречается нечасто.
Стандарт JPEG не включает в себя какой-либо метод кодирования разрешения или соотношения сторон изображения. JFIF предоставляет информацию о разрешении или соотношении сторон с помощью расширения сегмента приложения для JPEG. Он использует сегмент приложения #0 с заголовком сегмента, состоящим из строки с нулевым окончанием, пишущей "JFIF" в ASCII, за которой следует байт, равный 0, и указывает, что это должен быть первый сегмент в файле, что упрощает распознавание файла JFIF. Изображения Exif , записанные цифровыми камерами, обычно не включают этот сегмент, но, как правило, соответствуют во всех других отношениях стандарту JFIF.
Стандарт JPEG, используемый для кодирования сжатия в файлах JFIF, не определяет, какое цветовое кодирование должно использоваться для изображений. JFIF определяет цветовую модель , которая будет использоваться: либо Y для оттенков серого, либо YCbCr, полученный из основных цветов RGB , как определено в CCIR 601 (теперь известном как Rec. ITU-R BT.601), за исключением другого масштабирования "полного диапазона" компонентов Y, Cb и Cr. В отличие от "студийного диапазона", определенного в CCIR 601, в котором черный представлен Y=16, а белый - Y=235, и значения за пределами этого диапазона доступны для обработки сигнала "headroom" и "footroom", JFIF использует все 256 уровней 8-битного представления, так что Y=0 для черного и Y=255 для пикового белого. Основные цвета RGB, определенные в JFIF через CCIR 601, также несколько отличаются от того, что стало общепринятой практикой в новых приложениях (например, они немного отличаются от основных цветов, определенных в sRGB ). Более того, CCIR 601 (до 2007 года) не давал точного определения основных цветов RGB; вместо этого он полагался на базовые практики телевизионной индустрии.
Цветовую интерпретацию изображения JFIF можно улучшить, внедрив профиль ICC , метаданные цветового пространства или тег sRGB , а также используя приложение, которое интерпретирует эту информацию.
Файл JFIF состоит из последовательности маркеров или сегментов маркеров (подробнее см. JPEG, Синтаксис и структура ). Маркеры определены в части 1 стандарта JPEG . [1] Каждый маркер состоит из двух байтов: FFбайта, за которым следует байт, который не равен 00или FFи определяет тип маркера. Некоторые маркеры стоят отдельно, но большинство указывают на начало сегмента маркера, который содержит байты данных в соответствии со следующим шаблоном:
FF xx s1 s2 [data bytes]
Байты s1 и s2 берутся вместе, чтобы представить big-endian 16-битное целое число, указывающее длину следующих "байтов данных" плюс 2 байта, используемых для представления длины. Другими словами, s1 и s2 указывают количество следующих байтов данных как .
Согласно части 1 стандарта JPEG, приложения могут использовать сегменты маркеров APP и определять специфичное для приложения значение данных. В стандарте JFIF определены следующие сегменты маркеров APP:
Они описаны ниже.
Стандарт JFIF требует, чтобы сегмент маркера JFIF APP0 следовал сразу за маркером SOI. Если используется сегмент маркера расширения JFIF APP0, он должен следовать сразу за сегментом маркера JFIF APP0. [2] Таким образом, файл JFIF будет иметь следующую структуру:
В обязательном сегменте маркера JFIF APP0 указываются параметры изображения. Опционально может быть встроена несжатая миниатюра.
Сразу за сегментом маркера JFIF APP0 может следовать сегмент маркера расширения JFIF APP0. Этот сегмент может присутствовать только для версий JFIF 1.02 и выше. Он позволяет встраивать миниатюрное изображение в 3 различных форматах.
Данные миниатюры зависят от формата миниатюры следующим образом:
Новый формат файла изображения Exchangeable (Exif) сопоставим с JFIF, но эти два стандарта взаимно несовместимы. Это связано с тем, что оба стандарта указывают, что их конкретный сегмент приложения (APP0 для JFIF, APP1 для Exif) должен следовать сразу за маркером SOI. На практике многие программы и цифровые камеры создают файлы с включенными обоими сегментами приложения. Это не повлияет на декодирование изображения для большинства декодеров, но плохо спроектированные парсеры JFIF или Exif могут не распознать файл должным образом.
JFIF совместим с расширениями JPEG "Information Resource Block" Adobe Photoshop и метаданными модели обмена информацией IPTC , поскольку JFIF не препятствует другим сегментам приложения, а расширения Photoshop не обязаны быть первыми в файле. Однако Photoshop обычно сохраняет буферы CMYK как четырехкомпонентные "Adobe JPEG", которые не соответствуют JFIF. Поскольку эти файлы не находятся в цветовом пространстве YCbCr, они, как правило, не декодируются веб-браузерами и другим интернет-программным обеспечением.
Разработка документа JFIF была возглавлена Эриком Гамильтоном из C-Cube Microsystems , и соглашение о первой версии было достигнуто в конце 1991 года на встрече, проведенной в C-Cube с участием около 40 представителей различных компьютерных, телекоммуникационных и визуальных компаний. Вскоре после этого была опубликована небольшая редакция — JFIF 1.01. [3] В течение почти 20 лет последней доступной версией была v1.02, опубликованная 1 сентября 1992 года. [2]
В 1996 году RFC 2046 определил, что формат изображения, используемый для передачи изображений JPEG через Интернет, должен быть JFIF. Тип MIME "image/jpeg" должен быть закодирован как JFIF. Однако на практике практически все программное обеспечение Интернета может декодировать любое базовое изображение JIF , которое использует компоненты Y или YCbCr, независимо от того, совместимо ли оно с JFIF или нет.
Со временем C-Cube был реструктурирован (и в конечном итоге деградировал в Harmonic , LSI Logic , Magnum Semiconductor , Avago Technologies , Broadcom и GigOptix, GigPeak и т. д.) и потерял интерес к документу, а спецификация не имела официального издателя, пока ее не подхватили Ecma International и Объединенная группа экспертов по фотографии ITU-T/ISO/IEC около 2009 года, чтобы не допустить ее потери в истории и предоставить способ официально ссылаться на нее в стандартных публикациях и улучшить ее редакционное качество. Она была опубликована ECMA в 2009 году как Технический отчет номер 98, чтобы не допустить потери исторической записи, [3] и была официально стандартизирована ITU-T в 2011 году как Рекомендация T.871 [4] и ISO/IEC в 2013 году как ISO/IEC 10918-5, [5]. Более новые публикации включали редакционные улучшения, но не содержали существенных технических изменений.
