Мир программирования - Описание формата TIFF

Перед вами перевод спецификации 5.0 стандарта TIFF (Tag Image FileFormat). Этот документ содержит всю необходимую информацию для написания собственных программ поддержки в файлов в этом формате.

Думаю, он будет полезен всем, кто интересуется машинной графикой и

в частности таким ее аспектом, как работа с растровыми

изображениями.

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 обидится...

Этот меморандум был подготовлен фирмами Aldus и Microsoft

совместно с главными распространителями сканеров и другими

заинтересованными сторонами. Этот документ не является частью

обязательства Microsoft или Aldus обеспечивать поддержку этого

формата во всех приложениях. Если вам понадобится ответ на

специальные вопросы, затронутые в этом документе, или потребуются

дополнительные теги или модификации отдельных полей, обращайтесь

по любому из адресов:

Developers Desk Windows Marketing Group

Aldus Corporation Microsoft Corporation

411 First Ave. South 16011 NE 36th Way

Seattle, WA 98104 Redmond, WA 98073-9717

(206) 622-5500 (206) 882-8080

Этот документ описывает 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. Принимаются предложения для соглашений в других

вычислительных системах.

В TIFF конкретные поля идентифицируются с помощью уникального

тега. Это допускает присутствие или отсутствие конкретных полей в

файле в зависимости от требований конкретной задачи. Пояснения по

использованию теговых структур приведены в Приложении A.

TIFF-файл начинается с 8-байтового заголовка файла (Image File

Header), который указывает на одну или несколько директорий файла

(Image File Directories). Директории содержат информацию о

изображениях и указатели на данные самого изображения.

Теперь мы опишем эти структуры более подробно.

TIFF-файл начинается с 8-байтового заголовка, содержащего

следующую информацию:

Байты 0-1: Первое слово файла определяет порядок байтов,

используемый в файле. Допустимыми его значениями являются:

В формате 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 - 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,,o:p>

чтобы изучить примеры TIFF-изображений.

Отметим, что структура TIFF, описанная в предыдущем разделе никак

не связана с изображениями. Единственная связь описанной

структуры с изображениями, заключается в том, что поля описывают

различные характеристики и свойства изображений.

Перед тем, как определить поля, мы определим некоторые базовые

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

массивом пикселов, каждый из которых состоит из одного или

нескольких компонент (samples). В монохромных данных каждый пиксел

состоит из одной компоненты, и понятия компонента и пиксел

являются равнозначными. В цветных RGB-данных одному пикселу

соответствуют три компоненты.

Данный раздел описывает поля, определенные в настоящей редакции

TIFF. В будущем могут быть добавлены новые поля, однако, по мере

возможности это будет делаться таким образом, чтобы не разрушить

старые программы при встрече с новыми TIFF-файлами.

Документация для каждого поля содержит имя поля (достаточно

произвольное, но согласованное), значение для поля Tag value, тип

поля (Type), ожидаемое число значений (N), комментарий,

описывающий поле и значения по умолчанию, если таковые существуют.

Если поле отсутвует, программы чтения TIFF должны принимать эти

значения по умолчанию.

Текст "Нет умолчаний" не означает, что программа записи TIFF не

должна обращать внимание на это поле. Он просто означает, что для

него ничего не принимается по умолчанию. Если программа записи

имеет причины предполагать, что программе чтения понадобится

значение этого поля, она должна записать в него соответствующее

значение. Программы чтения TIFF могут делать что угодно, если они

обнаружат отсутствие нужного им поля, для которого не определены

значения по умолчанию. Например, если программа записи не запишет

поле PhotometricInterpretation (фотометрическая интерпретация), то

некоторые программы чтения будут интерпретировать изображение

правильно, а другие будут высвечивать его инвертированным. Это

нельзя признать удовлетворительным, и поэтому программы записи

должны быть достаточно аккуратны, чтобы не допускать подобных

Поля сгруппированы по нескольким категориям: базовые,

информационные, факсимильные, запоминания и восстановления

документа и не рекомендуемые в дальнейшем. В будущих версиях

описания некоторые из этих категорий могут быть помещены в

отдельные справочные документы.

В этом документе описано много полей, но большинство не являются

обязательными. В Приложении G содержится список полей, являющихся

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