Форматы представления графической информации в ЭВМ. Формат графических изображений 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 наоборот.

Если число бит в компоненте не является степенью 2, и вы готовы пожертвовать некоторым пространством для достижения более высокого быстродействия, вы можете использовать ближайшее значение, являющееся степенью 2. Например, если ваши данные описываются 6 битами, вы, возможно, захотите указать, что они содержат 8 бит.

Строки должны начинаться с выравниванием на байт. Следовательно, число байт на строку должно равняться (ImageWidth*SamplesPerPixel*BitsPerSample + 7)/8, имея в виду целую арифметику, для PlanarConfiguration=1. Для PlanarConfiguration=2 это число равно (ImageWidth * BitsPerSample + 7)/8.

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

Compression=2

Схема сжатия CCITT Group 3. Одно размерное кодирование длинных серий по модифицированной схеме Хаффмана.

Когда вы декодируете данные, которые были сжаты с Compression=2, вы должны транслировать белые серии в последовательность нулей, и черные - в последовательность единиц. Следовательно, стандартным значением PhotometricInterpretation для этого сжатия является 0 (WhiteIsZero). Если программа чтения встретит значение PhotometricInterpretation, равное 1 (BlackIsZero) для такого изображения, оно должно быть высвечено или напечатано с инвертированием черного и белого цветов.

Compression=5

LZW-сжатие для серых и цветных изображений.

Compression=32773

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

Сжатие данных оказывает влияние только на растровые данные, на которые имеется указатель в StripOffsets. Вся другая TIFF-информация остается неизменной.

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 в таких файлах.

Если в 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

Tag = 290 (122h)

Type = SHORT

Length = 1

Значение тега позволяет определить в каких единицах оптическая плотность в теге GrayResponseCurve. Возможные значения GrayResponse Unit:

1 = Число представляет десятые  доли единицы.

2 = Число представляет сотые  доли единицы.

3 = Число представляет тысячные  доли единицы.

4 = Число представляет десятитысячные  доли единицы.

5 = Число представляет стотысячные  доли единицы.

Влияет на GrayResponseCurve.

ImageLength

Tag = 257 (101h)

Type = SHORT или LONG

Length = 1

Длина (высота) изображения в пикселах (Y: вертикаль). Число строк (иногда их называют как строки развертки) в изображении. См. также ImageWidth.

ImageWidth

Tag = 256 (100h)

Type = SHORT or LONG

Length = 1

Ширина изображения в пикселах (X: горизонталь). Число колонок в изображении.

NewSubfileType

Tag = 254 (FEh)

Type = LONG

Length = 1

Замещает старое поле SubfileType, снимая ограничения, определенные в этом поле.

Общее описание данных, содержащихся в этом суб-файле. Это поле образовано 32 битами-флагами. Предполагается, что неиспользуемые биты должны быть равны 0. Бит 0 является младшим.

В настоящее время определены следующие  значения:

Бит 0 равен 1, если изображение является версией с пониженным разрешением другого изображения, имеющегося в этом же TIFF-файле. В противном случае бит равен 0.

Бит 1 равен 1, если изображение является отдельной страницей многостраничного изображения. В противном случае бит равен 0.

Бит 2 равен 1, если изображение определяет маску прозрачности для другого изображения в этом же TIFF-файле. Значение тега PhotometricInterpretation должно равняться 4 (это значение соответствует маске прозрачности).

Эти значения определены как битовые флаги, поскольку они в достаточной степени независимы один от другого. Например, полезно иметь 4 разных изображения в одном TIFF-файле: изображение с полным разрешением, изображение с пониженным разрешением, маску прозрачности для изображения с полным разрешением и маску прозрачности для изображения с пониженным разрешением. Каждое из этих четырех изображений будет иметь различное значение поля NewSubfileType.

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 не имеет значения и не должен включаться.

Predictor

Tag = 317 (13Dh)

Type = SHORT

Length = 1

Используется при Compression=5 (LZW).

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

Сантиметры.

RowsPerStrip

Tag = 278 (116h)

Type = SHORT или LONG

Length = 1

Число строк в полосе. Данные изображения организуются в полосы, которые затем используются для быстрого доступа к нужной строке, если данные подвергались сжатию (хотя использование этого поля допустимо даже если данные не сжимались).

Теги RowsPerStrip и ImageLength сообщают вам число полос во всем изображении. Уравнение StripsPerImage = (ImageLength + RowsPerStrip - 1) / RowsPerStrip подразумевает использование целой арифметики.

Заметим, что для значения тега могут использоваться типы данных SHORT или LONG. Значение SHORT используется для небольших TIFF-файлов. Однако, следует заметить, что предыдущие описания TIFF-файлов требовали значения LONG и некоторые прикладные программы могут не ожидать появления значения типа SHORT.

По умолчанию равно 2**32-1, что на практике означает бесконечность, т.е. все изображение располагается в одной полосе. Однако, мы не рекомендуем использовать одну полосу. Выбирайте RowsPerStrip таким образом, чтобы каждая полоса занимала приблизительно 8К байтов, даже если данные не сжимаются, поскольку это упрощает буферизацию для программ чтения. Значение 8К является достаточно произвольным, но представляется вполне работоспособным.