8) Конечный шаг - кодирование Хаффмана

Сначала ВАЖНОЕ примечание: Вместо хранения фактической величины, JPEG стандарт определяет, что мы храним минимальный размер в битах, в котором мы можем держать эту величину (это названо категория этой величины) и затем битно кодированное представление этой величины подобно этому:

Впоследствии для предшествующего примера:

(0,57); (0,45); (4,23); (1,-30); (0,-8); (2,1); (0,0)

давайте закодируем ТОЛЬКО правую величину этих пар, кроме пар, которые являются специальными маркерами подобно (0,0) или (если мы должны иметь) (15,0)

57 - в категории 6 и это – битно кодированный 111001, так что мы закодируем это как (6,111001)

45, аналогично, будет закодирован как (6,101101)

23 -> (5,10111)

-30 -> (5,00001)

-8 -> (4,0111)

1 -> (1,1)

И теперь, мы напишем снова строку пар:

(0,6), 111001; (0,6), 101101; (4,5), 10111; (1,5), 00001; (0,4), 0111; (2,1), 1; (0,0)

Пары 2 величин, заключенные в скобки, могут быть представлены в байте, так как фактически каждая из 2 величин может быть представлена в 4-битном кусочке (счетчик предшествующих нулей - всегда меньше, чем 15 и также как и категория [числа закодированные в файле JPG - в области -32767..32767]). В этом байте, старший кусочек представляет число предшествующих нулей, а младший кусочек - категорию новой величины, отличной от 0.

КОНЕЧНЫЙ шаг кодировки состоит в кодировании Хаффмана этого байта, и затем записи в файле JPG, как поток из битов, кода Хаффмана этого байта, сопровождающийся битовым представлением этого числа.

Например, для байта 6 (эквивалент (0,6)) у нас есть код Хаффмана = 111000;

для байта 69 = (4,5) (например) у нас есть 1111111110011001

21 = (1,5) — 11111110110

4 = (0,4) — 1011

33 = (2,1) — 11011

0 = EOB= (0,0) — 1010

Конечный поток битов записанных в файле JPG на диск для предшествующего примера 63 коэффициентов (запомните, что мы пропустили первый коэффициент) -

111000 111001 111000 101101 1111111110011001 10111 11111110110 00001

1011 0111 11011 1 1010

Кодирование коэффициента DC

DC является коэффициентом на квантованном векторе соответствующем самой низкой частоте в образе (это - 0 частота), и (перед квантованием) - математически = (сумма 8x8 составляющих)/8. (Это - подобно средней величине для этого блока образцов изображения). Сказано, что он содержит много энергии, присутствующей в исходном изображении блока 8x8. (Обычно, это большие величины). Авторы JPEG стандарта обращали внимание, что есть очень близкое соотношение между коэффициентом DC последовательных блоков, так что они решили кодировать в файле JPG различие между DC последовательными блоками 8x8 (Примечание: последовательные блоки 8x8 одинаковых компонентов изображения, подобно последовательным блокам 8x8 для Y, или последовательные блоки для Cb, или для Cr)

Diff = DC_i – DC_i-1; Так DC текущего блока (DC_i) равен: DC_i = DC_i-1 + Diff

Декодируя JPG, Вы начнете с 0 - Вы рассмотрите первым коэффициентом DC = 0;

DC₀ = 0

А затем Вы добавите к текущей величине величину, декодированную из JPG (Diff величину)

Так, в файле JPG, первый коэффициент = коэффициент DC является действительно отличительным, и это – Хаффман-кодирование отличается от кодирования коэффициентов AC.

Здесь это - как это сделано: (Запомните, что мы теперь кодируем Diff величину)

Diff предшествует, как Вы видели, представлению категории и, это – бит-кодированное представление. В файле JPG будет Хаффманом закодирована только величина категории, подобно этому:

Diff = (Категория, битно кодированное представление)

Затем Diff будет закодирован как (код_Хаффмана (категория), битно кодированное представление)

Например, если Diff равняется -511, тогда Diff соответствует

(9, 000000000)

Допустим, что 9 имеет код Хаффмана = 1111110 (В файле JPG, есть 2 таблицы Хаффмана для каждого компонента изображения: для DC и для AC)

