Форматы представления графической информации в ЭВМ. Формат графических изображений TIFF

 

 

 

 

 

 

 

 

 

 

 

 

 

Курсовая работа

по  дисциплине: «Представление графической  информации»

на  тему: «Форматы представления графической информации в ЭВМ.

Формат  графических изображений TIFF.»

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Хабаровск 2013 г.

 

Содержание

 

Введение3

1. Структура5

1.1. Заголовок файла (Image File Header - IFD)5

1.2. Директории файла (Image File Directory)6

2. Определения8

3. Поля9

3.1. Базовые поля9

3.2. Информационные поля17

3.3. Факсимильные поля18

3.4. Поля запоминания и восстановления документов20

3.5. Поля, не рекомендуемые для дальнейшего использования20

4. Частные поля25

5. Обзор форматов файлов для изображений26

6. Дополнительная информация27

Заключение28

Список  используемой литературы29

 

 

Введение

TIFF – это семейство форматов  изображений, сгруппированных под  единым названием, первоначально разработанное компанией Aldus Corporation, теперь Adobe, и выпущенное для свободного копирования. Файл TIFF содержит список и серию тегов, которые определяют специфические типы данных. Файлы TIFF поддерживают CMYK, RGB, Lab, файлы в оттенках только серого с альфаканалами, файлы с индексированными цветами и монохромные файлы без альфаканалов. Данный формат широко используется для передачи отсканированных пиксельных изображений. Они также могут быть сжаты с использованием компрессии LZW (сжатие данных методом Лемпела–Зива–Уэлча). Впрочем, думается, большинство полиграфистов не пользуется этой возможностью, поскольку она увеличивает время печати. TIFF означает – теговый формат графических файлов. TIFF был создан в 1986 году группой компаний. Среди них были: Aldus, Datacopy, DEST Corporation, Hewlett Packard, Microsoft, Microtek  International и New Image Technology. У этого формата относительно короткая история, которая включает шесть новых версий. TIFF был создан для того, чтобы представить жизнеспособный метод передачи данных между сканерами и компьютерными программами. С самого начала TIFF был разработан для полиграфической индустрии. TIFF – один из самых гибких форматов пиксельных файлов. У него есть возможность выходить за пределы платформ и архитектуры компьютеров. Он может работать с черно белыми и цветными изображениями. Цветные изображения могут сохраняться в различных цветовых пространствах, делая TIFF привлекательным для полиграфистов. Ошибки в порядке побайтовой обработки данных, в алгоритмах сжатия и теговых данных могут привести к разрушению файла TIFF. Внутри TIFF Информация в файле TIFF организована по трем отделам: заголовок файла изображения (Image File Header), директория файла изображения (Image File Direсtory) и растровые пиксельные данные. Из этих отделов только два необходимы для создания файла TIFF – ни один из них не является пиксельными данными. Файл TIFF может оставаться TIFF без пиксельной информации. Заголовок файла изображения очень прост и содержит информацию о том, что файл закодирован в формате следования байтов, начиная с младшего, либо начиная со старшего. В зависимости от используемой вами компьютерной системы вы должны учитывать порядок следования байтов, в котором сохраняются многобайтовые числа, особенно если вы записываете эти числа в файл. Существуют два порядка следования байтов: обратный порядок следования, начиная с младшего (Little Endian) и прямой порядок, начиная со старшего. Обратный порядок означает, что младший байт располагается в памяти по меньшему адресу, а старший байт по большему адресу. (Первым идет младший байт.) Процессоры Intel (которые используются в PC) применяют обратный порядок следования байтов. Прямой порядок следования байтов означает, что старший байт из последовательности сохраняется в памяти по наименьшему адресу, а младший байт по наибольшему адресу. (Наибольшая величина идет первой.) Процессоры Motorola (используемые в компьютерах Mac) применяют прямой порядок следования байтов. Оба формата имеют свои плюсы и минусы, но, к счастью, оба работают. Файл также включает в себя номер версии, или, точнее, идентификационный номер. Номер версии – 42 независимо от того, какая версия TIFF используется. Заголовок файла изображения – единственная постоянная часть файла TIFF. Директория файла изображения и пиксельные данные могут размещаться в различных местах файла. Все данные, за исключением заголовка файла изображения, который всегда находится в начале, размещаются с использованием директории файла изображения. Директория и соответствующая ей пиксельная информация известны как подфайл TIFF. Теоретически не существует ограничений количества подфайлов, которые может иметь файл TIFF. Чтобы объявить пиксельные данные для директории, каждый ее подфайл имеет тег. Он содержит конкретную информацию о данных, включая любую из 70 различных теговых поддержек TIFF. Внутри TIFF существуют общие и частные теги. Общие теги доступны для чтения всем, в то время как частные теги могут использоваться только собственником. Эта новая характеристика относится к базовым и расширенным вариантам новейшей версии TIFF.

 

