277457745
|
|||||||||||||||||||||||||||||||||||||||
|
|
Оглавление От переводчика Введение Замечания по редакции Аннотация 1. Структура Заголовок файла (Image File Header - IFD) Директории файла (Image File Directory) 2. Определения 3. Поля Базовые поля Информационные поля Факсимильные поля Поля запоминания и восстановления документов Поля, не рекомендуемые для дальнейшего использования 4. Частные поля 5. Обзор форматов файлов для изображений 6. Дополнительная информация Приложение A: Разумность теговой структуры Приложение B: Сжатие данных по схеме 2 Приложение C: Схема сжатия данных 32773 (PackBits) Приложение D: Приложение E: Упорядоченный список тегов TIFF Приложение F: Схема сжатия данных 5 (LZW-сжатие) Аннотация Литература Требования Алгоритм Декодирование LZW Что делать, если SamplesPerPixel больше 1 Реализация Быстродействие Будущие расширения LZW Благодарности Приложение G: Классы TIFF Разумность Обзор Ядро требований Класс TIFF B - двухуровневые изображения Класс TIFF G - серые изображения Класс TIFF P - цветные палитровые изображения Класс TIFF R - полностью цветные RGB-изображения Подтверждения и интерфейс для пользователя Приложение H: Цветометрическая информация изображений I. Введение II. Стандарты цветометрии III. Мотивация IV. Цветометрическое воспроизведение V. Белая точка VI. Главные цвета VII. ColorResponseCurves VIII. Новые теги и изменения IX. Умолчания X. Ограничения и следствия XI. Литература Приложение I: Схема предварительного горизонтального дифференцирования Алгоритм Результаты и следствия Приложение J: Цветные палитровые изображения Предложение Возражения Преимущества Новые теги От переводчика Перед вами перевод спецификации 5.0 стандарта TIFF (Tag Image File
Format). Этот документ содержит всю необходимую информацию для написания
собственных программ поддержки в файлов в этом формате. Думаю, он будет полезен
всем, кто интересуется машинной графикой и в частности таким ее аспектом, как
работа с растровыми изображениями. TIFF является сравнительно "старым" форматом и де-факто давно
уже стал стандартом для представления изображений, получаемых со сканеров.
Однако он не получил достаточно широкого распространения, как стандарт обмена
графической информацией на IBM PC. На мог взгляд, это объясняется двумя
причинами. Во-первых, в нем долгое время отсутствовала эффективная схема для
сжатия изображений, которые не являются черно-белыми. Во-вторых, не было поддержки
цветных изображений на основе палитры (по сути дела таковыми являются все
изображения, которые можно высвечивать на современных графических адаптерах и
мониторах IBM PC). Введение в
спецификации 5.0 схемы сжатия LZW и тегов для
описания палитровых
изображений во многом устраняет эти
причины. По всей видимости можно
ожидать, что область
его использования будет постепенно расширяться. Когда я переводил этот документ, у меня уже было общее представление об
организации данного формата и не возникало сложностей с пониманием изложенного
в нем материала. Однако, когда я стал его перечитывать с целью устранения
опечаток, у меня сложилось впечатление, что он написан несколько тяжеловесно
для человека, который знакомится с эти форматом впервые. Поэтому я рискну
кратко изложить основные концепции организации TIFF-файла. Мне кажется, это
должно помочь тем, кто совсем не знаком с эти форматом. 1. В одном TIFF-файле может
находиться несколько изображений. 2. Каждое изображение описывается с помощью набора
полей или тегов, которые определяют это изображение. В рамках исходного
документа, как и в переводе, термины тег (tag) и поле (field) абсолютно
идентичны (хотя я отдаю себе отчет, что в общем случае это не так). 3. Каждый тег имеет строго определенное назначение и
описывает конкретные характеристики изображения (размеры, характеристики цветов
и т.д.). Иногда наполнение тега можно рассматривать как отдельное число, но в
общем случае - это массив чисел одинакового типа. 4. Каждому тегу соответствует определенный номер,
который позволяет определить при чтении файла какую информацию описывает данный
тег. При описании тегов в спецификации приводятся десятичные значения этого
номера, а в скобках - шестнадцатиричные. 5. В спецификации для каждого тега введены названия,
которые состоят из одного или нескольких английских слов, например, ImageWidth,
ColorMap и т.д. Эти названия чисто условны и никогда не появляются в самом
TIFF-файле. При переводе документа все они сохранены в своем первоначальном
виде (переводить их на русский - это то же самое, что переводить for, while,
return и т.д. в программах на C или Паскале). Текст типа "если
ImageWidth=320" расшифровывается как "если значение тега, имеющего
название ImageWidth, равно 320" (естественно, используется только для
тегов, значения которых состоят из одного числа). 6. Все теги, относящиеся к одному изображению
объединяются в рамках одного элемента внутри файла, который называется
директорией (Image File Directory - IFD). Соблюдается принцип "одно
изображение - одна директория". 7. Единственный
элемент, место которого определено в файле
жестко -
это заголовок из 8 байтов, с которого начинается TIFF-файл. Все остальные
элементы (директории, теги и значения тегов) могут располагаться практически в
любом месте файла. Взаимосвязь между ними осуществляется с помощью аппарата
указателей. Для начала этого
должно быть достаточно. Всю остальное вы узнаете, прочитав основной документ. Несколько слов следует сказать о терминологии. Очень часто при переводе
на русский язык англоязычных текстов по вычислительной технике приходится
сталкиваться с тем, что многие термины не имеют достаточно лаконичных
эквивалентов. В результате наш богатый и могучий обогащается еще больше словами
типа свопинг, дамп, скроллинг и т.д. Настоящий документ не является в этом
смысле исключением. Во избежание недоразумений ниже приводится перечень
терминов, перевод которых в документе может вызвать нарекания. Bilevel image. По непонятным мне причинам авторы документа старательно
избегают термина black and white image (черно-белое изображение) и обозначают
такие изображения как bilevel image (двухуровневое изображение). Хотя второй
вариант лаконичнее, он не совсем точен. На самом деле, все изображения, которые
названы в документе bilevel, являются именно черно-белыми, а не произвольными
двухуровневыми изображениями. Каюсь, в данном случае я пошел на поводу у
авторов документа и переводил этот термин дословно, т.е. как двухуровневые
изображения. Grayscale image. Английское слово grayscale образовано из двух корневых
слов gray (серый) и scale (масштаб). Имеются в виду изображения, которые
передаются тонами серого цвета разной интенсивности (классический пример -
черно-белые фотографии). При переводе использовались термины "изображение в
серых тонах" или просто "серое изображение". Palette color image. При переводе использовался термин "цветное
палитровое изображение". Имеются в виду изображения, которые обладают тем
свойством, что число цветов в них строго ограничено таблицей фиксированного размера
(палитрой). Каждый элемент этой таблицы задает каким либо образом цвет пиксела
(как правило, в цветовой системе RGB), который может появляться на экране.
Значения пикселов являются одно компонентными и используются как индексы для
входа в палитру. Все изображения, которые могут высвечиваться на стандартных
мониторах IBM PC обладают указанным свойством. Full color RGB image. Этот термин переводился как "полностью
цветное RGB-изображение" или "RGB-изображение". Здесь имеются в
виду изображения каждый пиксел которых может задаваться с помощью трех
независимых компонент (samples) интенсивностей основных цветов в системе RGB.
Перевод термина sample как "компонента" лексически не очень точен, но
на мой взгляд наиболее точно отражает существо дела в данном конкретном случае. Bit depth. Использовался дословный перевод "битовая глубина".
Здесь имеется ввиду число бит отводимое для определения интенсивностей серого
тона или компонент интенсивности в системе RGB. Говорят, что компонента или
само изображение тем "глубже", чем больше это число. Иногда
используются обороты типа "8-битное серое изображение" (смысл в свете
сказанного очевиден). Differing, differ matrix. В обработке изображений существует ряд
методов, которые предназначены для передачи изображений с использованием
меньшего количества цветов или оттенков, чем имеется в исходном изображении
(например, когда требуется напечатать образ черно-белой фотографии на матричном
принтере). Общее название этих методов в англоязычной литературе - differing.
Многие из этих методов основаны на использовании специальных матриц, имеющих
фиксированные размеры (differ matrix). Более подробную информацию об этих
методах можно, например, почерпнуть из книги Д.Роджерса "Алгоритмические
основы машинной графики" (M., Мир, 1989 г., стр. 131-138). Я долго пытался
найти для этих терминов приемлемые русские эквиваленты, но в конце концов
остановился на банальном "дифферинг" и "матрица дифферинга"
(Да простят меня наши лингвисты...). Могу честно признаться, что наибольшие трудности возникли у меня при
переводе Приложения H, посвященного проблемам цветопередачи. Во-первых, это
достаточно специфическая область. Во-вторых, сам стиль изложения в оригинале,
на мой взгляд оставляет желать лучшего (хотя это мое личное мнение). Второе
обстоятельство я как мог пытался сгладить при переводе, но не думаю, что это
мне удалось. Относительно первого должен заметить, что материал этого
Приложения может оказаться совершенно несъедобным, если не иметь хотя бы общего
представления о стандартах определения цвета. Могу порекомендовать уже
упоминавшуюся книгу Д.Роджерса (стр. 458-487). Отдельного обсуждения заслуживает Приложение F (алгоритм LZW-сжатия). В
принципе, изложенного в нем материала достаточно для написания собственных
программ, реализующих данный алгоритм. Однако, на мой взгляд авторы документа
опустили ряд подробностей, которые не очевидны на первый взгляд, но крайне
важны именно с точки зрения программной реализации. Если вы собираетесь писать
такие программы, то я настоятельно рекомендую вам сначала
"прокрутить" вручную случай сжатия и распаковки потока, состояжего из
N одинаковых байтов. Уверяю, что несмотря на тривиальность этого случая, при
распаковке "вылезет" весьма нетривиальная подробность, о которой
авторы документа просто умалчивают. В заключение должен
сказать, что материал данного документа, несмотря на явную его полезность,
местами оставляет достаточное странное впечатление. Я не обнаружил в нем явных
смысловых ошибок, но мне кажется, что иногда он носит откровенно рекламный
характер, что наносит ущерб точности изложения, а некоторые размышления его
авторов по меньшей мере спорны. Но я счел за благо воздержаться от комментариев
по ходу документа: он и так достаточно велик, а опытные программисты и без меня
поймут что к чему. Кроме того, не дай Бог Microsoft обидится... А.Самотохин Институт прикладной
математики AH CCCР Москва, 1991 г. Введение Этот меморандум был подготовлен фирмами Aldus и Microsoft совместно с
главными распространителями сканеров и другими заинтересованными сторонами.
Этот документ не является частью обязательства Microsoft или Aldus обеспечивать
поддержку этого формата во всех приложениях. Если вам понадобится ответ на
специальные вопросы, затронутые в этом документе, или потребуются
дополнительные теги или модификации отдельных полей, обращайтесь по любому из
адресов: Developers Desk Windows
Marketing Group Aldus Corporation Microsoft
Corporation 411 First Ave. Suite (206) 622-5500 (206)
882-8080 Замечания
по редакции Эта редакция заменяет редакцию TIFF Revision 4. Разделы, набранные
курсивом являются новыми или значительно измененными по сравнению с указанной
версией. Новыми также являются приложения F, G и H, хотя они и не набраны курсивом. Главными улучшениями в TIFF
5.0 являются: 1. Сжатие серых и цветных изображений для лучшего использования
дискового пространства. См. Приложение F. 2. Классы TIFF ограничивают набор объектов TIFF, что упрощает работу с
инструментами TIFF. Возможно вы захотите просмотреть Приложение G перед чтением
оставшейся части документа. Фактически вы можете использовать Приложение G как
основной путеводитель, возвращаясь к основному телу документа по мере
необходимости для получения подробных справок о структурах TIFF и описаний
полей. 3. Поддержка цветных палитровых изображений. См. TIFF Class P в
Приложении G, и описание нового поля ColorMap. 4. Два новых тега, которые могут использоваться для более полного определения
характеристик цветных изображений в пространстве RGB, и тем самым потенциально
улучшить качество воспроизведения цветных изображений. См. Приложение H. Организация документа также значительно изменилась. В частности, теги
перечислены в алфавитном порядке внутри некоторых категорий в теле главного
документа. Как всегда,
любые попытки расширить функциональные возможности выполнены таким
образом, чтобы минимизировать проблемы совместимости со
старым программным обеспечением
для TIFF. В частности, многие
TIFF-файлы версии 5.0
будут читаемы старыми прикладными программами, написанными для версий TIFF 4.0 или даже более
ранних. Единственным исключением являются файлы, которые используют новую схему
сжатия LZW. Конечно, старые прикладные программы будут "отказываться"
от такого случая, но будут делать это "изящно", если они выполняют
правила, принятые для TIFF. Мы благодарны всем,
кто прочитал черновые варианты этого документа, за их замечания. Особенно
полезны были замечания Herb Weiner из Kitchen Wisdom Publishing Company, Brad
Pillow из TrueVision, и инженеров из Hewlett Packard and Quark. Chris Sears из
Magenta Graphics снабдил нас информацией, которую мы включили в Приложение H. Аннотация
Этот документ описывает TIFF - формат файла, основанный на тегах,
который был разработан для содействия обмену изображениями в цифровом виде. При определении полей главным образом имелись в виду настольные
издательства и связанные с ними приложения. Однако, не исключено, что TIFF
может оказаться полезным и для других задач обработки изображений. Главный сценарий, для которого создавался TIFF, подразумевал, что
прикладная программа для сканирования или создания изображения создает
TIFF-файл, который затем читается и встраивается в документ или публикацию с
помощью программ типа настольных издательств. TIFF не имеет языка для принтера или языка описания страницы и не
претендует на общий стандарт описания документа. Главная цель его разработки
состояла в том, чтобы обеспечить богатую среду, внутри которой может
совершаться обмен данными по изображениям между прикладными программами. Это
богатство требовалось для того, чтобы использовать различные возможности
сканеров и сходных с ними устройств. Поэтому TIFF разрабатывался как
объединение существующих форматов файлов для настольных сканеров (а также
графических редакторов и всего остального, что порождает изображения, состоящие
из пикселов) и он может непрерывно совершенствоваться по мере появления новых
потребностей. Высокий приоритет был отдан структурированию данных таким
образом, чтобы снизить расходы при последующих дополнениях. TIFF разрабатывался
как расширяемый и гибкий формат обмена. Хотя от TIFF'а требуется, чтобы он был "богатым" форматом, он
может быть легко адаптирован к простым сканерам и прикладным программам,
поскольку разработчики программ могут использовать только те возможности,
которые им нужны. TIFF подразумевает независимость от конкретных операционных и файловых
систем, компиляторов и процессоров. Единственное существенное допущение состоит
в том, что пространство памяти поддерживается как файл, определяемый как
последовательность 8-битовых байтов, причем байты нумеруются от 0 до N.
Максимальная возможная длина TIFF-файла составляет 2**32 (2 в степени 32)
байтов. Поскольку в TIFF широко используются указатели (байтовые смещения),
TIFF-файл может легко считываться с устройства прямого доступа типа жесткого
диска или гибкой дискеты. Однако допускается чтение и запись TIFF-файлов на
магнитные ленты. Рекомендуемым расширением для TIFF-файлов в MS-DOS, UNIX, и OS/2
является .TIF. Рекомендуемый тип файла в компьютерах Macintosh - TIFF. Принимаются
предложения для соглашений в других вычислительных системах. 1. Структура В TIFF конкретные поля идентифицируются с помощью уникального тега. Это
допускает присутствие или отсутствие конкретных полей в файле в зависимости от
требований конкретной задачи. Пояснения по использованию теговых структур
приведены в Приложении A. TIFF-файл начинается с 8-байтового заголовка файла (Image File Header),
который указывает на одну или несколько директорий файла (Image File
Directories). Директории содержат информацию о изображениях и указатели на
данные самого изображения. Теперь мы опишем эти
структуры более подробно. Заголовок файла (Image File Header - IFD) TIFF-файл начинается с 8-байтового заголовка, содержащего следующую
информацию: Байты 0-1: Первое слово файла определяет порядок байтов, используемый в
файле. Допустимыми его значениями являются: II (hex 4949) MM (hex 4D4D) В формате II в 16-битных и 32-битных целых числах
порядок байтов всегда идет от младших (менее значимых) к старшим (более
значащим). В формате MM для тех же чисел порядок байтов идет от старших к
младшим. В обоих форматах символьные строки запоминаются как последовательность
байтов в их естественном порядке. Все программы, читающие TIFF-файлы, должны
поддерживать оба порядка байтов (см. Приложение G). Байты 2-3: Второе слово TIFF-файла - это номер версии. Это число, равное
42 (2A hex), но оно не равно номеру редакции текущей спецификации TIFF (в
данном случае номер редакции текущей спецификации - это 5.0). Фактически номер
версии TIFF (42) никогда не меняется и, возможно, никогда не изменится. Но если
это случится, то будет означать, что TIFF изменился настолько радикально, что
программа чтения TIFF должна немедленно прекратить работу. Число 42 было
выбрано из-за его глубокого философского смысла. Оно может и должно
использоваться для дополнительной проверки того, что это действительно
TIFF-файл. TIFF-файлы не имеют явного номера редакции (т.е. 5.0
для текущей редакция). Это решение при разработке было принято сознательно. Во
многих форматах поля могут принимать различные значения в зависимости от номера
версии. Проблема состоит в том, что как только формат начинает
"стареть", возрастают трудности по документированию того, какие поля
что означают в данной версии, и старые программы
обычно не способны
к работе с
файлами, содержащими новый
номер версии. Мы хотели, чтобы поля
TIFF имели постоянное и
хорошо определенное значение
так, чтобы "старые" программы как
правило могли читать
"новые" TIFF-файлы. Последнее снижает стоимость
разработки программного обеспечения и делает его более надежным. Байты 4-7: Это слово типа long, содержащее смещение в байтах первой
директории файла (Image File Directory). Директория может располагаться в любом
месте файла вслед за заголовком, но ее начало должно быть выровнено на границу
слова. В частности, директория может следовать за данными изображения, которое
она описывает. Программы чтения должны просто перемещаться по этому указателю,
вне зависимости от того, куда он указывает. (Термин байтовое смещение (byte offset) всегда используется в этом
документе, чтобы ссылаться на положение относительно начала файла. Первый байт
файла имеет смещение, равное 0). Директории
файла (Image File Directory) Директории файла (Image File Directory - IFD) состоят из 2-байтового
счетчика числа элементов (т.е. числа тегов в данной директории), вслед за
которым расположена последовательность 12-байтовых тегов и далее 4-байтовое
смещение для следующей директории (или 0, если таковая отсутствует). Не
забывайте записывать 4 нулевых байта в конце последней директории! Каждый 12-байтный элемент
IFD имеет следующий формат: Байты 0-1 содержат Тег
(Tag) поля. Байты 2-3 содержат Тип
(Type) поля. Байты 4-7 содержат Длину (Length) поля (здесь, возможно, более удачным
термином является Count - Счетчик). Байты 8-11 содержат Смещение для значения (Value Offset), т.е. байтовое
смещение того места в файле, где расположено само значение. Предполагается, что
это смещение должно быть выровнено на границу слова, т.е. Value Offset должно
быть четным числом. Это смещение может указывать на любое место в файле. Элементы в IFD должны быть отсортированы в порядке возрастания поля
Tag. Заметим, что этот порядок отличен от того, в котором поля описаны в данном
документе. Упорядоченный по номерам список тегов приведен в Приложении E.
Значения, на которые указывают элементы директории, могут следовать в файле в
любом порядке. Для экономии времени и пространства поле Value Offset интерпретируется
как само значение, а не как указатель на значение, если значение умещается в 4
байтах. Если значение меньше 4 байтов, то оно выравнивается по левому краю
4-байтового поля, т.е. запоминается в байтах с младшими номерами. Для того,
чтобы определить умещается или нет значение в 4 байтах, следует проверить
значения полей Type и Length. Поле Length описывает данные в терминах типов данных, а не общим числом
байтов в поле. Например, одиночное 16-битное слово (SHORT) имеет Length равное
1, а не 2. Ниже приведены типы данных и их длины: 1
= BYTE 8-битое
беззнаковое целое. 2
= ASCII 8-битные байты, которые содержат ASCII-коды; последний байт должен
быть нулевым. 3
= SHORT 16-битное
(2-байтовое) беззнаковое целое. 4
= LONG 32-битное
(4-байтовое) беззнаковое целое. 5 = RATIONAL Два числа типа LONG: первое представляет
числитель дроби, второе - ее знаменатель. Значение поля Length для данных типа ASCII включает нулевой байт. Если
необходимо выравнивание (например, на границу слова) то поле Length не включает
байты, добавляемые при выравнивании. Отметим, что здесь не нужен байт-счетчик
как в паскалевских строках. Наличие поля Length делает его ненужным. Строго
говоря, нулевой байт в конце строк не является необходимым, но его присутствие
значительно упрощает жизнь для программистов, пишущих на C. Программы чтения
должны проверять тип данных, чтобы убедиться, что он таков,
как они ожидают.
В настоящее время TIFF допускает использование
нескольких типов данных для одного и
того же поля. Например, поля
ImageWidth (ширина изображения)
и ImageLength (длина изображения) описаны, как имеющие тип SHORT. На некоторых
устройствах, существующих уже сегодня, возможны очень большие изображения,
имеющие более 64K строк или колонок. Вместо добавления параллельного LONG-тега
для этих полей, проще допустить возможность использования типов и SHORT и LONG
для поля ImageWidth и подобного ему. В Приложении G приведены рекомендации по
этому поводу. Заметим, что файле может существовать несколько IFD. Говорят, что
каждый IFD определяет суб-файл (subfile). Одна из потенциальных возможностей
использования последовательных суб-файлов состоит в описании суб-изображений,
каждое из которых связано с главным, например, является его версией с
уменьшенным разрешением. Если вы еще не сделали
этого, вы можете обратиться к Приложению G, чтобы изучить примеры
TIFF-изображений. 2. Определения Отметим, что структура TIFF, описанная в предыдущем разделе никак не
связана с изображениями. Единственная связь описанной структуры с
изображениями, заключается в том, что поля описывают различные характеристики и
свойства изображений. Перед тем, как
определить поля, мы определим некоторые базовые понятия. По определению
изображение является прямоугольным массивом пикселов, каждый из которых состоит
из одного или нескольких компонент (samples). В монохромных данных каждый
пиксел состоит из одной компоненты, и понятия компонента и пиксел являются
равнозначными. В цветных RGB-данных одному пикселу соответствуют три
компоненты. 3.
Поля Данный раздел описывает поля, определенные в настоящей редакции TIFF. В
будущем могут быть добавлены новые поля, однако, по мере возможности это будет
делаться таким образом, чтобы не разрушить старые программы при встрече с
новыми TIFF-файлами. Документация для каждого поля содержит имя поля (достаточно
произвольное, но согласованное), значение для поля Tag value, тип поля (Type),
ожидаемое число значений (N), комментарий, описывающий поле и значения по
умолчанию, если таковые существуют. Если поле отсутвует, программы чтения TIFF
должны принимать эти значения по умолчанию. Текст "Нет умолчаний" не означает, что программа записи TIFF
не должна обращать внимание на это поле. Он просто означает, что для него
ничего не принимается по умолчанию. Если программа записи имеет причины
предполагать, что программе чтения понадобится значение этого поля, она должна
записать в него соответствующее значение. Программы чтения TIFF могут делать
что угодно, если они обнаружат отсутствие нужного им поля, для которого не
определены значения по умолчанию. Например, если программа записи не запишет
поле PhotometricInterpretation (фотометрическая интерпретация), то некоторые
программы чтения будут интерпретировать изображение правильно, а другие будут
высвечивать его инвертированным. Это нельзя признать удовлетворительным, и
поэтому программы записи должны быть достаточно аккуратны, чтобы не допускать
подобных ситуаций. Поля сгруппированы по
нескольким категориям: базовые, информационные, факсимильные, запоминания и восстановления документа и
не рекомендуемые в дальнейшем. В будущих версиях описания некоторые из этих
категорий могут быть помещены в отдельные справочные документы. В этом документе
описано много полей, но большинство не являются обязательными. В Приложении G
содержится список полей, являющихся обязательными, а также примеры комбинации
полей в допустимых и полезных TIFF-файлах. Базовые поля Базовыми полями являются поля, которые являются фундаментальными для
пиксельной архитектуры и визуальных характеристик изображения. BitsPerSample Tag = 258 (102h) Type = SHORT Length
= SamplesPerPixel Значения этого тега определяют число битов в каждой компоненте пиксела.
Отметим, что этот тег допускает различное число бит для каждой компоненты, соответствующей пикселу. Например, цветные RGB-данные
могут использовать различное число бит для компонент каждой из трех цветовых
плоскостей. Большинство RGB-файлов имеют одинаковое число BitsPerSample для
каждой компоненты. Даже в этом случае следует включать все три элемента. Запись
только 8 вместо 8,8,8 создает ошибочную ситуацию для других полей. По умолчанию = 1. См. также SamplesPerPixel. ColorMap Tag = 320 (140h) Type = SHORT Length
= 3 * (2**BitsPerSample) Этот тег определяет цветовую RGB таблицу для изображений с цветовой
палитрой. Значения пикселов цветовой палитры используются как индексы в трех
таблицах цветопередачи (для каждого из трех основных цветов). Например, если
пиксел цветовой палитры имеет значение, равное 0, то он должен высвечиваться в
соответствии в 0 элементом красной (Red), зеленой (Green) и синей (Blue) таблиц
цветопередачи. Таблицы цветопередачи запоминаются последовательно. Сначала идут
элементы красного, затем зеленого и затем синего цветов. Длина каждой таблицы
равна 2**BitsPerSample (Для таких изображений SamplePerPixel всегда равно 1).
Следовательно, элемент ColorMap для изображения с 8-битными палитровыми цветами
должен составлять 3*256 элементов. Ширина каждого элемента равна 16 бит,
поскольку используется тип SHORT. 0 отвечает минимуму интенсивности и 65535 - максимуму. Черному цвету соответствует 0,0,0, и белому - 65535,
65535, 65535. Цель цветовой таблицы состоит в том, чтобы создать таблицу поиска
RGB-триплексов для пикселов, имеющих значения от 0 до 2**BitsPerSample-1. Поле ColorResponseCurves может использоваться совместно с полем
ColorMap для более полного определения RGB-триплексов в ColorMap. Однако, в
большинстве случаев достаточно значения ColorResponseCurves по умолчанию. См. также
PhotometricInterpretation. Нет умолчаний. Поле ColorMap должно включаться для всех цветных
палитровых изображений. ------------------------------------------------------------------ ColorResponseCurves Tag = 301 (12Dh) Type = SHORT Length
= 3 * (2**BitsPerSample) Этот тег определяет три таблицы цветопередачи, одну для красной, одну
для зеленой и одну для синей компонент цвета. Таблицы цветопередачи
запоминаются последовательно. Сначала идут элементы красного, затем зеленого и затем синего цветов. Длина каждой таблицы равна
2**BitsPerSample, причем используется значение BitsPerSample, соответствующее
каждой компоненте. Ширина каждого элемента равна 16 бит, поскольку используется
тип SHORT. 0 отвечает минимуму интенсивности и 65535 - максимуму. Черному цвету
соответствует 0,0,0, и белому - 65535, 65535, 65535. Следовательно, элемент
ColorResponseCurve для RGB-данных, где каждая компонента содержит 8 битов,
занимает 3*256 элементов, причем каждый элемент имеет тип SHORT. Цель этих таблиц цветопередачи состоит в определении содержимого
цветных RGB-изображений. Для более подробной
информации см. Приложение H, раздел VII. Умолчание: таблицы базируются на рекомендованном NTSC значении
гамма=2.2. (См. Приложение H) ------------------------------------------------------------------ Compression Tag = 259
(103h) Type = SHORT Length = 1 Значение тега определяет схему сжатия растровых данных. В настоящее
время для этого тега определены значения 1, 2, 5 и 32773. Compression=1 Нет
сжатия, но данные пакуются в байты настолько плотно, насколько это возможно,
так, чтобы не было неиспользуемых битов (за исключением конца строк). Байты
запоминаются как массив типа BYTE, для BitsPerSample <= 8, SHORT, если
BitsPerSample > 8 и <= 16, и LONG, если BitsPerSample > 16 и <= 32.
Порядок байтов в данных, содержащих более 8 бит должен соответствовать тому,
который был указан в заголовке TIFF-файла (байты 0 и 1). В формате II младшие
байты предшествуют старшим, в формате MM наоборот. Если число бит в компоненте не является степенью 2, и вы готовы пожертвовать
некоторым пространством для достижения более высокого быстродействия, вы можете
использовать ближайшее значение, являющееся степенью 2. Например, если ваши
данные описываются 6 битами, вы, возможно, захотите указать, что они содержат 8
бит. Строки должны
начинаться с выравниванием на байт. Следовательно, число байт на строку должно
равняться (ImageWidth*SamplesPerPixel*BitsPerSample + 7)/8, имея в виду целую
арифметику, для PlanarConfiguration=1. Для PlanarConfiguration=2 это число
равно (ImageWidth * BitsPerSample + 7)/8. В некоторых графических системах требуется, чтобы строки были выровнены
на границу слова или на границу двойного слова. Перед передачей строк несжатого
TIFF'а в графические программы в такой среде, их следует скопировать в буферы,
удовлетворяющие требованиям выравнивания. Compression=2 Схема сжатия CCITT Group 3. Одно
размерное кодирование длинных серий по модифицированной схеме Хаффмана. См.
Приложение B: Сжатие данных - Схема 2. Значение BitsPerSample должно быть равно
1, поскольку этот тип сжатия определен только для двухуровневых изображений. Когда вы декодируете данные, которые были сжаты с Compression=2, вы
должны транслировать белые серии в последовательность нулей, и черные - в
последовательность единиц. Следовательно, стандартным значением
PhotometricInterpretation для этого сжатия является 0 (WhiteIsZero). Если
программа чтения встретит значение PhotometricInterpretation, равное 1
(BlackIsZero) для такого изображения, оно должно быть высвечено или напечатано
с инвертированием черного и белого цветов. Compression=5 LZW-сжатие для серых и цветных
изображений. См. Приложение F. Compression=32773 PackBits
компрессия, простая схема сжатия с помощью длинных серий, ориентированная на
1-битовые изображения. См. Приложение С. Сжатие данных оказывает влияние только на растровые данные, на которые
имеется указатель в StripOffsets. Вся другая TIFF-информация остается
неизменной. По умолчанию = 1. GrayResponseCurve Tag = 291 (123h) Type = SHORT Length = 2**BitsPerSample Цель этого тега, а также тега GrayUnits состоит в том, чтобы обеспечить
более точную фотометрическую интерпретацию серых изображений в терминах
оптической плотности. Тег GrayScaleResponseUnits указывает точность информации, содержащейся
в теге GrayResponseCurve. Поскольку оптическая плотность определяется в
терминах фракционных чисел (fractional numbers), этот тег необходим для
правильной интерпретации запомненной целой информации. Например, если тег GrayScaleResponseUnits равен 4 (десятитысячные доли), и значение
GrayScaleResponseCurve для серого уровня 4 равно 3455, то получаемое
действительное значение равно 0.3455. Оптические измерители плотности обычно
выдают значения в диапазоне от 0.0 до 2.0. Если известна кривая передачи оптической плотности для данных в
TIFF-файле, и известна аналогичная кривая для выходного устройства, то может
быть выполнено осмысленное обращение между входными данными и выходным
устройством. Например, вывод может точно соответствовать исходным данным. Кроме
того, если исходное изображение недостаточно контрастно (это нужно увидеть из
его таблицы отображения плотности), то может быть быть выполнено априорное
улучшение контрастности. Цель данного тега состоит в создании таблицы поиска, которая содержит
2**BitsPerSample-1 значений оптической плотности. Нулевой элемент массива
GrayResponseCurve используется для определения плотности для всех пикселов,
имеющих значение 0, первый элемент массива GrayResponseCurve - для определения
пикселов со значением 1, и т.д. до 2**BitsPerSample-1. Если ваши данные на самом деле являются, скажем, 7-битными, но вы
добавили один бит к каждому пикселу, чтобы превратить их в 8-битные, все будет
по-прежнему работать. Если ваши данные выровнены по старшим разрядам, то
половина элементов GrayResponseCurve (возможно, только нечетные) никогда не
будут использоваться, но вам и не надо о них заботиться. Если данные выровнены
по младшим разрядам, значения пикселов будут находиться в диапазоне от 0 до
127, и вам нужно соответствующим образом составить таблицу GrayResponseCurve.
Что эта таблица содержит в диапазоне от 128 до 255 не имеет значения. Отметим,
что выравнивание по младшим разрядам, возможно, не лучшая идея, поскольку не
все приложения работают так, как GrayResponseCurve. Заметим также, что
LZW-сжатие дает одинаковую степень сжатия вне зависимости от того проводилось
выравнивание по младшим или по старшим разрядам. Наличие GrayResponseCurve допустимо даже для двухуровневых (1-битных)
изображений. В этом случае GrayResponseCurve будет иметь два значения. Следует
однако заметить, что программы чтения TIFF-файлов класса B не обращают внимания
на наличие GrayResponseCurves в таких файлах. См. Приложение G. Если в IFD существуют одновременно поля GrayResponseCurve и
PhotometricInterpretation, то значение GrayResponseCurve замещает значение,
определенное в PhotometricInterpretation. Однако, наличие и того и другого поля
является неплохой идеей, поскольку некоторые прикладные программы не обращают
внимания на GrayResponseCurve. Авторы программ для записи TIFF-файлов могут купить Kodak Reflection
Density Guide (номер каталога 146 5947), который стоит $10 или переписать
данные из него. Это поможет формировать правильные кривые для передачи оптической плотности их сканера или
другого устройства. Если это покажется вам слишком большой работой, мы
рекомендуем кривую, которая линейна в пространстве интенсивность-отражательная
способность. Для вычисления отражательной способности от плотности: R =
1/pow(10,D). Для вычисления плотности в зависимости от отражательной способности:
D = log10(1/R). Типичная GrayResponseCurve для 4-битных изображений будет
выглядеть, следовательно, как: 2000, 1177, 875, 699, 574, 477, 398, 331, 273,
222, 176, 135, 97, 62, 30, 0, при GrayResponseUnit=3. Такая кривая согласуется с PhotometricInterpretation=1. См. также GrayResponseUnit, PhotometricInterpretation,
ColorMap. GrayResponseUnit Tag = 290 (122h) Type = SHORT Length
= 1 Значение тега позволяет определить в каких единицах оптическая
плотность в теге GrayResponseCurve. Возможные значения GrayResponse Unit: 1 = Число представляет десятые доли единицы. 2 = Число представляет сотые доли единицы. 3 = Число представляет тысячные доли единицы. 4 = Число представляет десятитысячные доли единицы. 5 = Число представляет стотысячные доли единицы. Влияет на GrayResponseCurve. См. также GrayResponseCurve. По историческим причинам значение по умолчанию равно 2. Однако, для
большей точности мы рекомендуем использовать 3. ------------------------------------------------------------------
ImageLength Tag = 257 (101h) Type = SHORT или LONG Length = 1 Длина (высота) изображения в пикселах (Y: вертикаль). Число строк
(иногда их называют как строки развертки) в изображении. См. также ImageWidth. Нет умолчаний. ImageWidth Tag = 256 (100h) Type = SHORT or LONG Length = 1 Ширина изображения в пикселах (X: горизонталь). Число колонок в
изображении). См. также ImageLength. Нет умолчаний. NewSubfileType Tag = 254
(FEh) Type = LONG Length = 1 Замещает старое поле
SubfileType, снимая ограничения, определенные в этом поле. Общее описание данных, содержащихся в этом суб-файле. Это поле
образовано 32 битами-флагами. Предполагается, что неиспользуемые биты должны
быть равны 0. Бит 0 является младшим. В настоящее время
определены следующие значения: Бит 0 равен 1, если изображение является версией с
пониженным разрешением другого изображения, имеющегося в этом же TIFF-файле. В
противном случае бит равен 0. Бит 1 равен 1, если изображение является отдельной
страницей многостраничного изображения (см. описание тега PageNumber). В
противном случае бит равен 0. Бит 2 равен 1, если изображение определяет маску
прозрачности для другого изображения в этом же TIFF-файле. Значение тега
PhotometricInterpretation должно равняться 4 (это значение соответствует маске
прозрачности). Эти значения определены как битовые флаги, поскольку они в достаточной
степени независимы один от другого. Например, полезно иметь 4 разных
изображения в одном TIFF-файле: изображение с полным разрешением, изображение с
пониженным разрешением, маску прозрачности для изображения с полным разрешением
и маску прозрачности для изображения с пониженным разрешением. Каждое из этих
четырех изображений будет иметь различное значение поля NewSubfileType. Значение по умолчанию
равно 0. PhotometricInterpretation Tag = 262
(106h) Type = SHORT Length = 1 Тег определяет
фотометрическую интерпретацию изображения и может принимать значения 0, 1, 2, 3
и 4. PhotometricInterpretation=0 Для
двухуровневых и серых изображений: 0 означает, что пиксел белый,
2**BitsPerSample-1 что он черный. Если существует тег GrayResponseCurve, он
переопределяет значение тега PhotometricInterpretation, хотя безопаснее
согласовать их значения, поскольку старые прикладные программы могут
по-прежнему игнорировать GrayResponseCurve. Это обычное значение для
Compression=2. PhotometricInterpretation=1 Для
двухуровневых и серых изображений: 0 означает, что пиксел черный,
2**BitsPerSample-1 что он белый. Если существует тег GrayResponseCurve, он
переопределяет значение тега PhotometricInterpretation, хотя безопаснее
согласовать их значения, поскольку старые прикладные программы могут
по-прежнему игнорировать GrayResponseCurve. Если это значение указано для
Compression=2, то при высвечивании или печати изображение должно быть
инвертировано. PhotometricInterpretation=2 RGB.
В RGB модели цвет описывается как комбинация трех основных цветов света
(красного, зеленого и синего) в соответствующих концентрациях. Для каждой из
трех компонент 0 представляет минимум интенсивности и 2**BitsPerSample-1 -
максимум. Так, в RGB значение (0,0,0) представляет черный, а значение
(255,255,255) белый цвет при 8-битных компонентах. При PlanarConfiguration=1
компоненты запоминаются в указанном порядке: сначала красный, затем зеленый,
затем синий. При PlanarConfiguration=2 StripOffsets для плоскости каждой
компоненты запоминаются в следующем порядке: сначала StripOffsets для красной
плоскости, затем StripOffsets для зеленой плоскости, затем StripOffsets для
синей плоскости. Поле ColorResponseCurves может использоваться для глобального уточнения
или изменения цветового баланса в RGB-изображениях без изменения значений самих
пикселов. PhotometricInterpretation=3 Цветное
изображение с палитрой. В этом режиме цвет описывается одной компонентой. Эта
компонента используется как индекс в таблицах цветопередачи тега ColorMap для
красной, зеленой и синей компонент, чтобы определить триаду RGB, которая задает
действительное значение цвета. Если используется тег PhotometricInterpretation,
то он должен применяться и к таблицам цветопередачи. Значение SamplesPerPixel должно равняться 1. PhotometricInterpretation=4 Маска
прозрачности. Это означает что последующее изображение используется для
определения нерегулярной области другого изображения, расположенного в этом же
TIFF-файле. Теги SamplesPerPixel и BitsPerSample должны иметь значение 1.
Рекомендуется использование схемы сжатия PackBits. Единичный бит определяет
внутреннюю часть области, а нулевой - внешнюю. Маска прозрачности должна иметь
те же значения тегов ImageLength и ImageWidth, что и основное изображение. Программы чтения могут использовать эту маску для определения того,
какую часть изображения следует высвечивать. Пикселы основного изображения,
соответствующие единичным битам маски выводятся на экран или принтер, а
пикселы, соответствующие нулевым битам - нет. Возможно обобщение понятия маски прозрачности для ввода частичной
прозрачности, однако не очевидно, что такая информации будет полезна для
настольных издательских систем. Нет умолчаний. Это означает, что если вас волнует, чтобы ваше
изображение не было высвечено или напечатано как инвертированное, вы должны
записать это поле. Не полагайтесь, что прикладная программа поступит с вашим
изображением по умолчанию так, как вам нужно! Для черно-белых и серых
изображений рекомендуется значение PhotometricInterpretation = 1 (за
исключением Compression=2), чем достигается популярный пользовательский
интерфейс для изменения яркости и контрастности изображений. PlanarConfiguration Tag = 284 (11Ch) Type = SHORT Length
= 1 Тег определяет
последовательность запоминания компонент пикселов в цветных изображениях и
может принимать значения 1 и 2. PlanarConfiguration=1 Значения
компонент пикселов запоминаются последовательно так, что они располагаются в
одной плоскости изображения. См. тег PhotometricInterpretation для определения
порядка компонент внутри пиксельных данных. Следовательно, для RGB-данных
данные запоминаются как RGBRGBRGB... и т.д. PlanarConfiguration=2 Компоненты
запоминаются в отдельных компонентных плоскостях. Значения тегов StripOffsets и
StripByteCounts образуются как двумерные массивы с SamplesPerPixel строк и
StripsPerImage колонок (сначала запоминаются все колонки для строки 0, затем
все колонки для строки 1, и т.д.). PhotometricInterpretation описывает тип
данных, который запомнен в каждой компонентной плоскости. Например, RGB-данные
запоминаются как красные компоненты в одной плоскости, зеленые компоненты в другой и синие - в
третьей. Если SamplesPerPixel равен 1, PlanarConfiguration не имеет значения и
не должен включаться. По умолчанию равно 1.
См. также BitsPerSample, SamplesPerPixel. Predictor Tag = 317 (13Dh) Type = SHORT Length
= 1 Используется при Compression=5 (LZW). См.
Приложение F. 1 = Нет схемы предварительных операций
перед кодированием. По умолчанию равно 1. ResolutionUnit Tag = 296 (128h) Type = SHORT Length = 1 Используется совместно с тегами XResolution и YResolution и определяет
единицы, в которых задаются значения этих тегов. ResolutionUnit=1 Нет
абсолютных единиц измерения. Используется для изображений, которые могут иметь
неквадратный пространственный коэффициент пропорциональности по горизонтали и
вертикали (aspect ratio), но для которых не важны абсолютные размеры. Недостаток
ResolutionUnit=1 состоит в том, что разные прикладные программы могут
переводить изображение в разные размеры. Даже если решение является достаточно
произвольным, возможно лучше использовать число точек на дюйм или на сантиметр,
и задавать для XResolution и YResolution такие значения, чтобы сохранялся
коэффициент пропорциональности (aspect ratio) и максимальный размер изображения
составлял, например, 4 дюйма. ResolutionUnit=2 Дюймы. ResolutionUnit=2 Сантиметры. По умолчанию равно 2. См. также XResolution, YResolution. RowsPerStrip Tag = 278 (116h) Type = SHORT или LONG Length
= 1 Число строк в полосе. Данные изображения организуются в полосы, которые
затем используются для быстрого доступа к нужной строке, если данные подвергались
сжатию (хотя использование этого поля допустимо даже если данные не сжимались). Теги RowsPerStrip и ImageLength сообщают вам число полос во всем
изображении. Уравнение StripsPerImage =
(ImageLength + RowsPerStrip - 1) / RowsPerStrip подразумевает использование целой
арифметики. Заметим, что для значения тега могут использоваться типы данных SHORT
или LONG. Значение SHORT используется для небольших TIFF-файлов. Однако,
следует заметить, что предыдущие описания TIFF-файлов требовали значения LONG и
некоторые прикладные программы могут не ожидать появления значения типа SHORT.
Для получения дополнительных рекомендаций см. Приложение G. По умолчанию равно 2**32-1, что на практике означает бесконечность,
т.е. все изображение располагается в одной полосе. Однако, мы не рекомендуем
использовать одну полосу. Выбирайте RowsPerStrip таким образом, чтобы каждая
полоса занимала приблизительно 8К байтов, даже если данные не сжимаются,
поскольку это упрощает буферизацию для программ чтения. Значение 8К является
достаточно произвольным, но представляется вполне работоспособным. См. также ImageLength, StripOffsets,
StripByteCounts. SamplesPerPixel Tag = 277 (115h) Type = SHORT Length
= 1 Число компонент в пикселе. SamplesPerPixel равно 1 для двухуровневых,
серых и палитровых изображений и равно 3 для RGB-изображений. По умолчанию=1. См. также BitsPerSample, PhotometricInterpretation. StripByteCounts Tag = 279 (117h) Type = SHORT or LONG Length = StripsPerImage для
PlanarConfiguration=1. =
SamplesPerPixel*StripsPerImage для
PlanarConfiguration=2 Для каждой полосы число байтов в полосе. Существование этого поля
значительно упрощает подсчет и буферизацию сжатых данных, если полоса имеет
осмысленный размер. Нет умолчаний. См. также
StripOffsets, RowsPerStrip. StripOffsets Tag = 273 (111h) Type = SHORT or LONG Length = StripsPerImage для
PlanarConfiguration=1. =
SamplesPerPixel*StripsPerImage для
PlanarConfiguration=2 Для каждой полосы ее байтовое смещение в файле. Смещение указывается по
отношению к началу TIFF-файла. Заметим, что наличие этого поля делает положение
текущей полосы независимым от местоположения других полос. Эта возможность
должна быть особенно полезна для редактирующих программ. Это дает единственный
способ нахождения данных изображения для программ чтения и, следовательно,
должно существовать. Заметим, что для значения тега могут использоваться типы данных SHORT
или LONG. Значение SHORT используется для небольших TIFF-файлов. Однако,
следует заметить, что предыдущие описания TIFF-файлов требовали значения LONG и
некоторые прикладные программы могут не ожидать появления значения типа SHORT.
Для получения дополнительных рекомендаций см. Приложение G. Нет умолчаний. См. также
StripByteCounts, RowsPerStrip. XResolution Tag = 282
(11Ah) Type = RATIONAL Length
= 1 Число пикселов на единицу, определенную полем ResolutionUnit в
направлении X, т.е. в направлении ImageWidth. Это, конечно не гарантирует, что
изображение действительно будет напечатано с размерами, определяемыми этим
параметром. Он предназначен для прикладных программ, которые могут использовать
его по своему усмотрению. Нет умолчаний. См. также YResolution,
ResolutionUnit. YResolution Tag = 283 (11Bh) Type = RATIONAL Length
= 1 Число пикселов на единицу, определенную полем ResolutionUnit в
направлении Y, т.е. в направленииImageLength. Нет умолчаний. См. также XResolution,
ResolutionUnit. Информационные
поля Информационными полями являются поля, которые могут содержать некоторую
полезную информацию для пользователя, например, откуда пришло изображение.
Большинство из них является ASCII-полями. Прикладные программы могут иметь
диалоговое окно типа More Info... для высвечивания такой информации. Artist Tag = 315
(13Bh) Type = ASCII Имя человека, создавшего изображение. Если вам нужно добавить к изображению замечание типа Copyright, то это
то место, где это следует сделать. На практике вы возможно захотите записать
содержимое этого поля сразу после 8-байтового TIFF-заголовка. Проверьте, что
ваш IFD и указатели полей выставлены надлежащим образом, и сделайте это. DateTime Tag = 306 (132h) Type = ASCII Length
= 20 Дата и время создания изображения. Используйте формат YYYY:MM:DD HH:MM:SS
с 24 часовым диапазоном значений для часов и одним пробелом между датой и
временем. Длина строки вместе с нулевым символом составляет 20 байтов. ------------------------------------------------------------------ HostComputer Tag = 316
(13Ch) Type = ASCII Компьютер, на котором создано изображение.
ENIAC или что-то еще. См. также Make, Model, Software. ImageDescription Tag = 270 (10Eh) Type = ASCII Например, пользователь может по своему усмотрению добавить к
изображению комментарий типа "1988 Компания на пикнике". Предполагается, что это то, что в газетах и журналах называется
"подписью под иллюстрацией". ------------------------------------------------------------------ Make Tag = 271
(10Fh) Type = ASCII Тип сканера, видеодигитайзера и т.п. См. также Model, Software. Model Tag = 272 (110h) Type = ASCII Название/номер модели сканера, видеодигитайзера и т.п. Этот тег предназначен исключительно для
информации пользователю. См. также Make, Software. Software Tag = 305 (131h) Type = ASCII Название и версия программы, создавшей
изображение. Этот тег предназначен исключительно для
информации пользователю. См. также Make, Model. Факсимильные
поля Факсимильные поля могут быть полезны для вас, если вы используете TIFF
для запоминания факсимильных сообщений в их исходном виде. Их не рекомендуется
использовать для обмена с прикладными программами типа настольных издательств. Compression (базовый тег) Tag = 259 (103h) Type = SHORT Length = 1 Значение тега определяет схему сжатия растровых данных. В настоящее
время для этого тега определены значения 3 и 4. Compression=3 Факсимильно-совместимая схема сжатия CCITT Group 3, в точности соответствующая документу "Standardization of Group 3 facsimile
apparatus for document transmission, Recommendation T.4, Volume VII, Fascicle
VII.3, Terminal Equipment and Protocols for Telematic Services, The
International Telegraph and Telephone Consultative Committee (CCITT), Geneva,
1985, pp. 16-31". Каждая полоса
должна начинаться с выравниванием на байт (напоминаем, что изображение может
состоять целиком из одной полосы). Строки, которые не являются первыми в полосе
не обязательно начинаются с границы байта. Данные запоминаются как байты,
никакие перестановки байтов внутри слов не допускаются. Для задания таких опций
Group 3, как 1D и 2D используется поле Group3Options. Compression=4 Факсимильно-совместимая схема сжатия CCITT Group 4, в точности соответствующая документу "Facsimile Coding Schemes and Coding
Control Functions for Group 4 Facsimile Apparatus, Recommendation T.6, Volume
VII, Fascicle VII.3, Terminal Equipment and Protocols for Telematic Services,
The International Telegraph and Telephone Consultative Committee (CCITT),
Geneva, 1985, pp. 40-48". Каждая
полоса должна начинаться с выравниванием на байт. Строки, которые не являются
первыми в полосе не обязательно начинаются с границы байта. Данные запоминаются
как байты, но не как слова. перестановки байтов внутри слов не допускаются.
Опции для Group 4 определены в поле Group4Options. ------------------------------------------------------------------ Group3Options Tag = 292 (124h) Type = LONG Length
= 1 См. Compression=3. Это
поле образовано 32
битами-флагами. Неиспользуемые биты должны быть нулевыми.
Бит с номером 0 является младшим. Наверное, не
имеет смысла пытаться читать файл, если один из этих битов имеет единичное значение, но вы не
знаете, что он означает. Бит 0 равен 1 для двумерного кодирования (в противном
случае подразумевается одномерное). Если для двумерного кодирования задано
более одной полосы, каждая полоса должна начинаться с одномерной схемы. Т.е.
RowsPerStrip должен быть умножен на "Parameter K", как это указано в
документации CCITT. Бит 1 равен 1, если используется
режим без компрессии. Бит 2 равен 1, если перед кодом EOL добавляются
биты-заполнители, чтобы EOL всегда заканчивался на границе байта. Это
обеспечивает, что EOL-последовательность всегда заканчивается единичным байтом,
которому предшествуют по крайней мере два нулевых: xxxx-0000-0000-0001. По умолчанию равен 0 для
базового одномерного кодирования. См. также Compression. Group4Options Tag = 293 (125h) Type = LONG Length
= 1 См. Compression=4. Это поле
образовано 32 битами-флагами. Неиспользуемые биты должны быть нулевыми. Бит с
номером 0 является младшим. Наверное, не имеет смысла пытаться читать файл,
если один из этих битов имеет единичное значение, но вы не знаете, что он
означает. В настоящее время изучаются схемы кодирования для серых и цветных
изображений. Они будут добавлены, когда это изучение закончится. При двумерной схеме кодирования каждая полоса кодируется так, как если
бы она была отдельным изображением. В частности, каждая полоса начинается с
границы байта и кодирование для первой строки полосы проводится независимо от
предыдущих строк с использованием горизонтальных кодов (т.е. так, как если бы
предыдущая строка была пустой). Каждая полоса заканчивается 24-битным блока
конца факсимильного сообщения (end-of-facsimile block - EOFB). Бит 0 не используется. Бит 1 равен 1, если используется режим без
компрессии. По умолчанию равно 0, для двумерной
двоичной компрессии. См. также Compression. Поля запоминания и восстановления
документов Эти поля могут полезны для запоминания и восстановления документов. Не
рекомендуется их использование для обмена с программами типа настольных
издательств. DocumentName Tag = 269
(10Dh) Type = ASCII Имя документа, из которого было
просканировано изображение. Нет умолчаний. См. также PageName. PageName Tag = 285
(11Dh) Type = ASCII Название страницы, с которой было
просканировано изображение. См. также DocumentName. Нет умолчаний. PageNumber Tag = 297
(129h) Type = SHORT Length
= 2 Этот тег используется для указания номера страницы для многостраничных
(в том числе факсимильных) документов. Задаются два значения типа SHORT. Первое
значение является номером страницы; второе - номером страницы в документе. Отметим, что страницы
не обязательно должны следовать в порядке их номеров. Номер первой страницы
равен 0. Нет умолчаний. XPosition Tag = 286
(11Eh) Type = RATIONAL X-смещение левого края изображения относительно левого края страницы,
заданное в единицах, определяемых тегом ResolutionUnits. Нет умолчаний. См. также YPosition. YPosition Tag = 287
(11Fh) Type = RATIONAL Y-смещение верхнего края изображения относительно верхнего края
страницы, заданное в единицах, определяемых тегом ResolutionUnits. В
координатной схеме TIFF положительным направлением для Y считается направление
вниз, поэтому YPosition всегда положительно. Нет умолчаний. См. также XPosition. Поля, не рекомендуемые для дальнейшего
использования Эти поля не рекомендуются в дальнейшем, за исключением, может быть, локального
использования. Их не следует применять при обмене изображениями. Они либо были
заменены другими полями, либо в них были обнаружены существенные недостатки,
либо они бесполезны сами по себе. Возможно, они будут удалены из будущих
редакций описания. CellLength Tag =
265 (109h) Type = SHORT Length = 1 Длина в одно битных компонентах матрицы для полутонирования или
дифферинга. Считается, что Threshholding = 2. Это поле, а также поля CellWidth и Threshholding, находятся под
вопросом, поскольку они не могут быть однозначно использованы для создания
изображений в серых тонах из черно-белых изображений, полученных методами
дифферинга или полутонирования (в этом состоит их единственное правдоподобное
назначение). Единственный корректный способ выполнения такой операции состоит
не в обработке этих полей, а написании удовлетворительных программ, которые
способны оперировать с экранными углами, не кратными 45 градусам и разрешать
другие проблемы, возникающие при полутонировании. Поэтому мы не рекомендуем пытаться конвертировать изображения,
созданные с помощью полутонирования и дифферинга, в серые изображения.
Дифферинг и полутонирование требуют аккуратного обращения, которое позволяло бы
избегать появления "протяженных раковин", но они могут возникать. Если
вы хотите получить серое изображение возьмите его непосредственно со сканера
или другого аналогичного устройства. Нет умолчаний. См. также
Threshholding. CellWidth Tag = 264 (108h) Type = SHORT Length
= 1 Ширина в одно битных компонентах матрицы полутонирования/ дифферинга. Нет умолчаний. См. также Threshholding и комментарий
для тега CellLength. FillOrder Tag = 266 (10Ah) Type = SHORT Length
= 1 Порядок значений данных внутри байта (1
или 2). FillOrder=1 Старшие
биты располагаются в байтах первыми. Т.е. значения данных (или кодовых слов)
упорядочены от битов старших порядков к битам младших порядков внутри байта. FillOrder=2 Младшие
биты располагаются в байте первыми. Поскольку такой порядок битов представляет
ограниченный интерес, и поскольку для программ чтения этот порядок несложно
инвертировать (используя таблицу перекодировки из 256 байтов), мы рекомендуем
использовать FillOrder=2 только для частных целей, не связанных с обменом
информацией. По умолчанию FillOrder = 1. FreeByteCounts Tag = 289 (121h) Type = LONG Для каждого свободного
блока в файле число байтов в этом блоке. Программы чтения TIFF-файлов могут
игнорировать теги FreeOffsets и FreeByteCounts, если таковые присутствуют. Теги FreeOffsets и FreeByteCounts не переопределяют логическое адресное
пространство внутри файла. Поскольку эта информация может быть извлечена путем просмотра
директорий и тегов StripOffsets и StripByteCounts, то в тегах FreeByteCounts и FreeOffsets
нет необходимости. Кроме того, неясно, что делать, если эти теги присутствуют в
нескольких директориях. См. также FreeOffsets. FreeOffsets Tag = 288 (120h) Type = LONG Для каждого свободного блока файла его
байтовое смещение. См. также FreeByteCounts. MaxSampleValue Tag = 281
(119h) Type = SHORT Length = SamplesPerPixel Максимальное используемое значение компоненты пикселов. Например, если
изображение состоит из 6-битовых данных, выровненных в младших битах 8-битовых
байтов, то значение MaxSampleValue не может быть больше 63. Это поле никак не
влияет на визуальные характеристики изображения и не оказывает влияния на
интерпретацию других полей. Используется только для статистических целей. По умолчанию равно
2**(BitsPerSample) - 1. MinSampleValue Tag = 280
(118h) Type = SHORT Length = SamplesPerPixel Минимальное используемое значение компонент пикселов. Это поле никак не
влияет на визуальные характеристики изображения. См. комментарий к тегу
MaxSampleValue. По умолчанию равно 0. SubfileType Tag = 255
(FFh) Type = SHORT Length = 1 Общее указание на то, какой тип данных содержится в данном суб-файле. В
настоящее время определены следующие значения: SubfileType=1 Изображение
с полным разрешением. Поля ImageWidth, ImageLength и StripOffsets являются
обязательными. SubfileType=2 Изображение
с уменьшенным разрешением. Поля ImageWidth, ImageLength и StripOffsets
обязательны. Далее предполагается, что это изображение является версией другого
изображения, находящегося в этом же файле, но с уменьшенным разрешением. SubfileType=3 Отдельная
страница многостраничного изображения (см. описание тега PageNumber). Отметим, что в одном TIFF-файле может находиться несколько изображений,
причем каждое из них описывается собственной IFD. Нет умолчаний. Дальнейшее использование этого поля не рекомендуется. Программы записи
должны использовать вместо него более общее поле NewSubfileType. ------------------------------------------------------------------
Orientation Tag = 274 (112h) Type = SHORT Length
= 1 Значение тега определяет ориентацию изображения на экране. Возможны
следующие значения: Orientation=1 При
высвечивании нулевая строка соответствует верхнему краю изображения и нулевая
колонка - левой его стороне. Orientation=2 При
высвечивании нулевая строка соответствует верхнему краю изображения и нулевая
колонка - правой его стороне. Orientation=3 При
высвечивании нулевая строка соответствует нижнему краю изображения и нулевая
колонка - правой его стороне. Orientation=4 При
высвечивании нулевая строка соответствует нижнему краю изображения и нулевая
колонка - левой его стороне. Orientation=5 При
высвечивании нулевая строка соответствует левой стороне изображения и нулевая
колонка - верхнему его краю. Orientation=6 При
высвечивании нулевая строка соответствует правой стороне изображения и нулевая
колонка - верхнему его краю. Orientation=7 При
высвечивании нулевая строка соответствует правой стороне изображения и нулевая
колонка - нижнему его краю. Orientation=8 При
высвечивании нулевая строка соответствует левой стороне изображения и нулевая
колонка - нижнему его краю. По умолчанию равно 1. Это поле рекомендуется только для частных применений, не связанных с
обменом информацией. Для большинства программ чтения слишком накладно выполнять
вращение изображения "на лету", т.е. при печати и передаче. Кроме
того, пользователи большинства настольных издательств не ожидают, что
переданный им файл должен непрерывно изменяться подобным образом. ------------------------------------------------------------------
Threshholding Tag = 263 (107h) Type = SHORT Length
= 1 Значение тега
определяет тип двухуровнего изображения. Возможны следующие значения: Threshholding=1 Двухуровневое изображение со сплошными линиями. BitsPerSample должен быть равен 1. Threshholding=2 Изображение,
полученное с помощью дифферинга из изображения с непрерывными тонами (типа
фотографии). BitsPerSample должен быть равен 1. Threshholding=3 То
же, что 2, но получено путем рассеивания ошибки (Error Diffused). По умолчанию
Threshholding=1. См. также CellWidth, CellLength. 4.
Частные поля Некоторая организация может пожелать запомнить в TIFF-файле информацию
таким образом, чтобы она была понятна только этой организации. Для этих целей
зарезервированы теги с номерами больше или равными 32768. По вашему требованию
администратор TIFF будет размещать и регистрировать блоки частных тегов для
организаций, чтобы избежать возможных конфликтов с другими организациями. Теги
обычно размещаются блоками по 5 штук. Если этого недостаточно, не стесняйтесь и
просите больше. Вам не нужно сообщать администратору или кому-либо еще каким
образом вы собираетесь использовать эти теги. Частные значения перечисляемых констант поддерживаются аналогичным
образом. Например, вы, возможно, захотите проэкспериментировать с новыми
схемами сжатия в рамках TIFF'а. Перечисляемые константы, имеющие значения
больше или равные 32768 зарезервированы для таких частных использований. Чтобы
избежать возможных конфликтов, по вашему требованию администратор разместит и
зарегистрирует блок перечисляемых значений для нужного поля (в нашем примере
для поля Compression). Теги и значения, которые были размещены под частными номерами, не
запрещается затем включать в будущие версии описаний TIFF. Несколько таких
примеров вы можете обнаружить и в настоящем описании. Не выбирайте свои собственные номера для тегов. Если вы это сделаете,
то в один прекрасный момент вы можете столкнуться с серьезными проблемами. 5. Обзор форматов файлов
для изображений Пытаясь устранить причины, по которым пользователи не приобретают их
продукты, некоторые программы для сканирования и редактирования изображения
ошарашивают невероятным количеством опций в функции "Save As...".
Давайте избавляться по возможности от их избытка. Например, выбор только TIFF'а
будет достаточен для большинства программ чтения, поддерживающих три его схемы
сжатия. Затем программы записи всегда могут ужать его более плотно. Имеющаяся в
TIFF'е гибкость, включающая частные теги и возможности редактирования
изображения, кажется устраняет любые разумные причины для продолжения записи
файлов изображений с использованием собственных форматов. Следование этим
принципам избавляет пользователя от необходимости знания формата файла, который
он читает с помощью прикладной программы. TIFF-файлы, также, как большинство
других форматов, содержит достаточно информации, чтобы автоматически и надежно
отличать один тип файла от другого. 6. Дополнительная
информация Для получения образцов TIFF-файлов, фрагментов исходных кодов и списка
возможностей, поддерживаемых продуктами Aldus вступите в контакт с Aldus
Developers Desk. В настоящее время Aldus Developers Desk является
администратором TIFF. Разработчики прикладных программ для Windows могут найти
вспомогательный инструмент для поддержки TIFF в пакете Windows Developers
Tookit фирмы Microsoft. Наконец, некоторые
производители сканеров обеспечивают некоторый сервис, относящийся к TIFF, типа
помощи в распространении описаний и ответов на вопросы, относящиеся к TIFF. Контактируйте
с менеджером соответствующего продукта или группой обеспечения разработчиков. Приложение
A: Разумность теговой структуры Формат файла определяется его формой (структурой) и содержанием.
Содержание TIFF'а состоит из определения конкретных полей. Следовательно, в
конце концов нас интересует именно их содержимое. Структура всего лишь говорит
нам, где эти поля найти. Однако, структура заслуживает серьезного рассмотрения
по целому ряду причин, не все из которых очевидны с первого взгляда. Поскольку
описываемая здесь структура значительно отличается от некоторых других,
возможно будет полезно обсудить степень ее разумности. Простейшей и наиболее очевидной структурой для некоторых файлов,
похожих на файлы изображений, является позиционный формат. При позиционной
схеме расположение данных определяет то, что эти данные означают. Например,
поле "число строк" может начинаться в файле изображения с байтового
смещения, равного 30. Этот метод прост, легок в реализации и является совершенным для
статической среды. Но если требуется отслеживать значительное число последующих
изменений, то начинают возникать некоторые проблемы. Например, предположим, что
поле должно быть замещено новым полем более общего характера. Вы могли бы
применить такое сильнодействующее средство, как замену номера версии. Тогда
новые программы не будут испытывать проблем при работе со старыми данными, а
старые программы будут выбрасывать все новые данные, даже если им нет дела до
изменившегося поля. На первый взгляд это может показаться незначительной
помехой, но принудительное разрушение старых программ чаще, чем это
действительно необходимо, может быть весьма накладным и неизбежно вызовет
зубовный скрежет у покупателей. Однако, этого можно избежать. Один из возможных методов состоит в запоминании
бита-флага "правильности" для каждого поля. Теперь вам не нужно
изменять номер версии, как раньше, и вы можете помещать новые поля таким
образом, что это не будет мешать старым. Старые программы, которые не имеют
дела с этим старым полем будут продолжать функционировать. (Старые программы,
которые имеют отношение к изменившемуся полю, конечно, будут неработоспособны,
но это является неизбежной ценой, которую приходится платить ради прогресса,
несущего всеобщее знание). Другой часто возникающей проблемой является то, что некоторые поля
имеют смысл только в том случае, если другие поля принимают определенные
значения. На практике это не является серьезной проблемой, порождая лишь
небольшой беспорядок. Тем не менее, заметим, что бит-флаг "правильности",
описанный в предыдущем абзаце, может помочь прояснить подобную ситуацию. Для целей диагностики очень полезными могут оказаться программы,
создающие дампы полей. Желаемой характеристикой такой программы является то,
что знает не слишком много о том, что она помещает в дамп. В частности было бы
прекрасно, если такая программа могла бы выводить ASCII-данные в ASCII-формате, целые данные в целом формате
и т.д., и эту программу не приходилось бы постоянно обучать обращению с новыми
полями. Поэтому вы вероятно захотите добавить к вашему полю компоненту
"тип данных" плюс информацию о длине самого поля таким образом, чтобы
программа создания дампов могла проходить по этим полям, не зная что они
означают. Заметим, что если мы добавим к каждому полю, называемому тегом, еще
одну компоненту, которая скажет что означает это поле, мы сможем отказаться от
флага-бита "правильности" полей и избежать ненужной траты
пространства на поля, не имеющие смысла. Простые программы создания изображений
могут записывать только некоторые поля и заканчиваться. Таким образом мы пришли к существу файлового формата, базирующегося на
тегах. Наконец, выводы.
Схема, основанная на тегах не гарантирует безболезненного роста. Но она дает
полезный инструмент для сопровождения процесса. Приложение
B: Сжатие данных по схеме 2 Аннотация Этот документ
описывает метод сжатия двухуровневых данных, основанный на факсимильной схеме
компрессии CCITT Group 3 1D. Литература 1. Standardization of Group 3
facsimile apparatus for document transmission, Recommendation T.4, Volume VII,
Fascicle VII.3, Terminal Equipment and Protocols for Telematic Services, The
International Telegraph and Telephone Consultative Committee (CCITT), Geneva,
1985, pp. 16-31. 2. Facsimile Coding Schemes
and Coding Control Functions for Group 4 Facsimile Apparatus, Recommendation
T.6, Volume VII, Fascicle VII.3, Terminal Equipment and Protocols for Telematic
Services, The International Telegraph and Telephone Consultative Committee
(CCITT), Geneva, 1985, pp. 40-48. Мы не думаем, что эти
документы необходимы для реализации схемы сжатия, соответствующей
Compression=2. Мы включили (в большинстве мест с подробными комментариями) в
это приложение всю существенную информацию. Однако, если вы захотите заказать
документы, вы можете написать в ANSI Attension по адресу: Sales, 1430 Broadway,
New York, N.Y., 10018. Попросите перечисленные выше публикации; они содержат
рекомендации T.4 и T.6. Относительно
спецификаций CCITT Спецификации CCITT
Group 3 и Group 4 описывают коммуникационные протоколы устройств определенного
класса. Сами по себе они недостаточны для описания формата дисковых данных.
Однако, к счастью, схемы кодирования CCITT могут быть легко адаптированы к
другой среде. Последующее является такой адаптацией. Значительная часть текста
просто скопирована из спецификаций CCITT. Схема
кодирования Строка данных образована сериями кодовых слов переменной длины. Каждое кодовое
слово задает последовательность либо всех черных либо всех белых пикселов (на
самом деле для задания серии определенной длины может потребоваться более
одного кодового слова, как это будет описано ниже). Черные и белые серии
чередуются. Для обеспечения цветовой синхронизации с получателем (распаковщиком)
все строки данных будут начинаться с кодового слова для белой серии. Если в
действительности строка данных начинается с черной серии, то сначала будет
послано (записано) кодовое слово для белой серии нулевой длины. Кодовые слова
для черных и белых серий приведены в таблицах 1 и 2. Кодовые слова могут быть
двух типов: терминальные (Terminating code words) и образующие (Make-up code
words). Каждая серия кодируется с помощью нуля или нескольких образующих
кодовых слов, за которыми следует одно (и только одно!) терминальное слово. Серии длиной от 0 до 63 пикселов кодируются с помощью определенных
терминальных кодовых слов. Отметим, что для черных и белых серий существуют
разные списки кодовых слов. Серии длиной от 64 до 2623 (2560+63) пикселов кодируются сначала
образующим кодовым словом, которое описывает ближайшую по длине, но не более
длинную серию, чем требуемая. За ним следует терминальное кодовое слово,
представляющее разность между требуемой серией и серией, описанной образующим
кодовым словом. Серии длина которых больше или равна 2624 пикселам кодируются сначала
образующим кодовым словом для 2560. Если оставшаяся часть серии (после первого
образующего кода для 2560) равна 2560 пикселам или более, то происходит
добавление образующих кодов для 2560 до тех пор, пока оставшаяся часть серии
станет меньше, чем 2560 пикселов. Затем оставшаяся часть серии кодируется с
помощью терминального кода или терминального кода плюс образующего кода, в
соответствии с правилами, упомянутыми выше. Если сумма длин серий для строки не равна значению поля ImageWidth, то
это считается фатальной ошибкой. Новые строки всегда
начинаются с первой доступной границы байта. Кодовое слово EOL
(конец строки) не используется. Добавление битов-заполнителей также не
применяется, за исключением последнего байта строки. RTC не используется. Таблица 1/T.4 Терминальные коды
Таблица 1/T.4 Продолжение
Таблица 2/T.4 Образующие коды
Дополнительные образующие
коды
Приложение C: Схема сжатия
данных 32773 (PackBits) Аннотация Этот документ
описывает простую схему сжатия для файлов с двухуровневыми просканированными
изображениями и рисунками. Мотивация Описание TIFF
предусматривает несколько схем сжатия данных. Сжатие типа 1 является скорее не
сжатием, а базовой упаковкой пикселов. Сжатие типа 2, основанное на одномерной
схеме сжатия CCITT, является мощным, но оно требует нетривиальной реализации.
Сжатие типа 5 обычно весьма эффективно для большинства двухуровневых
изображений, как и для многих "глубоких" изображений типа палитровых
цветных и изображений в серых тонах, но оно также требует нетривиальной
реализации. Схема PackBits является простой, но часто эффективной
альтернативой. Описание В различных прикладных задачах уже используется несколько хороших схем.
Мы отчасти произвольно выбрали схему PackBits c компьютеров Macintosh. Она
ориентирована на байты, и поэтому при ее использовании не возникает проблем с
выравниванием слов. Кроме того, она достаточно хорошо ведет себя в наихудшем
случае (не более одного дополнительного байта на 128 входных). Пользователи
Macintosh могут использовать утилиты PackBits и UnPackBits из их toolbox,
однако не составляет труда написать собственные программы. Фрагмент псевдо кода распаковки можно представить следующим образом: Цикл, пока число распакованных байтов не станет равно ожидаемому:
Чтение очередного исходного байта в n. Если n между 0 и 127 включительно, непосредственное копирование
следующих n+1 байтов. Иначе, если n между -127 и -1 включительно, копирование следующего
байта -n+1 раз. Иначе, если n равно
128, ничего не делать. Конец цикла В обратной программе лучше кодировать два 2 повторяющихся байта в серию
с повторением за исключением тех случаев, когда им предшествует или следует за
ними серия неповторяющихся байтов. Тогда лучше слить три байта в серию без
повторений. Три повторяющихся байта всегда кодируются как серия с повторением. Вот и весь алгоритм. Но для
него действуют следующие правила: 1. Каждая строка должна упаковаться отдельно. При
сжатии недопустим переход через границу строк. 2. Число несжатых байтов в строке по определению равно
(ImageWidth + 7)/8. Если для распакованного изображения требуется четное число байтов
в строке, проводите распаковку в буфер, выровненный на границу слова. 3. Если длина серии больше 128 байтов, просто
кодируйте остаток серии как одну или несколько дополнительных серий с
повторением. После распаковки данных
PackBits результат следует интерпретировать как сжатие типа 1. Приложение D Приложение D
исключено. Раньше оно содержало рекомендации для передачи TIFF-файлов в
Microsoft Windows Clipboard. Это получило негативную оценку, поскольку приводит
к увеличению размеров просканированных изображений. Вместо этого рекомендуются
программы, использующие обмен данных TIFF на основе файлов. Например, PageMaker
фирмы Aldus снабжен командой "File Place", которая позволяет
импортировать TIFF-файлы. Приложение E: Упорядоченный список тегов TIFF NewSubfileType Tag = 254
(FEh) Type = LONG Length
= 1 SubfileType Tag = 255 (FFh) Type = SHORT Length
= 1 ImageWidth Tag = 256 (100h) Type = SHORT or LONG Length
= 1 ImageLength Tag = 257 (101h) Type = SHORT или LONG Length
= 1 BitsPerSample Tag = 258 (102h) Type = SHORT Length
= SamplesPerPixel Compression Tag = 259 (103h) Type = SHORT Length
= 1 PhotometricInterpretation Tag = 262 (106h) Type = SHORT Length
= 1 Threshholding Tag = 263 (107h) Type = SHORT Length
= 1 CellWidth Tag = 264 (108h) Type = SHORT Length
= 1 CellLength Tag = 265 (109h) Type = SHORT Length
= 1 FillOrder Tag = 266 (10Ah) Type = SHORT Length
= 1 DocumentName Tag = 269 (10Dh) Type
= ASCII ImageDescription Tag = 270 (10Eh) Type
= ASCII Make Tag = 271 (10Fh) Type
= ASCII Model Tag = 272 (110h) Type
= ASCII StripOffsets Tag = 273 (111h) Type = SHORT or LONG Length = StripsPerImage для
PlanarConfiguration=1. =
SamplesPerPixel*StripsPerImage для
PlanarConfiguration=2. ------------------------------------------------------------------ Orientation Tag = 274 (112h) Type = SHORT Length
= 1 SamplesPerPixel Tag = 277 (115h) Type = SHORT Length
= 1 RowsPerStrip Tag = 278 (116h) Type = SHORT или LONG Length
= 1 StripByteCounts Tag = 279 (117h) Type = LONG or SHORT Length = StripsPerImage для
PlanarConfiguration=1. = SamplesPerPixel*StripsPerImage для PlanarConfiguration=2.
MinSampleValue Tag = 280
(118h) Type = SHORT Length
= SamplesPerPixel MaxSampleValue Tag = 281 (119h) Type = SHORT Length
= SamplesPerPixel XResolution Tag = 282 (11Ah) Type = RATIONAL Length
= 1 YResolution Tag = 283 (11Bh) Type = RATIONAL Length
= 1 PlanarConfiguration Tag = 284 (11Ch) Type = SHORT Length
= 1 PageName Tag = 285 (11Dh) Type =
ASCII XPosition Tag = 286 (11Eh) Type
= RATIONAL YPosition Tag = 287 (11Fh) Type
= RATIONAL FreeOffsets Tag = 288 (120h) Type
= LONG FreeByteCounts Tag = 289 (121h) Type
= LONG GrayResponseUnit Tag = 290 (122h) Type = SHORT Length
= 1 GrayResponseCurve Tag = 291 (123h) Type = SHORT Length
= 2**BitsPerSample Group3Options Tag = 292 (124h) Type = LONG Length
= 1 Group4Options Tag = 293 (125h) Type = LONG Length
= 1 ResolutionUnit Tag = 296 (128h) Type = SHORT Length
= 1 PageNumber Tag = 297 (129h) Type = SHORT Length
= 2 ColorResponseCurves Tag = 301 (12Dh) Type = SHORT Length
= 3 * (2**BitsPerSample) Software Tag = 305 (131h) Type
= ASCII DateTime Tag = 306 (132h) Type = ASCII Length
= 20 Artist Tag = 315 (13Bh) Type
= ASCII HostComputer Tag = 316 (13Ch) Type
= ASCII Predictor Tag = 317 (13Dh) Type = SHORT Length
= 1 WhitePoint Tag = 318 (13Eh) Type = RATIONAL Length
= 2 PrimaryChromaticities Tag = 319 (13Fh) Type = RATIONAL Length
= 6 ColorMap Tag = 320 (140h) Type = SHORT Length
= 3 * (2**BitsPerSample) Приложение F: Схема сжатия данных 5 (LZW-сжатие) Аннотация Это документ содержит
схему сжатия, адаптированную для растровых данных. Литература Terry A. Welch, A Technique
for High Performance Data Compression, IEEE Computer, vol. 17 no. 6 (June
1984). В этой статье описан
базовый Lempel-Ziv & Welch алгоритм (LZW). Цель авторов статьи состояла в
описании аппаратного упаковщика данных, который мог бы быть встроен в дисковый
контроллер или базу данных и мог бы работать с любыми типами данных. Специальное
обсуждение для растровых данных в статье отсутствует. Мы собираемся привести в
этом приложении достаточно информации, чтобы не понадобилось прочтение данной
статьи. Требования В среде настольных издательств
должна хорошо работать схема сжатия со следующими характеристиками: 1. Должна хорошо работать с изображениями любой
битовой глубины, включая изображения, имеющие глубину более 8 битов на
компоненту пиксела. 2. Должна быть эффективной: средняя степень сжатия
должна быть по крайней мере 2:1 или лучше. И должна обладать приемлемым
поведением в наихудших случаях, когда ей предлагается "нечто
странное". 3. Должна быть устойчива к малым вариациям пикселов.
Цветные палитровые изображения имеют тенденцию к внезапному изменению значений
индексов, которые порождаются при закраске регулярными образцами или методикой
дифферинга. Однако, эти резкие изменения имеют тенденцию к повторяемости и
схема должна учитывать этот факт. 4. Для изображений, сгенерированных с помощью программ
рисования, не должна зависеть от частной ширины наносимых шаблонов. Чаще всего
используются образцы размера 8x8, однако, мы не думаем, что это никогда не
изменится. 5. Должна быть быстрой. Не должна тратить более 5
секунд на раскрытие 100К изображения в серых тонах при использовании
компьютеров с процессорами 68020 или 386. Сжатие может быть медленнее, но, по
возможности, не более чем отношение 2 к 3. 6. Уровень сложности реализации должен быть
приемлемым. Таковым мы считаем то, что можно реализовать не более, чем за пару
недель силами
квалифицированного программиста и нескольких экспертов по обработке
изображений. Объем откомпилированного кода для сжатия и раскрытия в
сумме не должен превышать 10К. 7. Не должно требоваться программное и аппаратное
обеспечение для операций с плавающей точкой. В следующем разделе приведено описание алгоритма, основанного на LZW
(Lempel-Ziv & Welch) методе, который удовлетворяет перечисленным выше
требованиям. Кроме удовлетворения нашим требованиям, LZW обладает следующими
характеристиками: 1. LZW полностью обратим. Вся информация сохраняется.
Но если из изображения удалить шум или некоторую информацию, например с помощью
обнуления или осмысленной очистки младших битов, то при сжатии LZW приведет его
к меньшему размеру. Так 5-битные, 6-битные и 7-битные данные, приведенные к
8-битным, упаковываются более эффективно, чем действительно 8-битные данные.
Отфильтрованные изображения также пакуются лучше, чем зашумленные, а простые
лучше, чем сложные. 2. В компьютерах с процессорами 68020 или 386,
программы для реализации LZW могут быть написаны таким образом, что скорость
сжатия будет составлять от 30K до 80K в секунду в зависимости от характеристик
изображения. Скорость упаковки с помощью LZW обычно составляет около 50K в
секунду. 3. LZW также дает неплохие результаты для
двухуровневых изображений. Он всегда превосходит PackBits, и обычно
предпочтительнее одномерной схемы CCITT (Modified Huffman) для наших тестовых
изображений. Предпочтение перед одномерной схемой CCITT выражается в том, что
LZW оказался значительно быстрее схемы CCITT, по крайней мере в нашей
реализации. 4. Наша реализация на C дает после компиляции около 2К
объектного кода для сжатия и столько же для раскрытия данных. 5.
Одной из приятных особенностей LZW является то, что он широко используется в
других приложениях типа программ архивации и, следовательно, его количественные
характеристики хорошо известны. Алгоритм Каждая полоса пакуется независимо. Мы настоятельно рекомендуем выбирать
значение RowsPerStrip таким образом, чтобы каждая полоса перед сжатием
содержала приблизительно 8К байтов. Мы хотим сохранить строки полосы достаточно
малыми, для того, чтобы они целиком помещались в память даже на малых машинах,
но достаточно большими для поддержания коэффициента сжатия, близкого к
оптимальному. LZW-алгоритм основан на таблице трансляции или таблице цепочек, с
помощью которой осуществляется перевод входных символов в коды. Реализация для
TIFF использует коды переменной длины с максимальной длиной в 12 бит. Эта
таблица трансляции является уникальной для каждой полосы, но важно то, что ее
не нужно сохранять для раскрытия данных. Фокус в том, что при раскрытии данных автоматически строится точно такая же таблица, которая была
построена при сжатии данных. Для описания схемы сжатия воспользуемся псевдо
кодом, похожим на язык C: InitializeStringTable(); /* инициализация таблицы */
WriteCode(ClearCode); /* запись кода очистки */ s = <пустая цепочка>; for для каждого
символа в полосе K = GetNextCharacter();
/* взять очередной символ */ if s+K уже есть в таблице s = s+K; /*
конкатенация цепочки */ else WriteCode (CodeFromString(s)); /* запись кода, соответствующего цепочке
s */ AddTableEntry(s+K); /* внесение в таблицу s+K */ s = K; /* конец цикла */ WriteCode (CodeFromString(s)); /* запись кода,
соответствующего цепочке s */ WriteCode (EndOfInformation); /* запись кода конца
информации */ Это все. Схема проста, хотя в ней есть некоторые тонкости, связанные с
обеспечением эффективности. Однако, прежде, чем перейти к раскрытию данных нам
понадобятся некоторые пояснения. В нашей реализации "символы", которые образуют цепочки LZW,
являются байтами содержащимися в несжатых растровых данных (Compression=1).
Например, если BitsPerSample равно 4, то 8-битные символы LZW будут содержать
два 4-битных пиксела. Если BitsPerSample равно 16, каждый 16-битный пиксел
будет состоять из двух 8-битных символов LZW. (Возможна также реализация версии LZW, в которой
глубина символов LZW
равна BitsPerSample, как это было описано во втором черновом варианте настоящей редакции
данного описания. Но
такой метод порождает одну серьезную проблему. Если
BitsPerSample больше, чем 11,
мы не можем использовать коды с
максимальной длиной равной 12 битам и получаемая LZW-таблица становится неприемлемо велика. К
счастью, сделав адаптацию исходного LZW, мы не расплачиваемся существенным
снижением коэффициента сжатия из-за упаковки пикселов в один байт перед
сжатием. Например, наши изображения с 4-битовыми компонентами сжимаются
приблизительно на 3 процента хуже, а изображения с 1-битовыми компонентами на 5
процентов лучше. Кроме того, проще написать программу сжатия, которая всегда
использует символы одинаковой глубины, чем писать аналогичную программу,
которая поддерживает символы разной глубины.) Теперь мы может
описать некоторые программы и переменные, на которые присутствуют ссылки в
нашем псевдо коде: InitializeStringTable() инициализирует таблицу цепочек, содержащую все
возможные односимвольные цепочки. Поскольку наши символы являются байтами, то
их 256, и они нумеруются от 0 до 255. WriteCode() записывает код в выходной поток. Первый записываемый код
является кодом очистки и для него определен код #256. s является текущей
префиксной цепочкой. GetNextCharacter() возвращает из входного потока значение следующего
символа. Поскольку наши символы являются байтами, то это число в диапазоне от 0
до 255. Знак "+" означает
конкатенацию цепочек. AddTableEntry() добавляет в таблицу элемент. (InitializeStringTable() уже поместила в нашу таблицу 256 элементов.
Каждый из этих элементов образован односимвольной цепочкой и соответствующим ей
кодовым значением, которое в данном случае идентично самому символу. Т.е.
нулевой элемент нашей таблицы образован цепочкой <0>, которой
соответствует кодовое значение <0>, первый элемент состоит из цепочки
<1> с соответствующим кодовым значением <1>, ..., и 255-ый элемент
таблицы состоит из цепочки <255>, с кодовым значением <255>.)
Значит, когда мы добавляем в нашу таблицу первый элемент мы должны находиться
на позиции 256? Да, но не совсем, поскольку мы зарезервировали код #256 для
кода очистки, а код #257 для кода конца информации, который мы будем записывать
в конце каждой полосы. Поэтому первый многосимвольный элемент добавляется в
таблицу цепочек в позицию 258. Давайте рассмотрим пример. Предположим, что наши входные данные
выглядят следующим образом: Пиксел 0: <7> Пиксел 1: <7> Пиксел 2: <7> Пиксел 3: <8> Пиксел 4: <8> Пиксел 5: <7> Пиксел
6: <7> Пиксел
7: <6> Пиксел 8: <6> Сначала мы читаем пиксел 0 в K. sK становится равно <7>,
поскольку в этот момент s является пустой цепочкой. Есть ли уже в таблице
цепочек <7>? Конечно есть, поскольку все возможные односимвольные цепочки
уже были помещены в таблицу программой InitializeStringTable(). Присваиваем s
значение <7> и переходим к началу цикла. Читаем пиксел 1 в K. Есть ли уже в таблице цепочка sK
(<7><7>)? Нет, и поэтому нам нужно выполнить некоторые действия. Мы
запишем код, соответствующий s в выходной поток (выведем в выходной поток
<7>), и добавим sK (<7><7>) в таблицу в качестве
258-элемента. Запоминаем K в s. Отметим, что хотя мы добавили в таблицу
цепочку, содержащую символы 0 и 1, мы по-прежнему используем пиксел 1 в
качестве начала следующей цепочки. Возвращаемся опять к началу цикла. Мы читаем пиксел 2 в K. Есть ли уже
sK (<7><7>) в таблице? Да, мы уже добавили элемент 258, содержащий
именно <7><7>. Поэтому мы добавляем K в конец s, и s теперь
становится равным <7><7>. Возвращаемся к началу цикла. Мы читаем пиксел 3 в K. Есть ли уже sK
(<7><7><8>) в таблице? Нет, поэтому записываем код,
соответствующий s (<258>) в выходной поток и добавляем sK в таблицу в
качестве элемента 259. Запоминаем K (<8>) в s. Возвращаемся к началу цикла. Мы читаем пиксел 4 в K. Есть ли уже sK
(<8><8>) в таблице? Нет, поэтому записываем код, соответствующий s
(<8>) в выходной поток и добавляем sK в таблицу в качестве элемента 260.
Запоминаем K (<8>) в s. Продолжая, мы получим
следующие результаты:
Программа WriteCode() также требует некоторых пояснений. Поток выходных
кодов (в нашем примере это -
<7><258><8><8><258><6>...) должен быть
записан с использованием по возможности меньшего числа битов. Когда мы начинали
вывод, мы могли использовать 9-битные коды, поскольку наши новые элементы
таблицы имеют коды большие 255 но меньшие 512. Но когда мы добавим в таблицу
элемент 512, мы должны переключиться на 10-битные коды. Аналогично, мы
переключаемся на 11-битные коды при 1024 и 12-битные при 2048. Мы сами наложили
несколько произвольное ограничение в 12 битов, и поэтому наша таблица может
содержать до 4096 элементов. Если мы положим его большим, то таблица будет
иметь тенденцию к росту. Что произойдет, если мы выйдем за пределы нашей таблицы цепочек? Для этого
существует упомянутый выше код очистки. Как только мы используем элемент 4094,
мы выводим в выходной поток (12-битный) код очистки. (Если мы подождем чуть
дольше перед выводом кода очистки, то программа распаковки данных будет
пытаться интерпретировать код очистки как 13-битный код.) В этот момент
программа сжатия реинициализирует таблицу цепочек и снова начинает выдавать в
выходной поток 9-битные коды. Отметим, что как только вы вывели код в выходной поток и добавили
элемент в таблицу, s перестает быть пустой. Она содержит точно один символ.
Будьте аккуратны и не потеряйте его при записи кода очистки, сигнализирующего о
конце таблицы. Вы можете записать его как 12-битный код перед записью кода
очистки (в этом случае это надо сделать сразу после добавления в таблицу
элемента 4093), или после записи кода очистки в виде 9-битного кода. Программа
распаковки даст одинаковый результат в обоих случаях. Чтобы несколько упростить работу программ распаковки, мы требуем, чтобы
каждая полоса начиналась с кода очистки и заканчивалась кодом конца информации. Каждая полоса, упакованная с помощью LZW должна начинаться с границы
байта. Начинать с границы слова нет необходимости. Коды сжатия LZW запоминаются
в байтах в форме "от старших к младшим", т.е. предполагается, что
FillOrder=1. Коды сжатия записываются как байты, а не как слова, и поэтому
сжатые данные имеют одинаковый вид вне зависимости от того какой формат (II или
MM) используется в данном файле. Отметим, что таблица
цепочек LZW является постоянно обновляющейся историей цепочек, встречающихся в
исходных данных. Тем самым отражаются характеристики данных, давая в результате
высокую степень адаптивности. Декодирование
LZW Процедура раскрытия данных несколько более сложна, но тоже не так
плоха: while ((Code = GetNextCode()) != EoiCode) if (Code == ClearCode) InitializeTable(); Code = GetNextCode(); if (Code == EoiCode) break; WriteString(StringFromCode(Code)); OldCode = Code; else if (IsInTable(Code)) WriteString(StringFromCode(Code)); AddStringToTable(StringFromCode(OldCode)+ FirstChar(StringFromCode(Code)));
OldCode = Code; else OutString = StringFromCode(OldCode)+ FirstChar(StringFromCode(OldCode));
WriteString(OutString); AddStringToTable(OutString); OldCode = Code; Функция GetNextCode() возвращает следующий код из потока закодированных
с помощью LZW данных. Она должна отслеживать битовые границы. Она знает, что
первый код, который она возьмет, будет 9-битным. Мы добавляем элемент в таблицу
каждый раз, как только берем очередной код, поэтому GetNextCode() должна
переключиться на 10-битные коды, как только цепочка #511 будет запомнена в
таблице. Функция StringFromCode() извлекает из таблицы цепочек цепочку,
соответствующую конкретному коду. Функция AddStringToTable() добавляет цепочку в таблицу. Знак
"+" означает слияние двух частей аргумента функции AddStringToTable и
указывает на конкатенацию. StringFromCode() занимается поиском цепочки, соответствующей данному
коду. WriteString() добавляет
цепочку в выходной поток. Рекомендации
для случая SamplesPerPixel > 1 До сих пор мы описывали схему сжатия неявно считая, что SamplesPerPixel
всегда равен 1, что могло быть случаем изображения в серых тонах или
палитрового изображения. Но что делать с данными RGB-изображений? Тестирование наших изображений показало, что степень сжатия LZW почти
одинакова вне зависимости от того используется ли для RGB-данных
PlanarConfiguration=1 или PlanarConfiguration=2. Поэтому вы можете использовать
ту конфигурацию, которую вы предпочитаете, просто упаковав байты в полосы. Гораздо более важно, что степень сжатия для наших тестовых
RGB-изображений оказалась низкой: где-то от 1.1:1 до 1.5:1, в зависимости от
изображения. Мы настояли, чтобы поставщики изображений удалили по возможности
как можно больше шума. Предварительные тесты показали, что для изображений с
пониженным уровнем шума возможно значительное улучшение коэффициента сжатия.
Даже такой простой способ, как обнуление одного или двух битов во всех
плоскостях может быть достаточно эффективен и почти не влияет на само
изображение. Реализация Структура таблицы
цепочек и метод, используемый для определения того, что цепочка уже помещена в
таблицу, являются, пожалуй, наиболее значительными конструктивными решениями
при реализации LZW-сжатия и раскрытия. При сжатии полезным методом может
оказаться хеширование. Мы выбрали метод, основанный на деревьях и он дал
хорошие результаты. Раскрытие является более простым и быстрым, поскольку оно
не содержит поиска, и доступ к цепочкам может осуществляться по значениям их
кодов. Быстродействие Многие не представляют себе, что быстродействие любой схемы сжатия
сильно зависит от типа данных, для которых она используется. Схемы, которые
хорошо работают с одними данными, могут оказаться плохи для других. Поскольку мы не хотим обременять мир слишком большим набором схем
сжатия, то желательно применение адаптивных схем типа LZW, которые работают
вполне прилично с широким диапазоном изображений. Возможно, LZW не всегда дает
оптимальный коэффициент сжатия, однако его адаптивная природа и относительная
простота делают этот выбор удачным. Многочисленные эксперименты показывают, что коэффициент сжатия LZW для
непрерывных серых тоновых изображений колеблется обычно от 3.0-1.5 к 1. Если обнулить один или два младших битовых слоя в 8-битных
данных, то может быть достигнута более высокая степень сжатия. Эти битовые слои
очень часто содержат главным образом шум, и в этом случае почти не происходит
потери качества изображения. Палитровые цветные изображения, создаваемые с
помощью графических редакторов, обычно сжимаются намного лучше, чем
просканированные изображения с непрерывными тонами, поскольку имеют большую
тенденцию к повторяемости. Нет ничего необычного в достижении для таких
изображений коэффициента сжатия 10 к 1 или даже лучше. Для сравнения: схема PackBits, используемая в TIFF для черно-белых
двухуровневых изображений, дает плохие результаты для цветных изображений,
созданных с помощью графических редакторов, и еще хуже для серых и цветных
изображений с непрерывными тонами. Представляется, что средний коэффициент
сжатия составляет порядка 1.2 к 1 для 4-битных изображений и еще
хуже для 8-битных. Предполагается, что одномерная схема CCITT не может применяться для непрерывных
тоновых изображений с использованием независимого сжатия каждого битового слоя.
Нет сомнений, что такая схема может быть построена. Однако сомнительно, чтобы
схема, основанная на фиксированной таблице, которая оптимизировалась для
коротких черных серий, разделенных длинными белыми, была бы хорошим выбором для
любого битового слоя. Она должна быть очень хороша для битовых слоев старших
порядков (но для для них проще использовать схему PackBits), но очень плоха для
младших слоев. Мы думаем, что коэффициент сжатия окажется не особенно впечатляющим и, кроме того,
процесс будет значительно медленнее. Разбиение пикселов по слоям с последующей
их сборкой обратно в пикселы довольно дорог, и его код очень медленный при
реализации на программном уровне. Еще одним методом, который можно было бы рассмотреть, является
двумерное дифференцирование с последующим кодированием разностей с помощью
фиксированной таблицы кодов переменной длины. Схемы такого типа очень хорошо
срабатывают для 8-битных серых изображений, и, пожалуй, проще в реализации, чем
LZW. Но они имеют несколько недостатков при использовании разнообразных
изображений. Во-первых, они не адаптивны. Они порождают большие разности при
сжатии таких данных, как например 8-битные изображения, полученные методами
полутонирования. Такие изображения имеют при сжатии тенденцию к увеличению, а
не к уменьшению. Другой недостаток подобных схем состоит в том, что они
работают недостаточно хорошо в широком диапазоне битовых глубин. Для того,
чтобы быть эффективной, встроенная таблица кодов должна оптимизироваться для
конкретной битовой глубины. Наконец, мы должны упомянуть так называемые lossy-схемы, или схемы с
частичной потерей информации. В области этих схем ведутся очень интенсивные
исследования. Эти методы обычно дают гораздо более высокую степень сжатия, чем
та, которая может быть достигнута на полностью обратимых методах с сохранением
всей информации типа LZW и PackBits. Некоторые недостатки: многие из этих схем
настолько сложны вычислительно, что требуют аппаратной поддержки. Другие сложны
настолько, что большинство производителей программного обеспечения
микрокомпьютеров не в состоянии либо либо повысить расходы на их реализацию,
либо увеличить размер объектного кода своих прикладных программ. Третьи настолько
сильно изменяют качество изображений, что делают их непригодными для целей
публикации. Несмотря на эти трудности, мы верим, что в один прекрасный день будет
стандартизована lossy-схема для цветных изображений, которая будет пригодна для
прикладных издательских программ в микрокомпьютерах. Группа
ISO/IEC/JTC1/SC2/WG8 Международной организации стандартов (International
Standards Organization) совместно с исследовательской группой VIII (Study Group
VIII) CCITT усиленно работают над схемой, которая могла бы подойти для подобных
целей. Мы предполагаем включить такую схему в будущие редакции TIFF, как только
эта работа будет закончена, если она не будет противоречить требованиям
настольных издательств и других программ в среде микрокомпьютеров. Это будет
дополнением, но не заменой схемы LZW, которая является основной в TIFF. LZW
вероятно останется выбранной схемой для цветных палитровых изображений и, может
быть, 4-битных серых изображений и при необходимости будет являться хорошей
альтернативой схемам CCITT и PackBits для двухуровневых изображений. Будущие расширения LZW Некоторые изображения пакуются с использованием LZW лучше, если их
сначала обработать с помощью процесса, в котором значение пиксела заменяется
разностью между ним и значением предыдущего пиксела. Осуществление такого
дифференцирования по двум координатам для некоторых изображений может помочь
еще больше. Однако, многие изображения не сжимаются лучше при применении
подобной предварительной обработки, а для значительного числа изображений
коэффициент сжатия может оказаться даже хуже. Поэтому мы не стали делать
дифференцирование встроенной частью схемы LZW в TIFF. Однако, возможно, что
некоторая предварительная стадия типа дифференцирования может существовать, что
окажется эффективным для изображений определенного типа. Если такая схема будет
в дальнейшем найдена, то мы включим ее в последующие редакции спецификации
TIFF. Если это произойдет, то для нового тега TIFF Predictor будут определены
новые значения. Следовательно, все программы чтения TIFF для LZW-файлов должны
обращать внимание на значение этого тега. Если он равен 1, что соответствует
умолчанию, то можно безбоязненно выполнять LZW-раскрытие. Если же он не равен
1, и программа чтения не распознает указанную предварительную схему, то она
должна прерывать обработку. Благодарности Ссылка на оригинальный источник по LZW уже была приведена.
Использование кода очистки, как способа предотвращения переполнения таблицы,
было заимствовано из GIF (Graphics Interchange Format), формата для небольших
цветных изображений, который используется фирмой CompuServe и также содержит
адаптацию метода LZW. Джофф Морган (Joff Morgan) и Эрик Робинсон (Eric
Robinson) из фирмы Aldus создали собственные реализации для LZW-метода. Приложение
G: Классы TIFF Разумность TIFF был разработан с целью облегчения жизни для производителей
сканеров, разработчиков издательских систем и пользователей продуктов этого
класса за счет снижения многообразия форматов просканированных изображений. И
он вполне оправдал наши ожидания в этом отношении. Но мы ожидали, что он будет
интересен не только для дюжины (или около того) производителей сканеров (их не
стало намного больше по сравнению с 1985 годом) и другой дюжины (или около
того) производителей настольных издательских систем. Это было бы большой
недооценкой. Единственной проблемой, связанной с достижением успеха в этой
области является то, что TIFF разрабатывался как мощный и гибкий формат, а это
привело к некоторому усложнению. Такое обстоятельство порождает многочисленные
попытки поддержки всех опций, определенных в этой спецификации (вероятно, нет
программ которые действительно нуждались бы в столь сложной работе), и в
настоящее время это является единственным способом, гарантирующим, что вы
сможете импортировать любое TIFF-изображение, поскольку программ, генерирующих
изображения сейчас довольно много. Поэтому здесь мы приводим попытку ввести гибкость TIFF в несколько
более ограниченные рамки, используя ту информацию о полезности опций, которую
мы получили в результате двухлетнего изучения. Такое предприятие конечно же
сопряжено с принятием многочисленных произвольных решений. Но его результатом
будет являться то, что программам записи будет легче создавать файлы, которые
успешно понимались бы многочисленными программами чтения, а программы чтения
могут узнать, когда они могут прекратить добавлять возможности TIFF. Цена, которую мы
платим за классы TIFF заключается в некоторой потере способности к адаптации.
Как только мы установили требования для класса TIFF, мы никогда не сможем добавить
новое. (Лучшее, что мы можем сделать, это ввести новый класс. Но проблема
состоит в том, что очень скоро мы имели бы слишком много классов). Поэтому мы
должны поверить, что мы знаем, что мы делаем, при установке этих классов. Если
это не так, то любая ошибка будет очень дорогой. Обзор Определим четыре класса TIFF: Класс B для
двухуровневых (1-битных) изображений Класс G для серых
изображений Класс P для цветных
палитровых изображений Класс R для полностью цветных
RGB-изображений Чтобы сэкономить время и место, мы будем обычно говорить TIFF B, TIFF
G, TIFF P и TIFF R. Если речь идет обо всех четырех классах, мы можем написать
TIFF X. (Замечание для
пользователей факсов: если вам интересен класс F для факсов, давайте соберемся
и решим, что должно входить в TIFF-файлы класса F. Дайте нам знать, если вы
можете помочь в этой области. Когда вы решите, пошлите нам свои результаты и мы
поместим здесь эту информацию.) Ядро
требований Этот раздел описывает
требования, которые являются общими для всех TIFF-изображений класса X. Общие требования Ниже приведены требуемые характеристики для всех TIFF-файлов класса X. Там, где есть опции (т.е. необязательные параметры), программы записи
TIFF X могут делать то, что они предпочитают, хотя очень часто мы будем рекомендовать
конкретный выбор. Однако программы чтения TIFF X должны поддерживать все опции.
Пожалуйста, обратите внимание на эти рекомендации. Возможно, что когда-то в
будущем будут определены новые и совсем упрощенные классы TIFF, которые будут
содержать только рекомендуемые возможности. Для полного понимания последующего обсуждения вам следует прочитать по
крайней мере три первых раздела основной спецификации. Умолчания. Программы записи TIFF X могут, но не обязаны, записывать
поля, значения которых совпадают со значениями, принимаемыми по умолчанию.
Программы чтения TIFF X должны быть готовы поддерживать любую из этих ситуаций. Другие поля. Программы чтения TIFF X должны быть готовы к приему полей,
которые не обязательны для TIFF X файлов. Для программ записи TIFF X
допускается запись полей типа Make, Model, DateTime и т.д., и программы чтения
TIFF X могут определенным образом использовать такие поля, если они
присутствуют. Однако, программы чтения TIFF X не должны отказываться читать
файл, если таких полей нет. Порядок байтов MM и II. Программы чтения TIFF X должны поддерживать оба
порядка. Программы записи могут использовать тот, который наиболее удобен и
эффективен. Передача изображений между компьютерами IBM PC и Macintosh (также,
как и между другими) происходит удивительно часто. Мы могли бы заставить
программы записи использовать одинаковый порядок байтов, но заранее очевидно,
что это вызовет проблемы, как только мы начнем рассматривать более, чем 8-битные изображения. Перестановка байтов при
сканировании могла бы сильно замедлить процесс сканирования и даже вызывать его
останов, что приводило бы к проблемам с качеством получаемых изображений. Многочисленные суб-файлы. Программы чтения TIFF X должны быть готовы к
приему нескольких изображений (т.е. суб-файлов) в одном TIFF-файле, хотя им не
обязательно делать что либо с изображениями, которые следуют после первого.
Программы записи TIFF X должны записывать длинное слово 0 в конце последней
директории (это стандартный способ сигнализации о том, что директория является
последней), как это было указано при обсуждении структур TIFF. Если программа записи TIFF X записывает несколько суб-файлов, то первый
должен быть изображением с полным разрешением. Последующие изображения, такие
как изображения с уменьшенным разрешением и маски прозрачности, могут следовать
в TIFF-файле в любом порядке. Если программа чтения желает использовать
подобные изображения, она должна просмотреть директории файла перед принятием
решения о дальнейшей обработке. Редакторы TIFF X К редакторам, т.е. программам, которые модифицируют TIFF-файлы,
предъявляются дополнительные требования. Редакторы TIFF должны быть особенно аккуратны с суб-файлами. Если
редактор TIFF изменяет суб-файл для изображения с полным разрешением, но не
обновляет соответствующий суб-файл для изображения с уменьшенным разрешением,
то программы чтения, которые используют это изображение для высвечивания на
экране дисплея, будут выдавать ошибки. Поэтому редакторы TIFF должны либо
создавать новые суб-файлы после изменения суб-файлов с полным разрешением, либо
просто уничтожать любые суб-файлы, для работы с которыми они не готовы. Похожим образом
обстоит дело и с самими полями. Редакторы TIFF X должны иметь дело только с
обязательными полями TIFF X. В частности, нет необходимости, и возможно опасно,
копировать поля, значения которых непонятны. Файл мог измениться таким образом,
что он стал несовместим с неизвестным полем. Обязательные поля NewSubfileType. LONG. Рекомендуется, но не
обязательно. ImageWidth. SHORT или LONG. (Т.е. допускаются типы данных TIFF и SHORT,
и LONG, и они оба должны поддерживаться программой чтения. Программа записи
TIFF может использовать любой.) Однако, программы чтения TIFF X не обязаны
читать произвольно большие изображения. Некоторые программы чтения могут прерывать обработку, если все
изображение не удается разместить в доступной памяти (В таких случаях программа
чтения должна информировать пользователя о существе проблемы). Другие,
возможно, будут не в состоянии поддерживать изображения, для которых ImageWidth
больше, чем 65535. Рекомендация: используйте LONG, поскольку разрешение постоянно растет. ImageLength. SHORT или LONG. Рекомендация: используйте
LONG. RowsPerStrip. SHORT или LONG. Программы чтения должны быть в состоянии поддерживать
любое значение от 1 до 2**32-1. Однако, некоторые программы чтения, могут
пытаться читать полосу в память целиком, и поэтому, если вы разместите весь
образ в одной полосе, они могут выходить за пределы памяти. Рекомендация 1: Устанавливайте RowsPerStrip таким образом, чтобы размер
одной полосы равнялся приблизительно 8K байтов. Делайте это даже для несжатых
данных, поскольку это несложно для программы записи и сильно упрощает программы
чтения. (Замечание: очень широкие изображения с высоким разрешением могут иметь
строки большие 8К байтов. В этом случае RowsPerStrip должно быть 1, и полоса
будет больше, чем 8К). Рекомендация 2: используйте LONG. StripOffsets. SHORT или LONG. Как уже говорилось в основной части
спецификации, число StripOffsets зависит от RowsPerStrip и ImageLength. Рекомендация: всегда
используйте LONG. (Конечно, LONG обязательно, если длина файла больше 64K.) StripByteCounts. SHORT или LONG. Многие существующие TIFF-изображения
не содержат StripByteCounts, поскольку, строго говоря, в них нет необходимости.
Конечно, возможно написать эффективную программу чтения TIFF, которой нет
необходимости знать, как изменяется размер сжатой полосы. Но это ее значительно
усложнит, поэтому мы требуем наличия StripByteCounts в TIFF X файлах. Рекомендация: используйте SHORT, поскольку предполагается, что размер
полосы не очень велик. XResolution, YResolution. RATIONAL. Отметим, что разрешение по X и Y
может быть различным. Программы чтения TIFF X обязаны поддерживать этот случай.
Пиксельные редакторы TIFF X обычно не обращают внимания на разрешение, однако в
таких программах, как издательские системы, оно нужно. ResolutionUnit. SHORT. Программы чтения TIFF X должны быть готовы к
поддержке всех трех возможных значений для ResolutionUnit. Класс TIFF B -
двухуровневые изображения Обязательные поля (в дополнение к перечисленным выше в ядре
требований) Кроме обязательных
полей для классов TIFF X (см. выше), для файлов TIFF B обязательны следующие
поля и значения. SamplesPerPixel = 1. SHORT. (Поскольку это совпадает со значением по
умолчанию, в присутствии этого поля нет необходимости. Это правило сохраняется
для всех полей TIFF X, значения которых совпадают со значениями по умолчанию). BitsPerSample = 1. SHORT. Compression = 1, 2 (CCITT 1D),
или 32773 (PackBits). SHORT. Программы чтения TIFF B должны поддерживать все
три. Рекомендация: используйте PackBits. Она проста, эффективна, быстра и
хорошо ведет себя в наихудших ситуациях. Одномерная схема CCITT 1D определенно
эффективнее в некоторых ситуациях, например при сканировании страницы чистого
текста, но трудна в реализации и тестировании, довольно медленна и плохо ведет
себя в наихудших ситуациях. PhotometricInterpretation = 0 или 1. SHORT. Пример TIFF B изображения
Данные изображения: 00000700 Сжатые данные для полосы 10 xxxxxxxx Сжатые данные для полосы 179 xxxxxxxx Сжатые данные для полосы 53 xxxxxxxx Сжатые данные для полосы 160 . . . Конец примера Комментарии к примеру TIFF B 1. В нашем примере первая директория начинается с места, имеющего
байтовое смещение 14h. Она могла бы находиться в любом другом месте, при
условии что оно имеет четное байтовое смещение большее или равное 8, поскольку
заголовок TIFF имеет длину 8 и должен быть первым в файле. 2. При 16 строках на полосу
мы имеем всего 188 полос. 3. Пример содержит несколько необязательных полей типа DateTime.
Программы чтения TIFF X должны аккуратно пропускать такие поля, если они не
хотят использовать расположенную в них информацию. Кроме того, такие программы
не должны требовать присутствия подобных полей. 4. Наш пример содержит сильно фрагментированные данные изображения не
ради шутки (полосы нашего изображения расположены даже не последовательном
порядке). Это указывает на то, что тег StripOffsets нельзя игнорировать.
Никогда не считайте, что полоса N+1 следует за полосой N. Между прочим, не
требуется, чтобы данные изображения следовали после информации IFD. Вы должны
использовать указатели IFD, указатели полей и указатели тега StripOffsets. Класс TIFF G - серые
изображения Обязательные поля (в дополнение к перечисленным выше в ядре
требований) SamplesPerPixel = 1. SHORT. BitsPerSample = 4, 8. SHORT. Представляется, что небольшое выравнивание
при работе с серыми изображениями, мельче 4 бит, а также при работе с 5, 6 и
7-битными изображениями, облегчит их запоминание в 8-битном виде, поскольку вы
можете сжать "неиспользуемые" битовые плоскости без особой потери.
Это можно сделать с помощью LZW (Compression = 5.) Compression = 1 или 5
(LZW). SHORT. Рекомендация: используйте 5, поскольку
LZW-раскрытие достаточно быстро. PhotometricInterpretation
= 0 или 1. SHORT. Рекомендация: используйте 1, для удовлетворения популярному пользовательскому
интерфейсу для регулирования яркости и контрастности. Класс
TIFF P - цветные палитровые изображения Обязательные поля (в дополнение к перечисленным выше в ядре
требований) SamplesPerPixel =
1. SHORT. Мы используем значение как
индекс для всех трех цветовых таблиц поля ColorMap. BitsPerSample = 1,2,3,4,5,6,7, или 8. SHORT. 1,2,3,4, и 8 являются
возможно наиболее общими, но не более того, и мы оставляем для остальных
достаточную свободу выбора. Compression = 1 или 5. SHORT. PhotometricInterpretation
= 3. SHORT. ColorMap.
SHORT. Отметим, что двухуровневые и серые изображения являются частным случаем
цветных палитровых изображений. Как только вы напишите достаточно общие
прикладные программы для цветных палитровых изображений, вы, возможно,
пожелаете перестать различать двухуровневые, серые и цветные палитровые
изображения. Класс TIFF R - полностью
цветные RGB-изображения Обязательные поля (в дополнение к перечисленным выше в ядре
требований) SamplesPerPixel = 3. SHORT. По одной компоненте на красный, зеленый и
синий цвета. BitsPerSample = 8,8,8. SHORT. Мелкие изображения можно легко запомнить
в 8-битных компонентах без особых накладных расходов, если использовать сжатие
данных с помощью LZW. Очевидно, что данные с глубиной более 8 бит не
представляют ценности даже в большинстве издательских программ. PlanarConfiguration = 1 или
2. SHORT. Рекомендация: используйте 1. Compression
= 1 или 5. SHORT. PhotometricInterpretation
= 2 (RGB). SHORT. Рекомендация Для TIFF R,
рекомендуются, но необязательны, новые (так, как они описаны в редакции 5.0)
теги цветометрической информации. См. Приложение H. Подтверждения и интерфейс
для пользователя Прикладные программы, которые записывают корректные TIFF X файлы должны
содержать "TIFF B" и/или "TIFF G" и/или "TIFF P"
и/или "TIFF R" в листе спецификаций продукта (product spec sheet).
Если ваши программы могут записывать все четыре этих типа, вы можете написать
"TIFF B,G,P,R". Конечно, термин типа "TIFF B", который ясен
при контактах с другими производителями, не дает достаточной информации для
обычного пользователя. В этом случае фраза типа "Standard TIFF
Black-and-White Scanned Images" (стандарт TIFF для черно-белых сканируемых
изображений), возможно, лучше. Аналогичная линия поведения в отношении терминологии приложима к
прикладным программам, которые читают TIFF-файлы класса X. Если ваша программа способна читать большее число классов, чем
записывать, или наоборот, то неплохо бы это сделать понятным для покупателя.
Например, если ваша программа читает файлы классов TIFF B и TIFF G, но
записывает только файлы класса TIFF G, вам следует написать об этом в листе
спецификаций. Приложение
H: Цветометрическая информация изображений Chris Sears 210 Lake Street San
Francisco, CA 94118 June 4, 1988 Revised August 8, 1988 I.
Введение Наша цель состоит в точном воспроизведении цветных изображений с
использованием различных устройств. Точность требует стандартизации методов
измерения и сравнения. Наличие различных устройств подразумевает аппаратную
независимость. Цветометрия дает основу для разрешения подобных проблем. Если
изображение снабжено полной цветометрической информацией, то в принципе его
можно одинаково воспроизвести на разных мониторах с использованием специальных
методов, например офсетной литографии. Цветометрические данные определяются при создании и изменении
изображений. Цветометрические данные сканируемых изображений определяются
фильтрами и цветом исходного изображения, а синтетические изображения имеют
цветометрические данные, соответствующие монитору, на котором оно создавалось,
или мониторной модели среды визуализации. Эти данные используются для вывода
исходного изображения с использованием возможностей конкретного выходного
устройства. Раздел II описывает
организацию различных стандартов и их работу с цветами. Раздел III описывает
наши мотивы рассмотрения подобных тегов. Раздел IV описывает наши цели
воспроизведения. Разделы V, VI и VII
вводят цветометрические теги. Раздел VIII определяет
сами теги. Раздел IX описывает
умолчания. В разделе X
обсуждаются ограничения и некоторые следствия. Раздел XI содержит несколько ссылок на
литературу. II.
Стандарты цветометрии TIFF является стандартом общего назначения для описания данных типа изображений.
Было бы глупо изменять его таким образом, чтобы он не соответствовал
существующим промышленным и международным стандартам. Поэтому приведенное ниже
обсуждение отражает мучительные попытки удовлетворить стандартам различных
организаций и выбрать умолчания при работе с этими организациями. CIE (Commission
Internationale de l'Eclairage) Основой цветометрической информации является CIE 1931 Standard Observer
(стандарт наблюдения) [3]. Хотя можно было бы поддерживать другие цветовые
модели [1] [4], CIE 1931 XYZ является международным стандартом, принятым в
промышленности для указания цветов, и имеет хроматическую диаграмму CIE xyY,
связанную с трех компонентными значения CIE 1931 XYZ. NTSC (National Television System Committee - Национальный комитет
телевизионных систем). NTSC интересен главным образом по историческим причинам
и используется для кодирования телевизионных данных. Стандарты производителей
мониторов постоянно удаляются от цветометрической спецификации 1953 NTSC. SMPTE (Society of Motion Picture and Television Engineers) Значительная
часть работы NTSC выполняется SMPTE. Эта организация имеет набор стандартов,
называемый "Recommended Practices", который приложим к различным
техническим аспектам фильмов и телевизионной продукции [5] [6]. ISO (International Standards
Organization - Организация международных стандартов). ISO включено в цветовые стандарты из-за цветового
приложения к работе "Office Document Architecture (ODA) and Interchange
Format" [7]. ANSI (American
National Standards Institute - Американский национальный институт стандартов)
ANSI является представителем ISO в США. III. Мотивация Наша мотивация при определении этих тегов опирается на исследования и
разработки по технологии цветового разделения. Обсуждаемая здесь информация,
плюс RGB-данные пикселов, дают все необходимое для генерации высококачественных
цветовых разделений. Мы могли бы вынести цветометрическую информацию за пределы
файлов изображений. Однако, поскольку TIFF содержит удобный механизм для
связывания всей относящейся к делу информации в одном месте, определены теги
для описания такой информации в цветных TIFF-файлах. Цветные изображения, снабженные некорректной цветометрической
информацией могут выглядеть отличными от оригинала. Одно из наших ранних
тестовых изображений получалось искусственным из-за того, что оно сканировалось
с одним набором основных цветов а поверх него были наложены цветовые сигналы
другого цветового набора. В результате при печати синие сигналы выглядели как
пурпурные. Использование неправильной гамма-таблицы или белой точки также может
приводить к искаженным изображениям. Наилучший способ избежать такого рода
ошибок состоит в возможности для создателя изображений снабжать RGB-значения
цветометрической информацией [1] [2]. Цель цветометрических
данных состоит в том, чтобы позволить выполнить переход от основных
составляющих цвета и белой точки к основным составляющим и белой точке
устройства визуализации. Гамма отражает нелинейный перевод градиента реальных
устройств. IV. Цветометрическое воспроизведение Ранее мы сказали, что снабжение изображений цветометрической
информацией позволяет достичь идентичной визуализации на устройствах,
откалиброванных различным образом. Под идентичным мы понимаем цветометрическое
воспроизведение [9]. Главным образом
имеется в виду хроматическое соответствие, а световая интенсивность (luminance)
масштабируется в соответствии с диапазоном выходного устройства. Поэтому нам
нужны только хроматические координаты белой точки и основных цветов. Абсолютная
интенсивность произвольна, и в ней нет необходимости. V. Белая точка В редакции TIFF 4.0 белая точка была определена как D65. Данное
приложение содержит отдельный тег для описания белой точки и D65 является в нем
логичным умолчанием, поскольку это соответствует стандарту SMPTE [6]. Белая точка
определяется цветометрически на хроматической диаграмме CIE xyY. Хотя в
мониторах она редко отличается от D65, сканируемые изображения часто имеют
другую белую точку. В синтезируемых изображениях она может быть произвольной. В
художественной графике стандартом видимого яркого цвета является D50 [8]. VI.
Главные цвета В редакции TIFF 4.0 хроматические характеристики главных цветов
соответствовали спецификации NTSC. Из-за большого числа сканеров, мониторов и
устройств визуализации TIFF'у необходим механизм точного описания хроматических
характеристик основных цветов. Мы используем по умолчанию хроматические
характеристики SMPTE, поскольку обычные мониторы ближе к SMPTE, а некоторые
(Conrac 6545) производятся с ее использованием. Мы не используем белую точку и
хроматические характеристики NTSC, поскольку в настоящее время они не
используются для мониторов и должны ими матрично аппроксимироваться. Но, например, хроматические характеристики, используемые в мониторах
Sony Trinatron отличаются от тех, что рекомендованы SMPTE. В общем случае,
поскольку стандарты реальных мониторов отличаются, хроматические характеристики
основных цветов описываются в системе CIE xyY. Это позволяет системам
визуализации компенсировать такие различия. VII. ColorResponseCurves Этот тег определяет три таблицы цветопередачи, по одной для красной,
зеленой и синей компонент. Ширина каждого элемента равна 16 битам, т.е.
соответствует типу SHORT. Минимальная интенсивность представляется 0, а
максимальная 65535. Например, черный цвет описывается как 0,0,0, и белый как
65535, 65535, 65535. Размер каждой таблицы равен 2**BitsPerSample. Поле
ColorResponseCurves для RGB-данных, в которых каждая компонента имеет глубину в
8 бит, состоит из 3*256 элементов. Сначала должны следовать 256 красных
элементов, затем 256 зеленых и 256 синих. Цель поля ColorResponseCurves состоит в создании таблицы соответствия
между значениями цветовых компонент и указанными значениями интенсивности,
чтобы изображения, созданные на одной системе, могли высвечиваться в другой с
минимальными потерями цветовой точности. Таким образом, поле
ColorResponseCurves описывает "гамму" изображения, и программы чтения
TIFF или другие системы могут выполнить компенсацию гаммы изображения и гаммы
читающей системы. Гамма - это термин, относящийся к обычно нелинейному отклику
большинства систем высвечивания, включая мониторы. В большинстве систем
высвечивания напряжение, направляемое в ЭЛТ, прямо пропорционально значению
компонент красного, зеленого и синего цвета. Однако результирующее свечение
возбуждаемого фосфора не прямо пропорционально напряжению. Приближенное
уравнение для для большинства дисплеев имеет вид: свечение = напряжение **
гамма Значение гамма 2.2 в стандарте NTSC адекватно описывает большинство
видеосистем. Стандартное значение гамма 2.2 предполагает "матовое"
высвечивание (Нам неизвестны практические рекомендации SMPTE для гамма).
Пример, приведенный ниже использует 8-битную компоненту со значением 127: напряжение = 127 / 255
= 0.4980 свечение = 0.4980 ** 2.2 = 0.2157 В последующих примерах мы будем рассматривать только одну компоненту
основного цвета и, следовательно, только одну таблицу цветопередачи.
Аналогичный анализ применим для каждой из трех (красной, зеленой и синей)
компонент и таблиц. Также, не теряя общности, мы будем считать, что если нет
аппаратной таблицы цветов (палитры), то мы должны изменять значения пикселов
сами. Если же палитра присутствует, то все манипуляции должны проводиться с
ней, а не с пикселами. Если для цветного изображения поле ColorResponseCurves отсутствует, то
программа чтения должна предполагать, что гамма равна 2.2 для каждой из трех
основных компонент цвета. Таблица цветопередачи по умолчанию может быть
сгенерирована с помощью следующего кода на C: ValuesPerSample = 1 << BitsPerSample; for (curve[0] = 0, i = 1; i < ValuesPerSample; i++) curve[i] =
floor(pow(i/(ValuesPerSample - 1.0), 2.2) * 65535.0 + .5); Прикладные программы высвечивания и визуализации могут знать свое
собственное гамма, которое мы будем называть "получаемым гамма"
(Некалиброванные системы обычно считают, что их гамма равно 2.2, что не
приводит к большим ошибкам). Используя эту информацию, программа может
выполнить компенсацию для гаммы изображения способом, описанным ниже. Если исходная система и система-получатель адекватно описываются с
помощью гамма, равного 2.2, то программа записи может пропустить поле
ColorResponseCurves и программа чтения может просто прочитать данные в основной
буфер. Если программа записи записала поле ColorResponseCurves, то программа
чтения должна предполагать, что значения гамма различаются. Она может выполнить
следующие вычисления для каждой компоненты изображения: NewSampleValue = floor (pow(curve[OldSampleValue]/65535.0, 1.0 / DestinationGamma) * (ValuesPerSample - 1.0) + .5); Конечно, если гамма системы-получателя плохо аппроксимируется
экспоненциальной функцией, для уточнения можно использовать некоторую таблицу, которая
будет выдавать значения, подставляемые на место 1.0/DestinationGamma. Пропустите поле ColorResponseCurves, если вы используете значение гамма
по умолчанию. Это сэкономит в общем случае около 1.5K и, кроме того,
выбрасывание - это наилучший способ сжатия. Не используйте это поле для запоминания палитры. Для этого предназначен
тег ColorMap. Однако отметим, что поле ColorResponseCurves может использоваться
для уточнения информации поля ColorMap, если это нужно. В приведенных выше примерах предполагалось, что характеристики отклика
исходной системы и системы-получателя адекватно аппроксимируются единственным
параметром гамма. Обычно это верно, но использование таблицы вместо одного
параметра гамма придает гибкость для описания более сложных отношений, без
дополнительных вычислений и усложнения. VIII. Новые теги и
изменения В раздел "Основные поля" спецификации TIFF должны быть
помещены следующие теги. WhitePoint Tag = 318 (13Eh) Type = RATIONAL Length
= 2 Белая точка изображения. Отметим, что эти значения описываются с
использованием хроматической диаграммы 1931 CIE xyY и указываются только
хроматические составляющие. Составляющая свечения (luminance) произвольна и не
указывается. Она может соответствовать белой точке монитора, на котором
создавалось изображение, исходной комбинации фильтра set/light сканера, или
белой точке модели высвечивания в пакете визуализации. По умолчанию принимается
белая точка SMPTE, D65: x=0.313, y=0.329. Порядок компонент: x, затем y. PrimaryChromaticities Tag = 319 (13Fh) Type = RATIONAL Length
= 6 Хроматические характеристики основных цветов. Отметим, что значения
описываются с использованием хроматической диаграммы системы 1931 CIE xyY и для
них указываются только хроматические составляющие. Для изображений, созданных с
помощью графических редакторов, они описывают хроматические характеристики
монитора, а для сканируемых изображений они определяются исходной комбинацией
фильтра set/light сканера. По умолчанию принимаются хроматические характеристики стандарта SMPTE: Красный: x = 0.635 y = 0.340 Зеленый: x = 0.305 y = 0.595 Синий:
x = 0.155 y = 0.070 Порядок значений: x для красного, y для красного, x для зеленого, y для
зеленого, x для синего, y для синего. ------------------------------------------------------------------ ColorResponseCurves По умолчанию поле ColorResponseCurves представляет таблицу,
соответствующую значению гамма 2.2 принятому в стандарте NTSC. IX.
Умолчания Значения по умолчанию, используемые в TIFF отвечают промышленным стандартам.
Теги WhitePoint и PrimaryChromaticities имеют значения по умолчанию, отвечающие
стандарту SMPTE. Кроме того, значение по умолчание для тега ColorResponseCurves
соответствует спецификации NTSC для гамма 2.2. Цель этих умолчаний
состоит в том, чтобы допустить получение приемлемых результатов при отсутствии
точной цветометрической информации. Некалиброванные сканеры и устройства
отображения порождают изображения, которые всегда высвечиваются идентично,
хотя, возможно, некорректно на двух других, но калиброванных системах. Это
лучше чем неопределенность ситуации, когда изображения могли бы высвечиваться
по разному на двух разных, но калиброванных системах. X. Ограничения и следствия В этом разделе обсуждаются некоторые ограничения и следствия, относящиеся
к цветометрической визуализации. Область применения Для многих целей в рекомендуемых здесь данных нет необходимости, и они
могут быть опущены. Для представления графики, где используются всего несколько
цветов, и достаточно того, что красный цвет отличен от зеленого, они не нужны.
В этом случае данные теги можно игнорировать. В более сложных средах
представления цветных репродукций эти данные позволяют при малых затратах
описывать изображения в аппаратно-независимой форме. Бремя для пользователя Данные, которые мы рекомендуем, не являются бременем для пользователя;
в действительности они предназначены для систем. Они допускают системные
решения без вмешательства пользователя. Однако, калибровка, является отдельным
следствием; и ее нельзя выполнить без вмешательства пользователя. Разрешение против четкости Некоторые
производители предусматривают в своих цветовых спецификациях глубину цветового
разрешения более 24 бит. Целью этого является либо устранение искусственных
помех, типа горизонтальных теней, либо более точное и аппаратно-независимое
описание цвета. Обе эти причины могут быть устранены. Другим, менее дорогим
методом устранения помех, является применение палитры с большой глубиной. С
точки зрения точности, четкость более важна, чем цветовое разрешение. Цветометрическое цветовое
воспроизведение Существуют другие возможности выбора критерия для цветового
воспроизведения [9]. Спектральное цветовое воспроизведение ставит более жесткие
условия, но большинство из них - менее жесткие, чем цветометрическое
воспроизведение, выбранное нами. Однако аппаратно-независимые характеристики
цветового спектрального воспроизведения невозможны, в то время, как для
цветометрического воспроизведения они возможны в пределах допусков и
ограничений гамма конкретных устройств. Выбрав сильный критерий, мы допускаем
использование более слабых критериев, чем используемое нами цветометрическое
воспроизведение, как части пакетов конструирования. Метамеризм Если два наложенных друг на друга цвета идентичны под одним светом, но
различны под другим, то говорят, что они являются метамеричной парой.
Цветометрическое воспроизведение ставит более слабые условия, чем цветовое
спектральное, и здесь допускаются проблемы метамеризма. Стандартизовав условия
просмотра мы можем во многом обойти проблемы метамеризма для печати. Поскольку
телевидение является самосветящимся и не использует спектральное поглощение, то
для него метамеризм не составляет большой проблемы. Цветовые модели: xyY против Luv, и т.д. Мы предпочли xyY модели Luv [1] потому, что XYZ является международным
стандартом для цветовых спецификаций, а хроматическая диаграмма xyY связана с
XYZ. Система Luv имеет значение для измерения цветовых разностей. Окружающая среда и
наблюдение Окружающая среда
влияет на то, как глаз воспринимает цвет. Глаз адаптируется в темной комнате и
адаптируется к цветовому окружению. Хотя эти проблемы могут быть
скомпенсированы в рамках цветометрии [4], намного лучше решать их путем
стандартизации. Конструируемая среда должна учитывать внешнее окружение. В
частности, она не должна быть темной комнатой, и в среднем состоять из
нейтральных цветов. Для печати ANSI рекомендует поверхность N-8 [8]. XI. Литература Особенно мы хотим
отметить работу Стюарта Ринга (Stuart Ring) из отдела копирования продуктов
(Copy Products Division) компании Eastman Kodak. Он и его коллеги предложили
основы обмена цветовыми данными. Они работали в тесном контакте с ISO 8613
Working Group [7]. [1] Color Data Interchange
Paradigm, Eastman Kodak, [2] Color Reproduction and
Illumination Models, Roy Hall, International Summer Institute: State of the Art
in Computer Graphics, 1986. [3] CIE Colorimetry: Official
Recommendations of the International Commission on Illumination, Publication
15-2, 1986. [4] Color Science: Concepts
and Methods, Quantitative Data and Formulae, Gunter Wyszecki, W.S. Stiles, John
Wiley and Sons, Inc., [5] Color Monitor Colorimetry,
SMPTE Recommended Practice RP 145-1987. [6] Color Temperature for
Color Television Studio Monitors, SMPTE Recommended Practice RP 37. [7] Office Document
Architecture (ODA) and Interchange Format_Addendum on Colour, ISO 8613 Working
Draft. [8] ANSI Standard PH 2.30-1985. [9] The Reproduction of Colour
in Photography, Printing and Television, R. W. G. Hunt, Fountain Press,
Tolworth, England, 1987. [10] Raster Graphics Handbook,
The Conrac Corporation, Van Nostrand Reinhold Company, Приложение I: Схема предварительного
горизонтального дифференцирования Это приложение, написанное после реализации редакции TIFF 5.0, мы
приводим в черновой форме. Пожалуйста присылайте любые комментарии в Developers
Desk. Редакция TIFF 5.0 определила новый тег, получивший название Predictor,
который описывает методы, которые могут применяться совместно со схемами сжатия
TIFF. Здесь мы определяем значение этого тега, которое значительно улучшает
коэффициент сжатия для некоторых изображений. Схеме предварительного
горизонтального дифференцирования присвоено значение тега Predictor = 2: Predictor Tag = 317 (13Dh) Type = SHORT Length
= 1 Под предварительной обработкой понимается математическая операция,
которая выполняется над данными изображения перед применением для них схемы
кодирования. В настоящее время (как и в редакции 5.0) этот тег используется
только при применении LZW-кодирования (Compression=5), поскольку LZW является,
пожалуй, единственной схемой кодирования TIFF , которая значительно улучшается
за счет предварительных действий. См. Приложение F. 1 = Предварительных
действий перед кодированием не выполняется. 2 = Горизонтальное дифференцирование. См.
Приложение I. По умолчанию равен 1. Алгоритм Идея состоит в использовании того факта, что многие изображения с
непрерывными тонами очень мало различаются при переходе от пиксела к пикселу. В
таких изображениях, если мы заменим значения пикселов разностями
последовательных пикселов, многие разности будут принимать значения 0, плюс или
минус 1, и т.д. Это снижает избыточность информации и позволяет LZW кодировать
данные более компактно. Код на основе C для 8-битного серого изображения выглядит
приблизительно следующим образом: char image[ ][ ]; int row, col; /* вычисление
горизонтальных разностей */ for (row = 0; row <
nrows; row++) for (col = ncols - 1; col >= 1; col--) image[row][col] -=
image[row][col-1]; Если мы имеем дело не с 8-битными компонентами, мы должны работать более
сложным образом, чтобы лучше использовать архитектуру большинства процессоров.
Предположим, что мы имеем 4-битные компоненты, упакованные по два компонента в
байте, как это имеет место для несжатых данных TIFF (Compression=1). Для
вычисления разностей мы должны сначала распаковать 4-битные компоненты в
8-битные байты, получая при этом по одной компоненте в байте, выровненной по
младшим битам. Затем мы выполняем приведенное выше дифференцирование. Как
только дифференцирование закончится, мы снова перепакуем 4-битные разности по 2
на байт, как в обычных несжатых данных TIFF. Если компоненты имеют глубину более 8 битов, расширение компонент в
16-битные слова представляется наилучшим способом для выполнения вычитания на
большинстве компьютеров. Отметим, что ни при этой операции, ни позже, не происходит никакой
потери данных. На первый взгляд может показаться, что наше дифференцирование
переводит 8-битные компоненты в 9-битные разности, 4-битные компоненты в
5-битные разности и т.д. Но это отсекается тем, что мы можем полностью
игнорировать бит "переполнения" появляющийся при вычитании большего
числа из меньшего. Это вполне обратимый процесс, не порождающий ошибок. Обычная
двоичная арифметика в дополнительном коде делает все, что нам нужно. Попробуйте
выполнить несколько примеров вручную, если это будет для вас более
убедительным. До сего момента мы неявно предполагали, что мы сжимаем двухуровневые и
серые изображения. Для случая цветных изображений требуются дополнительные
обсуждения. Если PlanarConfiguration=2, то проблем нет. Процесс дифференцирования
осуществляется точно также, как для серых изображений. Если же PlanarConfiguration=1, появляются некоторые тонкости. Если мы
не сделаем исключений, мы будем вычитать красные компоненты из зеленых, зеленые
из синих и синие из красных, что вряд ли поможет LZW на стадии кодирования.
Поэтому мы вводим при вычислении горизонтальных разностей смещение, равное
SamplesPerPixel (3 в случае RGB-данных). Другими словами мы будем вычитать
красные компоненты из красных, зеленые из зеленых и синие из синих. Стадия
LZW-кодирования идентична случаю SamplesPerPixel=1. Мы требуем, чтобы
BitsPerSample было одинаковым для всех трех компонент. Результаты и следствия LZW без дифференцирования достаточно хорошо обрабатывает 1-битные изображения,
4-битные серые изображения и синтезированные изображения. Но реалистичные
24-битные цветные и 8-битные серые изображения лучше обрабатывать с
дифференцированием. Например, наши тестовые 24-битные реалистические
изображения сжимаются с трудом при использовании "обычного" LZW:
средний коэффициент сжатия равен 1.04 к 1. Средний коэффициент сжатия при
использовании горизонтального дифференцирования составляет 1.40 к 1. (Коэффициент сжатия 1.40 к 1 означает, что если несжатое изображение
имеет размер 1.40 МГб, то его сжатая версия составляет 1 МГб). Хотя комбинация LZW-кодирования с горизонтальным дифференцированием не приводит к потере каких либо данных, возможно,
что в некоторых задачах полезно отказаться от некоторой информации, удаляя по
мере возможности наибольшее количество шума из данных изображения перед
горизонтальным дифференцированием (это касается в первую очередь 8-битных
компонент). Простейший способ удаления шума состоит в маскировании одного или
нескольких младших битов в 8-битных компонентах. Для наших 24-битных
реалистических изображений LZW с горизонтальным дифференцированием давало в
среднем коэффициент сжатия 1.4 к 1. При маскировании младшего бита в каждой
компоненте коэффициент сжатия подскочил до 1.8 к 1, при маскировании двух битов
до 2.4 к 1 и при маскировании трех до 3.4 к 1. Конечно, чем больше битов вы
маскируете, тем выше риск потери вместе с шумом полезной информации. Мы
предлагаем проэкспериментировать самостоятельно, чтобы достичь наилучшего
компромисса для вашего устройства. В некоторых задачах, возможно, имеет смысл
оставить окончательное решение за пользователем. Интересно, что большинство наших RGB-изображений сжимались несколько
лучше при использовании PlanarConfiguration=1. Можно было бы предполагать, что
сжатие отдельных разностей для красной, зеленой и синей плоскостей
(PlanarConfiguration=2) могло бы давать лучшие результаты, чем смешение
разностей перед сжатием (PlanarConfiguration=1), но этого не случилось. Между прочим, мы пытались использовать и вертикальное и горизонтальное
дифференцирование, но дополнительная сложность двумерного дифференцирования не
окупается для большинства наших тестовых изображений. Приблизительно одна треть
изображений сжималась несколько лучше, еще треть несколько хуже, а остальные
дают те же результаты. Приложение J: Цветные
палитровые изображения Это приложение, написанное после реализации редакции TIFF 5.0, мы
приводим в черновой форме. Пожалуйста присылайте любые комментарии в Developers
Desk. Редакция 5.0 спецификации
TIFF определила новое значение тега PhotometricInterpretation, названное
"цвета с палитрой" (palette color). Ранее нас удивило, что эта
дополнительная сложность может представлять ценность с точки зрения реализации.
Если нет, давайте удалим ее до того, как многие пользователи начнут создавать
цветные палитровые изображения. Предложение Исключить отдельный
тип данных для цветных палитровых изображений, поскольку мы не видим
побудительных причин, которые не позволяли бы запоминать цветные палитровые
изображения как полностью цветные (обычно 24-битовые) RGB-изображения. Возражения Наиболее очевидное возражение состоит в числе требуемых цветов. Но если
вас заботит как много места займет ваше изображение на диске, вам следует
использовать LZW-сжатие, которое идеально подходит для большинства цветовых
палитровых изображений (LZW сжимает большинство палитровых изображений с
коэффициентом сжатия 5:1 и выше). И, если вы используете LZW-сжатие, то это
исключает цветные палитровые изображения, поскольку такие изображения,
запомненные как полностью цветные RGB-изображения, сжимаются почти до такого же
размера, как если бы они запоминались в палитровом виде. Таким образом, при
использовании LZW-сжатия отсутствует плата за запоминание палитровых
изображений в RGB-виде. Получаемый файл может быть больше на несколько
процентов, но он не будет больше в три раза. Для получения более подробной
информации о работе LZW см. Приложение F. Другим возражением могло бы быть то, что некоторые программы хотели бы
обрабатывать изображения иначе, если таковые действительно являются цветовыми
палитровыми изображениями. Но вы можете легко добавить вспомогательную
информацию, которая поможет программе чтения быстро распознать категорию
цветного изображения, если она того захочет. См. приведенный ниже раздел
"Новые теги". Преимущества Они очевидны, но возможно стоит обсудить, почему мы хотели бы удалить
цветные палитровые изображения, как четко выделяющийся класс. Главная проблема состоит в том, что наличие отдельного типа для цветных
палитровых изображений вносит в жизнь пользователей опасность и беспорядок.
Фактор беспорядка усиливается, поскольку пользователи частично лишаются
представлений о различии между двухуровневыми, серыми и цветными палитровыми
изображениями. Наличие двух типов цветных изображений тяжело объяснить многим
пользователям, и, пожалуй, невозможно в некоторых ситуациях скрыть от
пользователя связанные с этим сложности. Уровень риска возрастает потому, что
некоторые программы могут принимать палитровые изображения, но не принимать
полностью цветных, или наоборот, или принимать 8-битные палитровые, но не 4 или
3-битные. Вторая проблема
состоит в том, что написание и поддержка кода для работы с дополнительным типом
изображений является несколько накладной для программ чтения TIFF. Стоимость
поддержки цветных палитровых изображений зависит от задачи, но мы полагаем, что
в общем случае она будет значительна. Представляется, что имеет смысл возложить
бремя конвертирования цветных палитровых изображений в полностью цветные на
программы записи TIFF, чем заставлять программы чтения поддерживать
дополнительный тип изображения, поскольку в настоящее время программ чтения
TIFF гораздо больше, чем программ записи. Новые теги Здесь мы предлагаем новые теги, которые помогут классифицировать
цветные изображения и позволят отказаться от наличия отдельного класса для
цветных палитровых изображений. Они не обязательны для класса TIFF R , но
настоятельно рекомендуются для цветных изображений, создаваемых с помощью
графических редакторов, использующих палитры. ColorImageType Tag = 318 (13Eh) Type = SHORT Length
= 1 Снабжает программы чтения TIFF скорее идеей о том какого типа данное
цветное изображение. Содержит ограниченный набор случаев. ColorImageType=1 Реалистическое изображение с непрерывными
тонами. ColorImageType=2 Синтетическое
изображение с использованием строго ограниченного набора цветов. Такие
изображения порождаются большинством графических редакторов. Для получения списка
используемых цветов см. тег ColorList. По умолчание
принимается 1. ColorList Tag = 319 (13Fh) Type = BYTE или SHORT Length = число цветов, используемых в изображении, умноженное на
SamplesPerPixel Список цветов, которые используются в изображении. Использование этого
поля практикуется только для изображений с сильно ограниченным (обычно меньшим
или равным 256) числом цветов. Тег ColorImageType должен быть равен 2. См. тег
ColorImageType. Список организован как массив троек RGB без выравнивания. Для троек RGB
не гарантирован какой либо порядок. Отметим, что компоненты красного, зеленого
и синего могут иметь типы BYTE или SHORT. Для большинства задач должно быть
достаточно типа BYTE. Нет умолчаний. |
||||||||||||||||||||||||||||||||||||||
Copyright(c) 2004 Vasy_ok. All rights reserved.