В файле JPG, биты соответствующие коэффициенту DC будут:

1111110 000000000

И, относившийся к этому примеру DC и в предшествующем примере AC, для этого вектора с 64 коэффициентами, КОНЕЧНЫЙ ПОТОК БИТОВ, записанных в файле JPG, будет:

1111110 000000000 111000 111001 111000 101101 1111111110011001 10111

11111110110 00001 1011 0111 11011 1 1010

(В файле JPG, сначала закодировано DC, затем AC)

ДЕШИФРАТОР ХАФФМАНА (краткий итог)

для 64 коэффициентов (Единиц Данных) компонента изображения (Например Y)

Так, когда Вы декодируете поток битов с изображения в файле JPG, Вы сделаете:

Инициализируйте DC = 0.

1. Сначала декодируйте коэффициент DC:

   1. Выберите правильный код Хаффмана (проверьте, существует ли он в DC таблице Хаффмана).

   2. Посмотрите, какой категории этот код Хаффмана соответствует.

   3. Пусть N равно категории битов, и определите, какая величина представлена (категория, выбранные биты N) = Diff

   4. DC + = Diff

   5. Запишите DC в 64 вектор: "вектор[0]=DC"

2. Декодируйте 63 коэффициента AC:

- ДЛЯ каждого коэффициента AC ДО ТЕХ ПОР, ПОКА (EOB достигнут ИЛИ AC_счетчик=64)

1. Выберите правильный код Хаффмана (проверьте существование в таблице Хаффмана)

2. Декодируйте этот код Хаффмана: Код Хаффмана соответствует (число предшест 0,категория)

[Помните: EOB достигнут = ВЕРНО, если (число предшест 0, категория) = (0,0)]

3. Пусть N равно категории битов, и определите, какая величина представлена (категория, выбранные биты N) = AC коэффициент

4. Запишите в 64 векторе, число нулей = число предшест 0

5. Увеличьте AC счетчик на число предшест 0 (число предшествующих нулей)

6. Запишите AC коэффициент в векторе: "вектор[AC счетчик]=AC коэффициент"

Следующие Шаги

Так, теперь у нас есть вектор из 64 элементов.

Мы сделаем возобновление шагов представленных в этом док.:

1. Выполните обратное квантование для 64 вектора:

"для (i=0; i<=63; i++) вектор[i]*=квант[i]"

2. Перестройте 64 элемента из зигзагообразного вектора в блок 8x8

3. Примените обратное DCT-преобразование в блок 8x8

Повторите предыдущие операции [дешифратор Хаффмана, шаги 1), 2) и 3)]

для каждого блока 8x8 каждого компонента образа (Y,Cb,Cr).

4. Обработайте, если требуется

5. Сдвиньте по уровню величины (добавьте 128 ко всем 8-битовых знаковым величинам в блоках 8x8, полученным IDCT-преобразованием (обратным DCT))

6. Преобразуйте YCbCr в RGB

7. - И... JPG изображение

JPEG Маркеры и/или как организована информация изображения в файле JPG

(Байтовый уровень)

ПРИМЕЧАНИЕ: JPEG/JFIF файловый формат использует формат Motorola для целых (двухбайтовых) значений, НЕ формат Intel, то есть: сначала старший байт, затем - младший (например: двухбайтовое целое значение FFA0 будет записано в JPEG файле в порядке: FF в младшем смещении, A0 в старшем смещении)

Стандарт JPG определяет, что JPEG файл сформирован в основном из частей, названных "сегментами". Сегмент является потоком байтов с длиной <= 65535. Сегментное начало определяется маркером. Маркер = 2 байта, начиная с 0xFF (C-шестнадцатеричная запись для 255), и заканчивая байтом, отличным от 0 и 0xFF. Например: 'FFDA', 'FFC4', 'FFC0'. Каждый маркер имеет значение: второй байт (отличный от 0 и 0xFF) определяет функцию этого маркера. Например, есть маркер, который определяет, что Вы должны запускать декодирование процесса, это обозначается (стандартная терминология JPG): SOS = Начало Сканирования = 'FFDA'