1. Структура

В TIFF конкретные поля идентифицируются с помощью уникального тега. Это допускает присутствие или отсутствие конкретных полей в файле в зависимости от требований конкретной задачи.

TIFF-файл начинается с 8-байтового заголовка файла (Image File Header), который указывает на одну или несколько директорий файла (Image File Directories). Директории содержат информацию об изображениях и указатели на данные самого изображения.

 

1.1. Заголовок файла (Image File Header - IFD)

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

Байты 0-1: Первое слово файла определяет порядок байтов, используемый в файле. Допустимыми его значениями являются:

II (hex 4949);

MM (hex 4D4D).

В формате II в 16-битных и 32-битных целых  числах порядок байтов всегда идет от младших (менее значимых) к старшим (более значащим). В формате MM для тех же чисел порядок байтов идет от старших к младшим. В обоих форматах символьные строки запоминаются как последовательность байтов в их естественном порядке.

Все программы, читающие TIFF-файлы, должны поддерживать оба порядка байтов.

Байты 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). Директория может располагаться в любом месте файла вслед за заголовком, но ее начало должно быть выровнено на границу слова. В частности, директория может следовать за данными изображения, которое она описывает. Программы чтения должны просто перемещаться по этому указателю, вне зависимости от того, куда он указывает.

 

 

1.2. Директории файла (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. Заметим, что этот порядок отличен от того, в котором поля описаны в данном документе. Значения, на которые указывают элементы директории, могут следовать в файле в любом порядке.

Для экономии времени и пространства поле 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 и подобного ему. Заметим, что в файле может существовать несколько IFD. Говорят, что каждый IFD определяет суб-файл (subfile). Одна из потенциальных возможностей использования последовательных суб-файлов состоит в описании суб-изображений, каждое из которых связано с главным, например, является его версией с уменьшенным разрешением.

 

2. Определения

Отметим, что структура TIFF, описанная  в предыдущем разделе никак не связана с изображениями. Единственная связь описанной структуры с изображениями, заключается в том, что поля описывают различные характеристики и свойства изображений.

Перед тем, как определить поля, мы определим некоторые базовые понятия. По определению изображение является прямоугольным массивом пикселов, каждый из которых состоит из одного или нескольких компонент (samples). В монохромных данных каждый пиксел состоит из одной компоненты, и понятия компонента и пиксел являются равнозначными. В цветных RGB-данных одному пикселу соответствуют три компоненты.

 

3. Поля

Данный раздел описывает поля, определенные в настоящей редакции TIFF. В будущем могут быть добавлены новые поля, однако, по мере возможности это будет делаться таким образом, чтобы не разрушить старые программы при встрече с новыми TIFF-файлами.

Документация для каждого поля содержит имя поля (достаточно произвольное, но согласованное), значение для поля Tag value, тип поля (Type), ожидаемое число значений (N), комментарий, описывающий поле и значения по умолчанию, если таковые существуют. Если поле отсутвует, программы чтения TIFF должны принимать эти значения по умолчанию.

Текст "Нет умолчаний" не означает, что программа записи TIFF не должна обращать внимание на это поле. Он просто означает, что для него ничего не принимается по умолчанию. Если программа записи имеет причины предполагать, что программе чтения понадобится значение этого поля, она должна записать в него соответствующее значение. Программы чтения TIFF могут делать что угодно, если они обнаружат отсутствие нужного им поля, для которого не определены значения по умолчанию. Например, если программа записи не запишет поле PhotometricInterpretation (фотометрическая интерпретация), то некоторые программы чтения будут интерпретировать изображение правильно, а другие будут высвечивать его инвертированным. Это нельзя признать удовлетворительным, и поэтому программы записи должны быть достаточно аккуратны, чтобы не допускать подобных ситуаций.

Поля сгруппированы по нескольким категориям: базовые, информационные, факсимильные, запоминания и восстановления документа и не рекомендуемые в дальнейшем.

 

3.1. Базовые поля

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

BitsPerSample

Tag = 258 (102h)

Type = SHORT

Length = SamplesPerPixel

Значения этого тега определяют число битов в каждой компоненте пиксела. Отметим, что этот тег допускает различное число бит для каждой компоненты, соответствующей пикселу. Например, цветные RGB-данные могут использовать различное число бит для компонент каждой из трех цветовых плоскостей. Большинство RGB-файлов имеют одинаковое число BitsPerSample для каждой компоненты. Даже в этом случае следует включать все три элемента. Запись только 8 вместо 8,8,8 создает ошибочную ситуацию для других полей.

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 по умолчанию.

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-изображений.

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 наоборот.