Двухмерное кодирование Group 4 (g42d)

Принцип двухмерного кодирования Group 4 (G42D) был разработан на базе алгоритма G32D как усовершенст­вованная схема двухмерного сжатия и оказался настолько удачным, что схема Group 4 почти полностью заменила Group 3 в коммерческом применении.

Схема Group 4 идентична Group 3, но между ними есть несколько различий. В частности, в Group 4 не применяются коды EOL и не учитывается значение переменной К, поскольку эта схема была разработана специально для кодирования данных, размещенных на дисковых накопителях и в сетях передачи данных. Характерные для Group 3 возможности выявления и коррекции ошибок при передаче данных, закодированных по схеме Group 4, оказались невостребованными.

Первая справочная строка кодируется в Group 4 как воображаемая строка развертки, состоящая только из белых пикселей. В G32D первой справочной строкой является первая строка развертки изображения. При кодировании по схеме Group 4 кодовое слово RTC заменяется кодом "Конец блока факсимильных данных" (EOFB), состоящим из двух кодовых слов EOL Group 3. Подобно RTC в Group 3, код EOFB является частью протокола передачи, а не частью данных изображения. Данные изображения, закодированные по схеме Group 4, могут также набиваться битами-за­полнителями от EOFB до границы байта.

Кодирование с использованием Group 4 обычно сжимает изображение до размера, вдвое меньшего чем тот, которого можно достичь с помощью кодирования по схеме G31D, но является более сложной операцией и требует больших затрат времени. Однако при аппаратной реализации различие в скорости между алгоритмами Group 3 и Group 4 не имеет значения, что обычно и определяет выбор Group 4.

Советы по разработке кодировщиков и декодеров ccitt

Если вы используете метод CCITT для кодирования и декодирования, рекомендуем вам придерживаться нескольких общих принципов:

• Игнорируйте биты, поступающие после маркеров RTC или EOFB. Эти маркеры указывают конец данных изображения, и все биты, пришедшие после них, могут рассматриваться как заполнители.

• Вы должны знать количество пикселей в строке развертки до того, как начнете декодирование. Любая строка, которая при декодировании будет иметь меньше или больше пикселей, чем обычно ожидается, рассматривается как поврежденная, а декодирование всего блока изображения (только двухмерное кодирование) не производится. При некоторых схемах кодирования строки развертки, содержащие только белые пиксели, могут быть укороченными. В этом случае декодер должен дополнять каждую такую строку до необходимого размера единичной белой группой.

• Помните, что при декодировании длина строки развертки не всегда кратна восьми, поэтому декодеры не должны предполагать, что такая строка будет дополнена до границы байта. Они должны "уметь" читать данные, не выровненные по границам байтов.

• Если декодер встретит маркер RTC или EOFB до того, как будет декодировано ожидаемое количество строк развертки, то предполагается, что все оставшиеся строки развертки белые. Если же ожидаемое количество строк развертки уже декодировано, а RTC или EOFB еще не поступили, декодирование следует остановить. Декодер при этом должен выдать предупреждение о том, что возникла непредвиденная ситуация.

• Обратите внимание на то, что профессионально разработанные декодеры CCITT должны быть способны решать типичные проблемы битового и цветового пола, связанные с однобитовыми данными:

• CCITT-кодирование определяет пиксельное значение 0 как белый цвет, а значение 1 — как черный. Однако многие растры могут быть сохранены с противоположными пиксельными цветовыми значениями, и в этом случае декодер создаст "негатив" данного изображения (проблемы цветового пола). Порядок записи битов в байт определяет архитектура машины: в одном случае первым записывается самый старший бит, в другом — самый младший. Если растровые данные читаются в формате, противоположном тому, в котором они были записаны, то изображение может появиться в виде фрагментов или содержать "дырки" (проблема битового пола). Чтобы избежать подобных проблем, декодер CCITT должен быть способен читать данные с применением любых схем цветового и битового пола, удовлетворяющих требованиям пользователя.

Сжатие JPEG

На сегодняшний день JPEG является одним из наиболее актуальных направлений развития технологии сжатия изображений. Аббревиатура JPEG происходит от названия комитета по стандартам Joint Photographic Experts Group (Объединенная группа экспертов по фотографии), входящего в состав Международной организации по стандартизации (ISO). В 1982 году ISO сформировала группу экспертов по фотографии (PEG), возложив на нее обязанности по проведению исследований в области передачи видеосигналов, неподвижных изображений и текстов по каналам ISDN (интегральная цифровая сеть связи). Перед PEG была поставлена задача разработать набор промышленных стандартов по передаче графических данных и данных изображений с помощью цифровых коммуникационных сетей.

В 1986 году подгруппой СС1ТТ были начаты исследования методов сжатия цветных и полутоновых данных для факсимильной связи. Применяемые при этом методы сжатия цветных данных очень напоминали те, которые исследовались PEG. Было принято решение объединить ресурсы этих групп для совместной работы над единым стандартом.

В 1987 году ISO и СС1ТТ объединили свои группы в комитет, который должен был провести исследования и выпустить один стандарт сжатия данных, который применялся бы обеими организациями. Новый комитет получил название JPEG.

Создатели JPEG могли предусмотреть множество коммерческих программ на базе разрабатываемой технологии, поскольку потребители с нетерпением ждали маркетинговых предложений по получению изображений и мультимедиа. Большинство из ранее разработанных методов сжатия были практически не пригодны для сжатия данных многоградационных изображений, содержащих сотни и тысячи цветов, взятых из реального мира. Очень мало файловых форматов могли поддерживать 24-битовые растровые изображения.

Например, формат GIF позволял сохранять только изображения с максимальной пиксельной глубиной 8 битов, т.е. не более 256 цветов. Его алгоритм сжатия (LZW) мало подходил для типичных данных сканированного изображения. Шум, всегда присутствующий в таких данных, не давал LZW возможности распознать повторяющиеся шаблоны.

Форматы TIFF и BMP позволяли хранить 24-битовые данные, но их версии, существовавшие до JPEG, позволяли применять только схемы кодирования, которые плохо сжимали этот тип данных изображения (LZW и RLE соответственно).

JPEG является методом сжатия, позволяющим сжимать данные многоградационных изображений с пиксельной глубиной от 6 до 24 битов с разумной скоростью и эффективностью. И хотя JPEG не был определен в качестве стандартного формата файлов изображений, на его основе были созданы новые или модифицированы существовавшие файловые форматы.