Другой маркер, названный DQT = Определение Таблицы Квантования = 0xFFDB, определяет, что в файле JPG, после маркера (и после 3 байтов, дополнительно об этом позже) следуют 64 байта = коэффициенты таблицы квантования.

Если, в течение обработки файла JPG, Вы встречаете 0xFF, затем снова байт, отличный от 0 (Я сообщил Вам, что второй байт маркера - не 0) и этот байт не имеет значение маркера (Вы не можете найти маркер, соответствующий этому байту), тогда байт 0xFF, который Вы встретили, должен игнорироваться и пропускаться. (В некоторых JPG-файлах, последовательности последовательных 0xFF - для некоторого заполнения и должны пропускаться)

Вы видите, что всякий раз, когда Вы встречаете 0xFF, Вы проверяете следующий байт и смотрите, имеет ли значение маркера или должно быть пропущено. Что случается, если нам действительно нужно кодировать байт 0xFF в файле JPG как *обычный* байт (не маркер или заполнение)? (Допустим, что нам нужно писать код Хаффмана, который начинается с 11111111 (8 битов 1) на перестановке байтов) Стандарт сообщает, что мы просто делаем следующий байт 0, и пишем последовательность 'FF00' в файл JPG. Так, когда Ваш дешифратор JPG встречает 2-байтовую последовательность 'FF00', он должен рассмотреть ее как обычный байт 0xFF.

Другая вещь: Вы понимаете, что эти маркеры являются выровненными по байту в файле JPG. Что случается, если в течение вашего кодирования Хаффмана и, включая биты в файловых байтах JPG, Вы не завершили включать биты в байт, но Вам нужно писать маркер, который является выровненным по байту? Для перестановки байтов маркеров, Вы УСТАНАВЛИВАЕТЕ ОСТАЛЬНЫЕ БИТЫ ДО НАЧАЛА СЛЕДУЮЩЕГО БАЙТА НА 1, тогда Вы пишите маркер в следующем байте.

Короткое объяснение некоторых важных маркеров, содержащихся в файле JPG.

SOI = Начало Изображения = 'FFD8'

Этот маркер должен присутствовать в любом файле JPG *однажды* в начале файла. (Любой файл JPG начинается с последовательности FFD8.)

EOI = Конец Изображения = 'FFD9'

Подобно EOI: любой файл JPG заканчивается на FFD9.

RSTi = FFDi (где i - значения 0..7) [RST0 = FFD0, RST7=FFD7]

= Маркеры Перезапуска

Эти маркеры перезапуска используются для синхронизации. В регулярных нтервалах, они появляются в потоке JPG байтов, в течение декодирования процесса (после SOS)

(Они появляются в порядке: RST0 - интервал - RST1 - интервал - RST2 -...

...- RST6 - интервал - RST7 - интервал - RST0 -...)

(Замечание: Большинство JPG-файлов не имеет маркеров перезапуска)

Проблема с этими маркерами – в том, что они прерывают нормальный битовый порядок в Хаффман-кодированном битовом потоке JPG. Запомните, что для байтового выравнивания маркеров остальные биты устанавливаются на 1, так что Ваш дешифратор должен пропустить в регулярные интервалы бесполезные биты заполнения (установленные в 1) и маркеры RST.

Маркеры...

В конце этого документа, я включил очень хорошее письменное техническое объяснение JPEG/JFIF файлового формата, записанное Oliver Fromme, автором QPEG-просмотрщика. Там Вы найдете довольно хорошее и полное определение для маркеров.

Но, во всяком случае, здесь - список маркеров, которые Вы должны проверять:

Таблица Хаффмана, сохраненная в файле JPG

Здесь - как JPEG содержит дерево Хаффмана: вместо дерева, он определяет таблицу в файле JPG после DHT (Определение Таблицы Хаффмана) маркера. ПРИМЕЧАНИЕ: длина кодов Хаффмана ограничивается 16 битами.

В основном есть 2 типа таблиц Хаффмана в файле JPG: одна для DC и одна для AC (действительно есть 4 таблицы Хаффмана: 2 для DC, AC для яркости и 2 для DC, AC цветоразности)

Они сохраняются в файле JPG в том же формате, который состоит из:

1. 16 байтов:

байт i содержит число кодов Хаффмана длины i (длина в битах)

i изменяется от 1 до 16

2. Таблица с длиной (в байтах) = S_i=1 число кодов длины i

которая содержит в позиции [k][j] (k в 1..16, j в 0..(число кодов с длиной k-1)) БАЙТОВУЮ величину, связанную с j-ым кодом Хаффмана длины k. (Для фиксированной длины k, величины сохранены, отсортированными по величине кода Хаффмана).

В этой таблице Вы можете найти фактический код Хаффмана, связанный с конкретным байтом.

Например: (Примечание: количество кодов для данной длины - здесь для этого конкретного примера, чтобы считать это, они могут иметь любые другие величины)

ДОПУСТИМ что,

Для длины 1 мы имеем число_кодов[1]=0, мы пропускаем эту длину

Для длины 2 у нас есть 2 кода 00

01

Для длины 3 у нас есть 3 кода 100

101

110

Для длины 4 у нас есть 1 код 1110

Для длины 5 у нас есть 1 код 11110

Для длины 6 у нас есть 1 код 111110

Для длины 7 у нас есть 0 кодов – пропускаем

(если у нас был 1 код для длины 7, мы должны иметь 1111110)

Для длины 8 у нас есть 1 код 11111100 (Вы видите, что код все еще перемещается на оставленное, хотя мы пропустили кодовую величину для 7)

.....

Для длины 16,... (та же вещь)

Я сообщил Вам, что в таблице Хаффмана в файле JPG загружены БАЙТОВЫЕ величины для данного кода.

Для этого конкретного примера кодов Хаффмана:

Допустим, что в таблице Хаффмана в файле JPG на диске мы имеем (после тех 16 байтов, которые содержат число кодов Хаффмана с данной длиной):

45 57 29 17 23 25 34 28

Эти величины соответствуют конкретным длинам, которые я Вам дал перед этим, в кодах Хаффмана это будет:

нет величины для кода длины 1

для кодов длины 2 : у нас есть 45 57

для кодов длины 3 : 3 величины (например : 29,17,23)

для кодов длины 4 : только 1 величина (например: 25)

для кодов длины 5 : 1 величина (например: 34)

...

для кода длины 7, снова никакая величина, переходим к коду с длиной 8

для кода длины 8 : 1 величина 28

ВАЖНОЕ примечание:

Для кодов длины 2:

величина 45 соответствует коду 00

57 соответствует коду 01

Для кодов длины 3:

величина 29 соответствует коду 100

17 соответствует коду 101

23 соответствует коду 110

И Т.П...

(Я сообщил Вам, что для данной длины байтовые величины хранятся в порядке увеличения величины кода Хаффмана.)

Четыре таблицы Хаффмана соответствуют DC и AC таблицам яркости, и DC и AC таблицам для цветоразности, даются в приложении JPEG стандарта как предложение для шифратора. Стандарт сообщает, что эти таблицы протестированы с хорошими результатами сжатия для многих изображений и рекомендует их, но шифратор может использовать любую другую таблицу Хаффмана. Много шифраторов JPG используют эти таблицы. Некоторые предлагаются на Ваш выбор: оптимизация энтропии - если возможно, используйте таблицы Хаффмана, оптимизированные для этого конкретного изображения.

JFIF (Jpeg Формат Взаимозаменяемого Файла) файл

JPEG стандарт (что в файле itu-1150.ps) как-нибудь очень обобщенный, JFIF реализация является конкретным случаем этого стандарта (и он является, конечно, совместимым со стандартом). JPEG стандарт определяет некоторые маркеры, зарезервированные для приложений (под приложениями я подразумеваю конкретные случаи осуществления стандарта) Эти маркеры названы APPn, где n изменяется от 0 до 0xF; APPn = FFEn. JFIF спецификация использует маркер APP0 (FFE0), чтобы идентифицировать файл JPG, который использует эту спецификацию. Вы увидите в JPEG стандарте, что он имеет отношение к "компонентам образа". Эти компоненты образа могут быть (Y,Cb,Cr) или (YIQ) или все, что угодно. JFIF реализации использует только (Y,Cb,Cr) для цветного JPG, или только Y для монохромного JPG.

Показатели (факторы) дискретизации

Примечание: следующее объяснение раскрывает кодировку цветных (3 компонента) JPG-файлов; для черно-белых JPG-файлов есть один компонент (Y), который - обычно никак необработанный совсем, и не требует любого обратного преобразования подобно инверсии (Y,Cb,Cr) -> (R,G,B). Впоследствии, черно-белые JPG-файлы - самые простейшие для декодирования: для каждого блока 8x8 в изображении Вы делаете декодирование Хаффмана кодированного вектора RLC, который затем Вы преобразовываете из зигзага, деквантуете 64 вектор и, наконец, Вы применяете к нему обратное DCT и прибавляете 128 (сдвиг уровня) к новым величинам 8x8.

Я сообщил Вам, что компоненты изображения обработаны. Обычно Y взято для каждый пикселя, и Cb, Cr взяты для блока пикселей 2x2. Но есть некоторые JPG-файлы, в которых Cb, Cr взяты для каждого пикселя, или некоторые JPG-файлы где Cb, Cr взяты для каждых 2 пикселей (горизонтальная дискретизация на 2 пикселях, и вертикальная дискретизация на каждом пикселе) Показатели дискретизации для компонента образа в файле JPG определяются в отношении (относительном) в самом высшем показателе дискретизации.

Вот показатели дискретизации для наиболее обычного примера: Y взято на каждый пиксель, и Cb, Cr взяты для блока пикселей 2x2 (JFIF спецификация дает формулу для показателей дискретизации, которая я думаю, что работает только когда максимальный показатель дискретизации для каждого измерения X или Y <=2) JPEG стандарт не определяет показатели дискретизации.

Вы видите, что Y будет иметь самую высшую частоту дискретизации:

Горизонтальный показатель дискретизации = 2 = HY

Вертикальный показатель дискретизации = 2 = VY

Для Cb, Горизонтальный показатель дискретизации = 1 = HCb

Вертикальный показатель дискретизации = 1 = VCb

Для Cr, Горизонтальный показатель дискретизации = 1 = HCr

Вертикальный показатель дискретизации = 1 = VCr

Действительно эта форма определения показателей дискретизации вполне полезна. Вектор 64 коэффициентов для компонента изображения, кодированных Хаффманом, назван

DU = Единица Данных (стандартная терминология JPEG)

В файле JPG, порядок кодировки Единиц Данных:

1. закодируйте Единицу Данных для первого компонента изображения:

для (счетчик_y=1; счетчик_y<=VY; счетчик_y++)

для (счетчик_x=1; счетчик_x<=HY; счетчик_x++)

{ кодировать Единицу Данных для Y }

2. закодируйте Единицу Данных для второго компонента изображения:

для (счетчик_y=1; счетчик_y<=VCb ; счетчик_y++)

для (счетчик_x=1; счетчик_x<=HCb; счетчик_x++)

{ кодировать Единицу Данных для Cb }

3. наконец, для третьего компонента, аналогично:

для (счетчик_y=1; счетчик_y<=VCr; счетчик_y++)

для (счетчик_x=1; счетчик_x<=HCr; счетчик_x++)

{ кодировать Единицу Данных для Cr }

Для примера я дал Вам (HY=2, VY=2; HCb=VCb =1, HCr, VCr=1) здесь это – цифра:

YDU YDU CbDU CrDU

YDU YDU

(YDU - Единица Данных (DU) для Y, и аналогично CbDU DU для Cb, CrDU = DU для Cr) Эта обычная комбинация показателей дискретизации обозначается 2:1:1 как для вертикальных, так и для горизонтальных показателей дискретизации.

И, конечно, в файле JPG порядок кодирования будет:

YDU,YDU,YDU,YDU,CbDU,CrDU

Вы знаете, что DU (64 коэффициента) определяют блок величин 8x8, таким образом, здесь мы определили кодирующий порядок для блока пикселей изображения 16x16 (Пиксель изображения (Y,Cb,Cr)): Четыре блока 8x8 величин Y (4 YDUs), один блок 8x8 величин Cb (1 CbDU) и один блок 8x8 величин Cr (1 CrDU)

(Hmax = Максимальный горизонтальный показатель дискретизации, Vmax = максимальный вертикальный показатель дискретизации) Впоследствии для этого примера показателей дискретизации (Hmax = 2, Vmax=2), шифратор должен обрабатывать ОТДЕЛЬНО каждый 16x16 = блок пикселей образа (Hmax*8 x Vmax*8) в упомянутом порядке.

Этот блок пикселей изображения размерами (Hmax*8,Vmax*8) называется, в стандартной терминологии JPG, MCU = Минимальная Кодированная Единица.

Для предшествующего примера: MCU = YDU,YDU,YDU,YDU,CbDU,CrDU

Другой пример показателей дискретизации:

HY =1, VY =1

HCb=1, VCb=1

HCr=1, VCr=1

Цифра/порядок: YDU CbDU CrDU

Вы видите, что здесь определены пиксель образа блока 8x8 (MCU) с 3 8x8 блоками:

один для Y, один для Cb и один для Cr (Совсем нет обработки)

Здесь (Hmax=1, Vmax=1) MCU имеет измерение (8,8), и MCU = YDU,CbDU,CrDU

In the JPG file, the sampling factors for every image component are defined after the marker SOF0 = Start Of Frame 0 = FFC0

Для черно-белых JPG-файлов Вы не должны побеспокоиться о порядке кодировки единиц данных в MCU. Для этих JPG, MCU = 1 Единица Данных (MCU = YDU)

В файле JPG, показатели дискретизации для каждого компонента образа определены после маркера SOF0 = Начало Кадра 0 = FFC0

Краткая схема декодирования файла JPG

Дешифратор читает из файла JPG показатели дискретизации, он обнаруживает размеры MCU (Hmax*8,Vmax*8) => сколько MCU - в целом изображении, затем декодирует каждую MCU, присутствующую в исходном изображении (цикл для всех этих блоков, или пока не обнаружится маркер EOI [это должно обнаружиться, когда кончится цикл, в противном случае Вы получите неполное изображение]) - он декодирует MCU, декодируя каждую Единицу Данных в MCU в порядке упомянутом перед этим, и наконец, пишет расшифрованный цветной блок пикселей (Hmax*8 x Vmax*8) в (R,G,B) буфер изображения.

Видео MPEG-1 и JPEG

Интересная часть спецификации MPEG-1 (и вероятно MPEG-2) - то, что она полагается сильно на JPEG спецификацию. Он использует много понятий, представленных здесь. Причина в том, что каждые 15 кадров, или, когда это нужно, есть независимый кадр названный I-кадр (Интра фрейм), который JPEG закодирован. (Между прочим, блок 16x16 пикселей изображения в примере, который я Вам дал, называется, в стандартной терминологии MPEG, макроблок) За исключением алгоритмов для компенсации движения, видео MPEG-1 положились во многом на спецификацию JPG (DCT-преобразование, квантование, и т.п.)

Техническое объяснение JPEG/JFIF файлового формата,

записанного Oliver Fromme, автором QPEG-просмотрщика

JPEG/JFIF формат файла:

• заголовок (2 байта): $ff, $d8 (SOI) (эти два идентифицируют JPEG/JFIF файл)

• для JFIF файлов, сегмент APP0 немедленно следует за маркером SOI, смотрите ниже

• любое число "сегментов" (подобно IFF (Image File Format) кускам), смотрите ниже

• хвостовик (2 байта): $ff, $d9 (EOI)

Формат сегмента:

• заголовок (4 байта):

$ff идентифицирует сегмент

n тип сегмента (один байт)

sh, sl размер сегмента, включая эти два байта, но не включая $ff и байт типа. Примечание, не порядок Intel: сначала старший байт, затем младший байт!

• содержимое сегмента, максимум 65533 байта.

Примечания:

• Есть сегменты без параметров (обозначенные '*'), которые не имеет спецификацию размера (и никакого содержания), просто $ff и байт типа.

• Любое число $ff байтов между сегментами легальное и должно быть пропущено.

Типы сегментов:

Все другие типы сегментов резервируются и должны быть проигнорированы (пропущены).

SOF0: Начало Кадра 0:

• $ff, $c0 (SOF0)

• длина (старший байт, младший байт), 8+components*3

• точность данных (1 байт) в битах/единицу, обычно 8 (12 и 16 не поддерживается большинством программного обеспечения)

• высота изображения (2 байта, High-Low), должно быть >0, если DNL не поддерживается

• ширина изображения (2 байта, High-Low), должно быть >0, если DNL не поддерживается

• количество компонентов (1 байт), обычно 1 = черно-белый, 3 = цвет YCbCr или YIQ, 4 = цвет CMYK)

• для каждого компонента: 3 байта

• идентификатор компонента (1 = Y, 2 = Cb, 3 = Cr, 4 = I, 5 = Q)

• показатели дискретизации (бит 0-3 вертикальной, 4-7 горизонтальной)

• номер таблицы квантования

Замечания:

• JFIF использует также 1 компонент (Y, черно-белое изображение) или 3 компонента (YCbCr, иногда называемое YUV, цветное).

APP0: JFIF маркер сегмента:

• $ff, $e0 (APP0)

• длина (старший байт, младший байт), должна быть >= 16

• 'JFIF'#0 ($4a, $46, $49, $46, $00), идентифицирует JFIF

• номер общей версии, должен быть 1 (в противном случае ошибка)

• номер подверсии, должен быть 0..2 (в противном случае попытка декодирования по-другому)

• единица для x/y разрешения:

0 = нет никаких единиц, x/y-отношение определяет соотношение аспекта

1 = x/y-разрешение в точках/дюйм

2 = x/y-разрешение в точках/сантиметр

• x-разрешение (старший байт, младший байт), должно быть <> 0

• y-разрешение (старший байт, младший байт), должно быть <> 0

• ширина предварительного просмотра (1 байт)

• высота предварительного просмотра (1 байт)

• n байт для предварительного просмотра (RGB 24 бит) n = ширина*высота*3

Замечания:

• Если нет 'JFIF'#0, или длина <16, тогда это - вероятно не JFIF сегмент и должен быть проигнорирован.

• Нормально единицы=0, x-разрешение=1, y-разрешение=1, означает, что отношение числа точек - 1:1 (равномерно масштабированное).

• JFIF файлы с предварительным просмотром встречаются очень редко, предварительный просмотр может обычно быть проигнорирован. Если нет предварительного просмотра, тогда ширина=0 и высота=0.

• Если длина не соответствует размеру предварительного просмотра, можно выдать предупреждение, затем продолжить декодирование.

DRI: Определение Интервала Перезапуска:

• $ff, $dd (DRI)

• длина (старший байт, младший байт), должна быть = 4

• интервал перезапуска (старший байт, младший байт) в единицах блоков MCU, означает, что каждые n блоков MCU может быть найден маркер RSTn.

• Первый маркер будет RST0, затем RST1 и т.п., после RST7 повторится с RST0.

DQT: Определение Таблицы Квантования:

• $ff, $db (DQT)

• длина (старший байт, младший байт)

• информация о таблице квантования (1 байт):

биты 0..3: номер таблицы (0..3, в противном случае ошибка)

биты 4..7: точность таблицы, 0 = 8 бит, в противном случае 16 бит

• n байт таблицы n = 64*(точность+1)

Замечания:

• Единственный сегмент DHT может содержать несколько таблиц, каждая со своим собственным байтом информации.

COM: Комментарий:

• $ff, $fe (COM)

• длина (старший байт, младший байт) комментария = L+2

• Комментарий = байтовый поток длиной L

SOS: Начало Сканирования:

• $ff, $da (SOS)

• длина (старший байт, младший байт), должна быть 6+2*(количество компонентов сканирования)

• количество компонентов сканирования (1 байт), должно быть >=1 и <=4 (в противном случае ошибка), обычно 1 или 3

• для каждого компонента: 2 байта

• идентификатор компонента (1 = Y, 2 = Cb, 3 = Cr, 4 = I, 5 = Q), смотри SOF0

• использование таблицы Хаффмана:

биты 0..3: таблица AC (0..3)

биты 4..7: таблица DC (0..3)

• 3 байта, которые должны игнорироваться

Замечания:

• Данные об изображении (данные сканирования) следуют сразу за сегментом SOS.