4. Частные поля
———————————————
Некоторая организация может пожелать запомнить в TIFF-файле
информацию таким образом, чтобы она была понятна только этой
организации. Для этих целей зарезервированы теги с номерами больше
или равными 32768. По вашему требованию администратор TIFF будет
размещать и регистрировать блоки частных тегов для организаций,
чтобы избежать возможных конфликтов с другими организациями. Теги
обычно размещаются блоками по 5 штук. Если этого недостаточно, не
стесняйтесь и просите больше. Вам не нужно сообщать администратору
или кому-либо еще каким образом вы собираетесь использовать эти
теги.
Частные значения перечисляемых констант поддерживаются аналогичным
образом. Например, вы, возможно, захотите проэкспериментировать с
новыми схемами сжатия в рамках TIFF'а. Перечисляемые константы,
имеющие значения больше или равные 32768 зарезервированы для таких
частных использований. Чтобы избежать возможных конфликтов, по
вашему требованию администратор разместит и зарегистрирует блок
перечисляемых значений для нужного поля (в нашем примере для поля
Compression).
Теги и значения, которые были размещены под частными номерами, не
запрещается затем включать в будущие версии описаний TIFF.
Несколько таких примеров вы можете обнаружить и в настоящем
описании.
Не выбирайте свои собственные номера для тегов. Если вы это
сделаете, то в один прекрасный момент вы можете столкнуться с
серьезными проблемами.
.
- 38 -
5. Обзор форматов файлов для изображений
————————————————————————————————————————
Пытаясь устранить причины, по которым пользователи не приобретают
их продукты, некоторые программы для сканирования и редактирования
изображения ошарашивают невероятным количеством опций в функции
"Save As...". Давайте избавляться по возможности от их избытка.
Например, выбор только TIFF'а будет достаточен для большинства
программ чтения, поддерживающих три его схемы сжатия. Затем
программы записи всегда могут ужать его более плотно. Имеющаяся в
TIFF'е гибкость, включающая частные теги и возможности
редактирования изображения, кажется устраняет любые разумные
причины для продолжения записи файлов изображений с использованием
собственных форматов.
Следование этим принципам избавляет пользователя от необходимости
знания формата файла, который он читает с помощью прикладной
программы. TIFF-файлы, также, как большинство других форматов,
содержит достаточно информации, чтобы автоматически и надежно
отличать один тип файла от другого.
.
- 39 -
6. Дополнительная информация
————————————————————————————
Для получения образцов TIFF-файлов, фрагментов исходных кодов и
списка возможностей, поддерживаемых продуктами Aldus вступите в
контакт с Aldus Developers Desk. В настоящее время Aldus
Developers Desk является администратором TIFF.
Разработчики прикладных программ для Windows могут найти
вспомогательный инструмент для поддержки TIFF в пакете Windows
Developers Tookit фирмы Microsoft.
Наконец, некоторые производители сканеров обеспечивают некоторый
сервис, относящийся к TIFF, типа помощи в распространении описаний
и ответов на вопросы, относящиеся к TIFF. Контактируйте с
менеджером соответствующего продукта или группой обеспечения
разработчиков.
.
- 40 -
Приложение A: Разумность теговой структуры
———————————————————————————————————————————
Формат файла определяется его формой (структурой) и содержанием.
Содержание TIFF'а состоит из определения конкретных полей.
Следовательно, в конце концов нас интересует именно их содержимое.
Структура всего лишь говорит нам, где эти поля найти. Однако,
структура заслуживает серьезного рассмотрения по целому ряду
причин, не все из которых очевидны с первого взгляда. Поскольку
описываемая здесь структура значительно отличается от некоторых
других, возможно будет полезно обсудить степень ее разумности.
Простейшей и наиболее очевидной структурой для некоторых файлов,
похожих на файлы изображений, является позиционный формат. При
позиционной схеме расположение данных определяет то, что эти
данные означают. Например, поле "число строк" может начинаться в
файле изображения с байтового смещения, равного 30.
Этот метод прост, легок в реализации и является совершенным для
статической среды. Но если требуется отслеживать значительное
число последующих изменений, то начинают возникать некоторые
проблемы. Например, предположим, что поле должно быть замещено
новым полем более общего характера. Вы могли бы применить такое
сильнодействующее средство, как замену номера версии. Тогда новые
программы не будут испытывать проблем при работе со старыми
данными, а старые программы будут выбрасывать все новые данные,
даже если им нет дела до изменившегося поля. На первый взгляд это
может показаться незначительной помехой, но принудительное
разрушение старых программ чаще, чем это действительно необходимо,
может быть весьма накладным и неизбежно вызовет зубовный скрежет у
покупателей.
Однако, этого можно избежать. Один из возможных методов состоит в
запоминании бита-флага "правильности" для каждого поля. Теперь вам
не нужно изменять номер версии, как раньше, и вы можете помещать
новые поля таким образом, что это не будет мешать старым. Старые
программы, которые не имеют дела с этим старым полем будут
продолжать функционировать. (Старые программы, которые имеют
отношение к изменившемуся полю, конечно, будут неработоспособны,
но это является неизбежной ценой, которую приходится платить ради
прогресса, несущего всеобщее знание).
Другой часто возникающей проблемой является то, что некоторые поля
имеют смысл только в том случае, если другие поля принимают
определенные значения. На практике это не является серьезной
проблемой, порождая лишь небольшой беспорядок. Тем не менее,
заметим, что бит-флаг "правильности", описанный в предыдущем
абзаце, может помочь прояснить подобную ситуацию.
Для целей диагностики очень полезными могут оказаться программы,
создающие дампы полей. Желаемой характеристикой такой программы
является то, что знает не слишком много о том, что она помещает в
дамп. В частности было бы прекрасно, если такая программа могла
.
- 41 -
бы выводить ASCII-данные в ASCII-формате, целые данные в целом
формате и т.д., и эту программу не приходилось бы постоянно
обучать обращению с новыми полями. Поэтому вы вероятно захотите
добавить к вашему полю компоненту "тип данных" плюс информацию о
длине самого поля таким образом, чтобы программа создания дампов
могла проходить по этим полям, не зная что они означают.
Заметим, что если мы добавим к каждому полю, называемому тегом,
еще одну компоненту, которая скажет что означает это поле, мы
сможем отказаться от флага-бита "правильности" полей и избежать
ненужной траты пространства на поля, не имеющие смысла. Простые
программы создания изображений могут записывать только некоторые
поля и заканчиваться.
Таким образом мы пришли к существу файлового формата,
базирующегося на тегах.
Наконец, выводы. Схема, основанная на тегах не гарантирует
безболезненного роста. Но она дает полезный инструмент для
сопровождения процесса.
.
- 42 -
Приложение 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.
Схема кодирования
Строка данных образована сериями кодовых слов переменной длины.
Каждое кодовое слово задает последовательность либо всех черных
либо всех белых пикселов (на самом деле для задания серии
определенной длины может потребоваться более одного кодового
слова, как это будет описано ниже). Черные и белые серии
чередуются.
.
- 43 -
Для обеспечения цветовой синхронизации с получателем
(распаковщиком) все строки данных будут начинаться с кодового
слова для белой серии. Если в действительности строка данных
начинается с черной серии, то сначала будет послано (записано)
кодовое слово для белой серии нулевой длины. Кодовые слова для
черных и белых серий приведены в таблицах 1 и 2. Кодовые слова
могут быть двух типов: терминальные (Terminating code words) и
образующие (Make-up code words). Каждая серия кодируется с помощью
нуля или нескольких образующих кодовых слов, за которыми следует
одно (и только одно!) терминальное слово.
Серии длиной от 0 до 63 пикселов кодируются с помощью определенных
терминальных кодовых слов. Отметим, что для черных и белых серий
существуют разные списки кодовых слов.
Серии длиной от 64 до 2623 (2560+63) пикселов кодируются сначала
образующим кодовым словом, которое описывает ближайшую по длине,
но не более длинную серию, чем требуемая. За ним следует
терминальное кодовое слово, представляющее разность между
требуемой серией и серией, описанной образующим кодовым словом.
Серии длина которых больше или равна 2624 пикселам кодируются
сначала образующим кодовым словом для 2560. Если оставшаяся часть
серии (после первого образующего кода для 2560) равна 2560
пикселам или более, то происходит добавление образующих кодов для
2560 до тех пор, пока оставшаяся часть серии станет меньше, чем
2560 пикселов. Затем оставшаяся часть серии кодируется с помощью
терминального кода или терминального кода плюс образующего кода, в
соответствии с правилами, упомянутыми выше.
Если сумма длин серий для строки не равна значению поля
ImageWidth, то это считается фатальной ошибкой.
Новые строки всегда начинаются с первой доступной границы байта.
Кодовое слово EOL (конец строки) не используется. Добавление
битов-заполнителей также не применяется, за исключением последнего
байта строки. RTC не используется.
.
- 44 -
Таблица 1/T.4 Терминальные коды
Ъ——————В—————————В——————В—————————————ї
іДлина іКодовое іДлина іКодовое і
ібелой іслово ічернойіслово і
ісерии і ісерии і і
Г——————Е—————————Е——————Е—————————————ґ
і 0 і00110101 і 0 і0000110111 і
і 1 і000111 і 1 і010 і
і 2 і0111 і 2 і11 і
і 3 і1000 і 3 і10 і
і 4 і1011 і 4 і011 і
і 5 і1100 і 5 і0011 і
і 6 і1110 і 6 і0010 і
і 7 і1111 і 7 і00011 і
і 8 і10011 і 8 і000101 і
і 9 і10100 і 9 і000100 і
і10 і00111 і 10 і0000100 і
і11 і01000 і 11 і0000101 і
і12 і001000 і 12 і0000111 і
і13 і000011 і 13 і00000100 і
і14 і110100 і 14 і00000111 і
і15 і110101 і 15 і000011000 і
і16 і101010 і 16 і0000010111 і
і17 і101011 і 17 і0000011000 і
і18 і0100111 і 18 і0000001000 і
і19 і0001100 і 19 і00001100111 і
і20 і0001000 і 20 і00001101000 і
і21 і0010111 і 21 і00001101100 і
і22 і0000011 і 22 і00000110111 і
і23 і0000100 і 23 і00000101000 і
і24 і0101000 і 24 і00000010111 і
і25 і0101011 і 25 і00000011000 і
і26 і0010011 і 26 і000011001010 і
і27 і0100100 і 27 і000011001011 і
і28 і0011000 і 28 і000011001100 і
і29 і00000010 і 29 і000011001101 і
і30 і00000011 і 30 і000001101000 і
і31 і00011010 і 31 і000001101001 і
і32 і00011011 і 32 і000001101010 і
і33 і00010010 і 33 і000001101011 і
і34 і00010011 і 34 і000011010010 і
і35 і00010100 і 35 і000011010011 і
і36 і00010101 і 36 і000011010100 і
і37 і00010110 і 37 і000011010101 і
і38 і00010111 і 38 і000011010110 і
і39 і00101000 і 39 і000011010111 і
і40 і00101001 і 40 і000001101100 і
А——————Б—————————Б——————Б—————————————Щ
.
- 45 -
Таблица 1/T.4 Продолжение
Ъ——————В—————————В——————В—————————————ї
іДлина іКодовое іДлина іКодовое і
ібелой іслово ічернойіслово і
ісерии і ісерии і і
Г——————Е—————————Е——————Е—————————————ґ
і41 і00101010 і 41 і000001101101 і
і42 і00101011 і 42 і000011011010 і
і43 і00101100 і 43 і000011011011 і
і44 і00101101 і 44 і000001010100 і
і45 і00000100 і 45 і000001010101 і
і46 і00000101 і 46 і000001010110 і
і47 і00001010 і 47 і000001010111 і
і48 і00001011 і 48 і000001100100 і
і49 і01010010 і 49 і000001100101 і
і50 і01010011 і 50 і000001010010 і
і51 і01010100 і 51 і000001010011 і
і52 і01010101 і 52 і000000100100 і
і53 і00100100 і 53 і000000110111 і
і54 і00100101 і 54 і000000111000 і
і55 і01011000 і 55 і000000100111 і
і56 і01011001 і 56 і000000101000 і
і57 і01011010 і 57 і000001011000 і
і58 і01011011 і 58 і000001011001 і
і59 і01001010 і 59 і000000101011 і
і60 і01001011 і 60 і000000101100 і
і61 і00110010 і 61 і000001011010 і
і62 і00110011 і 62 і000001100110 і
і63 і00110100 і 63 і000001100111 і
А——————Б—————————Б——————Б—————————————Щ
.
- 46 -
Таблица 2/T.4 Образующие коды
Ъ——————В————————————В——————В—————————————ї
іДлина іКодовое іДлина іКодовое і
ібелой іслово ічернойіслово і
ісерии і ісерии і і
Г——————Е————————————Е——————Е—————————————ґ
і 64 і11011 і 64 і0000001111 і
і 128 і10010 і 128 і000011001000 і
і 192 і010111 і 192 і000011001001 і
і 256 і0110111 і 256 і000001011011 і
і 320 і00110110 і 320 і000000110011 і
і 384 і00110111 і 384 і000000110100 і
і 448 і01100100 і 448 і000000110101 і
і 512 і01100101 і 512 і0000001101100і
і 576 і01101000 і 576 і0000001101101і
і 640 і01100111 і 640 і0000001001010і
і 704 і011001100 і 704 і0000001001011і
і 768 і011001101 і 768 і0000001001100і
і 832 і011010010 і 832 і0000001001101і
і 896 і011010011 і 896 і0000001110010і
і 960 і011010100 і 960 і0000001110011і
і1024 і011010101 і1024 і0000001110100і
і1088 і011010110 і1088 і0000001110101і
і1152 і011010111 і1152 і0000001110110і
і1216 і011011000 і1216 і0000001110111і
і1280 і011011001 і1280 і0000001010010і
і1344 і011011010 і1344 і0000001010011і
і1408 і011011011 і1408 і0000001010100і
і1472 і010011000 і1472 і0000001010101і
і1536 і010011001 і1536 і0000001011010і
і1600 і010011010 і1600 і0000001011011і
і1664 і011000 і1664 і0000001100100і
і1728 і010011011 і1728 і0000001100101і
і EOL і000000000001і EOL і000000000001 і
А——————Б————————————Б——————Б—————————————Щ
.
- 47 -
Дополнительные образующие коды
Ъ——————В————————————ї
іДлина іКодовое і
ічернойіслово і
іили і і
ібелой і і
ісерии і і
Г——————Е————————————ґ
і 1792 і00000001000 і
і 1856 і00000001100 і
і 1920 і00000001101 і
і 1984 і000000010010і
і 2048 і000000010011і
і 2112 і000000010100і
і 2176 і000000010101і
і 2240 і000000010110і
і 2304 і000000010111і
і 2368 і000000011100і
і 2432 і000000011101і
і 2496 і000000011110і
і 2560 і000000011111і
А——————Б————————————Щ
.
- 48 -
Приложение 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 повторяющихся байта в
серию с повторением за исключением тех случаев, когда им
предшествует или следует за ними серия неповторяющихся байтов.
Тогда лучше слить три байта в серию без повторений. Три
повторяющихся байта всегда кодируются как серия с повторением.
.
- 49 -
Вот и весь алгоритм. Но для него действуют следующие правила:
1. Каждая строка должна упаковаться отдельно. При сжатии
недопустим переход через границу строк.
2. Число несжатых байтов в строке по определению равно (ImageWidth
+ 7)/8. Если для распакованного изображения требуется четное
число байтов в строке, проводите распаковку в буфер,
выровненный на границу слова.
3. Если длина серии больше 128 байтов, просто кодируйте остаток
серии как одну или несколько дополнительных серий с
повторением.
После распаковки данных PackBits результат следует
интерпретировать как сжатие типа 1.
.
- 50 -
Приложение D
————————————
Приложение D исключено. Раньше оно содержало рекомендации для
передачи TIFF-файлов в Microsoft Windows Clipboard. Это получило
негативную оценку, поскольку приводит к увеличению размеров
просканированных изображений. Вместо этого рекомендуются
программы, использующие обмен данных TIFF на основе файлов.
Например, PageMaker фирмы Aldus снабжен командой "File Place",
которая позволяет импортировать TIFF-файлы.
.
- 51 -
Приложение 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
.
- 52 -
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
.
- 53 -
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
.
- 54 -
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
.
- 55 -
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
.
- 56 -
ColorMap
Tag = 320 (140h)
Type = SHORT
Length = 3 * (2**BitsPerSample)
.
- 57 -
Приложение 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. Уровень сложности реализации должен быть приемлемым. Таковым мы
считаем то, что можно реализовать не более, чем за пару недель
.
- 58 -
силами квалифицированного программиста и нескольких экспертов
по обработке изображений. Объем откомпилированного кода для
сжатия и раскрытия в сумме не должен превышать 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 бит. Эта таблица трансляции является
уникальной для каждой полосы, но важно то, что ее не нужно
сохранять для раскрытия данных. Фокус в том, что при раскрытии
.
- 59 -
данных автоматически строится точно такая же таблица, которая была
построена при сжатии данных. Для описания схемы сжатия
воспользуемся псевдо кодом, похожим на язык 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 процентов лучше. Кроме
того, проще написать программу сжатия, которая всегда использует
символы одинаковой глубины, чем писать аналогичную программу,
которая поддерживает символы разной глубины.)
Теперь мы может описать некоторые программы и переменные, на
которые присутствуют ссылки в нашем псевдо коде:
.
- 60 -
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>)?
Нет, и поэтому нам нужно выполнить некоторые действия. Мы запишем
.
- 61 -
код, соответствующий 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.
Продолжая, мы получим следующие результаты:
Ъ————————————В—————————В——————————————————————ї
іПосле чтенияі Выводим і Записываем в таблицу і
Г————————————Е—————————Е——————————————————————ґ
іПиксел 0 і і і
іПиксел 1 і <7> і 258: <7><7> і
іПиксел 2 і і і
іПиксел 3 і <258> і 259: <7><7><8> і
іПиксел 4 і <8> і 260: <8><8> і
іПиксел 5 і <8> і 261: <8><7> і
іПиксел 6 і і і
іПиксел 7 і <258> і 262: <7><7><6> і
іПиксел 8 і <6> і 263: <6><6> і
А————————————Б—————————Б——————————————————————Щ
Программа WriteCode() также требует некоторых пояснений. Поток
выходных кодов (в нашем примере это - <7><258><8><8><258><6>...)
должен быть записан с использованием по возможности меньшего числа
битов. Когда мы начинали вывод, мы могли использовать 9-битные
коды, поскольку наши новые элементы таблицы имеют коды большие 255
но меньшие 512. Но когда мы добавим в таблицу элемент 512, мы
должны переключиться на 10-битные коды. Аналогично, мы
переключаемся на 11-битные коды при 1024 и 12-битные при 2048. Мы
сами наложили несколько произвольное ограничение в 12 битов, и
поэтому наша таблица может содержать до 4096 элементов. Если мы
положим его большим, то таблица будет иметь тенденцию к росту.
Что произойдет, если мы выйдем за пределы нашей таблицы цепочек?
Для этого существует упомянутый выше код очистки. Как только мы
используем элемент 4094, мы выводим в выходной поток (12-битный)
код очистки. (Если мы подождем чуть дольше перед выводом кода
очистки, то программа распаковки данных будет пытаться
.
- 62 -
интерпретировать код очистки как 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;
}
.
- 63 -
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, в
зависимости от изображения. Мы настояли, чтобы поставщики
изображений удалили по возможности как можно больше шума.
Предварительные тесты показали, что для изображений с пониженным
уровнем шума возможно значительное улучшение коэффициента сжатия.
Даже такой простой способ, как обнуление одного или двух битов во
всех плоскостях может быть достаточно эффективен и почти не влияет
на само изображение.
.
- 64 -
Реализация
Структура таблицы цепочек и метод, используемый для определения
того, что цепочка уже помещена в таблицу, являются, пожалуй,
наиболее значительными конструктивными решениями при реализации
LZW-сжатия и раскрытия. При сжатии полезным методом может
оказаться хеширование. Мы выбрали метод, основанный на деревьях и
он дал хорошие результаты. Раскрытие является более простым и
быстрым, поскольку оно не содержит поиска, и доступ к цепочкам
может осуществляться по значениям их кодов.
Быстродействие
Многие не представляют себе, что быстродействие любой схемы сжатия
сильно зависит от типа данных, для которых она используется.
Схемы, которые хорошо работают с одними данными, могут оказаться
плохи для других.
Поскольку мы не хотим обременять мир слишком большим набором схем
сжатия, то желательно применение адаптивных схем типа LZW, которые
работают вполне прилично с широким диапазоном изображений.
Возможно, LZW не всегда дает оптимальный коэффициент сжатия,
однако его адаптивная природа и относительная простота делают этот
выбор удачным.
Многочисленные эксперименты показывают, что коэффициент сжатия LZW
для непрерывных серых тоновых изображений колеблется обычно от
3.0-1.5 к 1. Если обнулить один или два младших битовых слоя в
8-битных данных, то может быть достигнута более высокая степень
сжатия. Эти битовые слои очень часто содержат главным образом шум,
и в этом случае почти не происходит потери качества изображения.
Палитровые цветные изображения, создаваемые с помощью графических
редакторов, обычно сжимаются намного лучше, чем просканированные
изображения с непрерывными тонами, поскольку имеют большую
тенденцию к повторяемости. Нет ничего необычного в достижении для
таких изображений коэффициента сжатия 10 к 1 или даже лучше.
Для сравнения: схема PackBits, используемая в TIFF для черно-белых
двухуровневых изображений, дает плохие результаты для цветных
изображений, созданных с помощью графических редакторов, и еще
хуже для серых и цветных изображений с непрерывными тонами.
Представляется, что средний коэффициент сжатия составляет порядка
1.2 к 1 для 4-битных изображений и еще хуже для 8-битных.
Предполагается, что одномерная схема CCITT не может применяться
для непрерывных тоновых изображений с использованием независимого
сжатия каждого битового слоя. Нет сомнений, что такая схема может
быть построена. Однако сомнительно, чтобы схема, основанная на
фиксированной таблице, которая оптимизировалась для коротких
черных серий, разделенных длинными белыми, была бы хорошим выбором
для любого битового слоя. Она должна быть очень хороша для
битовых слоев старших порядков (но для для них проще использовать
схему PackBits), но очень плоха для младших слоев. Мы думаем, что
.
- 65 -
коэффициент сжатия окажется не особенно впечатляющим и, кроме
того, процесс будет значительно медленнее. Разбиение пикселов по
слоям с последующей их сборкой обратно в пикселы довольно дорог, и
его код очень медленный при реализации на программном уровне.
Еще одним методом, который можно было бы рассмотреть, является
двумерное дифференцирование с последующим кодированием разностей с
помощью фиксированной таблицы кодов переменной длины. Схемы
такого типа очень хорошо срабатывают для 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 для
двухуровневых изображений.
.
- 66 -
Будущие расширения 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-метода.
.
- 67 -
Приложение G: Классы TIFF
—————————————————————————
Разумность
TIFF был разработан с целью облегчения жизни для производителей
сканеров, разработчиков издательских систем и пользователей
продуктов этого класса за счет снижения многообразия форматов
просканированных изображений. И он вполне оправдал наши ожидания в
этом отношении. Но мы ожидали, что он будет интересен не только
для дюжины (или около того) производителей сканеров (их не стало
намного больше по сравнению с 1985 годом) и другой дюжины (или
около того) производителей настольных издательских систем. Это
было бы большой недооценкой. Единственной проблемой, связанной с
достижением успеха в этой области является то, что TIFF
разрабатывался как мощный и гибкий формат, а это привело к
некоторому усложнению. Такое обстоятельство порождает
многочисленные попытки поддержки всех опций, определенных в этой
спецификации (вероятно, нет программ которые действительно
нуждались бы в столь сложной работе), и в настоящее время это
является единственным способом, гарантирующим, что вы сможете
импортировать любое TIFF-изображение, поскольку программ,
генерирующих изображения сейчас довольно много.
Поэтому здесь мы приводим попытку ввести гибкость TIFF в несколько
более ограниченные рамки, используя ту информацию о полезности
опций, которую мы получили в результате двухлетнего изучения.
Такое предприятие конечно же сопряжено с принятием многочисленных
произвольных решений. Но его результатом будет являться то, что
программам записи будет легче создавать файлы, которые успешно
понимались бы многочисленными программами чтения, а программы
чтения могут узнать, когда они могут прекратить добавлять
возможности TIFF.
Цена, которую мы платим за классы TIFF заключается в некоторой
потере способности к адаптации. Как только мы установили
требования для класса TIFF, мы никогда не сможем добавить новое.
(Лучшее, что мы можем сделать, это ввести новый класс. Но проблема
состоит в том, что очень скоро мы имели бы слишком много классов).
Поэтому мы должны поверить, что мы знаем, что мы делаем, при
установке этих классов. Если это не так, то любая ошибка будет
очень дорогой.
Обзор
Определим четыре класса TIFF:
Класс B для двухуровневых (1-битных) изображений
Класс G для серых изображений
Класс P для цветных палитровых изображений
Класс R для полностью цветных RGB-изображений
.
- 68 -
Чтобы сэкономить время и место, мы будем обычно говорить 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 (также, как и между другими)
происходит удивительно часто. Мы могли бы заставить программы
записи использовать одинаковый порядок байтов, но заранее
очевидно, что это вызовет проблемы, как только мы начнем
.
- 69 -
рассматривать более, чем 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 не обязаны читать произвольно большие изображения.
.
- 70 -
Некоторые программы чтения могут прерывать обработку, если все
изображение не удается разместить в доступной памяти (В таких
случаях программа чтения должна информировать пользователя о
существе проблемы). Другие, возможно, будут не в состоянии
поддерживать изображения, для которых 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.
.
- 71 -
Класс 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 изображения
—————————————————————————
Смещение Название Значение (как правило,16-ное)
(16-ное)
Заголовок:
0000 Byte Order 4D4D
0002 Version 002A
0004 IFD pointer 1 00000014
IFD:
0014 Entry Count 000D
0016 NewSubfileType 00FE 0004 00000001 00000000
0022 ImageWidth 0100 0004 00000001 000007D0
002E ImageLength 0101 0004 00000001 00000BB8
003A Compression 0103 0003 00000001 8005 0000
0046 Photometric 0106 0003 00000001 0001 0000
Interpretation
0052 StripOffsets 0111 0004 000000BC 000000B6
005E RowsPerStrip 0116 0004 00000001 00000010
006A StripByteCounts 0117 0003 000000BC 000003A6
0076 XResolution 011A 0005 00000001 00000696
0082 YResolution 011B 0005 00000001 0000069E
008E Software 0131 0002 0000000E 000006A6
009A DateTime 0132 0002 00000014 000006B6
00A6 Сл. IFD pointer 00000000
.
- 72 -
Поля, на которые есть ссылки в тегах:
00B6 StripOffsets Offset0, Offset1, ... Offset187
03A6 StripByteCounts Count0, Count1, ... Count187
0696 XResolution 0000012C 00000001
069E YResolution 0000012C 00000001
06A6 Software "PageMaker 3.0"
06B6 DateTime "1988:02:18 13:59:59"
Данные изображения:
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.
.
- 73 -
Класс 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.
Отметим, что двухуровневые и серые изображения являются частным
случаем цветных палитровых изображений. Как только вы напишите
достаточно общие прикладные программы для цветных палитровых
изображений, вы, возможно, пожелаете перестать различать
двухуровневые, серые и цветные палитровые изображения.
.
- 74 -
Класс 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, вам
следует написать об этом в листе спецификаций.
.
- 75 -
Приложение 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 является стандартом общего назначения для описания данных
типа изображений. Было бы глупо изменять его таким образом, чтобы
он не соответствовал существующим промышленным и международным
стандартам. Поэтому приведенное ниже обсуждение отражает
мучительные попытки удовлетворить стандартам различных организаций
и выбрать умолчания при работе с этими организациями.
.
- 76 -
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].
.
- 77 -
Цель цветометрических данных состоит в том, чтобы позволить
выполнить переход от основных составляющих цвета и белой точки к
основным составляющим и белой точке устройства визуализации. Гамма
отражает нелинейный перевод градиента реальных устройств.
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. Это позволяет системам визуализации
компенсировать такие различия.
.
- 78 -
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:
.
- 79 -
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, если это нужно.
В приведенных выше примерах предполагалось, что характеристики
отклика исходной системы и системы-получателя адекватно
аппроксимируются единственным параметром гамма. Обычно это верно,
но использование таблицы вместо одного параметра гамма придает
гибкость для описания более сложных отношений, без дополнительных
вычислений и усложнения.
.
- 80 -
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.
.
- 81 -
IX. Умолчания
Значения по умолчанию, используемые в TIFF отвечают промышленным
стандартам. Теги WhitePoint и PrimaryChromaticities имеют значения
по умолчанию, отвечающие стандарту SMPTE. Кроме того, значение по
умолчание для тега ColorResponseCurves соответствует спецификации
NTSC для гамма 2.2.
Цель этих умолчаний состоит в том, чтобы допустить получение
приемлемых результатов при отсутствии точной цветометрической
информации. Некалиброванные сканеры и устройства отображения
порождают изображения, которые всегда высвечиваются идентично,
хотя, возможно, некорректно на двух других, но калиброванных
системах. Это лучше чем неопределенность ситуации, когда
изображения могли бы высвечиваться по разному на двух разных, но
калиброванных системах.
X. Ограничения и следствия
В этом разделе обсуждаются некоторые ограничения и следствия,
относящиеся к цветометрической визуализации.
Область применения
Для многих целей в рекомендуемых здесь данных нет необходимости, и
они могут быть опущены. Для представления графики, где
используются всего несколько цветов, и достаточно того, что
красный цвет отличен от зеленого, они не нужны. В этом случае
данные теги можно игнорировать. В более сложных средах
представления цветных репродукций эти данные позволяют при малых
затратах описывать изображения в аппаратно-независимой форме.
Бремя для пользователя
Данные, которые мы рекомендуем, не являются бременем для
пользователя; в действительности они предназначены для систем. Они
допускают системные решения без вмешательства пользователя.
Однако, калибровка, является отдельным следствием; и ее нельзя
выполнить без вмешательства пользователя.
Разрешение против четкости
Некоторые производители предусматривают в своих цветовых
спецификациях глубину цветового разрешения более 24 бит. Целью
этого является либо устранение искусственных помех, типа
горизонтальных теней, либо более точное и аппаратно-независимое
описание цвета. Обе эти причины могут быть устранены. Другим,
менее дорогим методом устранения помех, является применение
палитры с большой глубиной. С точки зрения точности, четкость
более важна, чем цветовое разрешение.
.
- 82 -
Цветометрическое цветовое воспроизведение
Существуют другие возможности выбора критерия для цветового
воспроизведения [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].
.
- 83 -
[1] Color Data Interchange Paradigm, Eastman Kodak, Rochester,
New York, 7 December 1987.
[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., New York, New York, 1982.
[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, New York, New York, 1985.
.
- 84 -
Приложение 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;
.
- 85 -
/* вычисление горизонтальных разностей */
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 было одинаковым для всех трех компонент.
.
- 86 -
Результаты и следствия
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), но этого не случилось.
Между прочим, мы пытались использовать и вертикальное и
горизонтальное дифференцирование, но дополнительная сложность
двумерного дифференцирования не окупается для большинства наших
тестовых изображений. Приблизительно одна треть изображений
сжималась несколько лучше, еще треть несколько хуже, а остальные
дают те же результаты.
.
- 87 -
Приложение J: Цветные палитровые изображения
————————————————————————————————————————————
Это приложение, написанное после реализации редакции TIFF 5.0, мы
приводим в черновой форме. Пожалуйста присылайте любые комментарии
в Developers Desk.
Редакция 5.0 спецификации TIFF определила новое значение тега
PhotometricInterpretation, названное "цвета с палитрой" (palette
color). Ранее нас удивило, что эта дополнительная сложность может
представлять ценность с точки зрения реализации. Если нет, давайте
удалим ее до того, как многие пользователи начнут создавать
цветные палитровые изображения.
Предложение
Исключить отдельный тип данных для цветных палитровых изображений,
поскольку мы не видим побудительных причин, которые не позволяли
бы запоминать цветные палитровые изображения как полностью
цветные (обычно 24-битовые) RGB-изображения.
Возражения
Наиболее очевидное возражение состоит в числе требуемых цветов. Но
если вас заботит как много места займет ваше изображение на диске,
вам следует использовать LZW-сжатие, которое идеально подходит для
большинства цветовых палитровых изображений (LZW сжимает
большинство палитровых изображений с коэффициентом сжатия 5:1 и
выше). И, если вы используете LZW-сжатие, то это исключает цветные
палитровые изображения, поскольку такие изображения, запомненные
как полностью цветные RGB-изображения, сжимаются почти до такого
же размера, как если бы они запоминались в палитровом виде. Таким
образом, при использовании LZW-сжатия отсутствует плата за
запоминание палитровых изображений в RGB-виде. Получаемый файл
может быть больше на несколько процентов, но он не будет больше в
три раза. Для получения более подробной информации о работе LZW
см. Приложение F.
Другим возражением могло бы быть то, что некоторые программы
хотели бы обрабатывать изображения иначе, если таковые
действительно являются цветовыми палитровыми изображениями. Но вы
можете легко добавить вспомогательную информацию, которая поможет
программе чтения быстро распознать категорию цветного изображения,
если она того захочет. См. приведенный ниже раздел "Новые теги".
.
- 88 -
Преимущества
Они очевидны, но возможно стоит обсудить, почему мы хотели бы
удалить цветные палитровые изображения, как четко выделяющийся
класс.
Главная проблема состоит в том, что наличие отдельного типа для
цветных палитровых изображений вносит в жизнь пользователей
опасность и беспорядок. Фактор беспорядка усиливается, поскольку
пользователи частично лишаются представлений о различии между
двухуровневыми, серыми и цветными палитровыми изображениями.
Наличие двух типов цветных изображений тяжело объяснить многим
пользователям, и, пожалуй, невозможно в некоторых ситуациях скрыть
от пользователя связанные с этим сложности. Уровень риска
возрастает потому, что некоторые программы могут принимать
палитровые изображения, но не принимать полностью цветных, или
наоборот, или принимать 8-битные палитровые, но не 4 или 3-битные.
Вторая проблема состоит в том, что написание и поддержка кода для
работы с дополнительным типом изображений является несколько
накладной для программ чтения TIFF. Стоимость поддержки цветных
палитровых изображений зависит от задачи, но мы полагаем, что в
общем случае она будет значительна. Представляется, что имеет
смысл возложить бремя конвертирования цветных палитровых
изображений в полностью цветные на программы записи TIFF, чем
заставлять программы чтения поддерживать дополнительный тип
изображения, поскольку в настоящее время программ чтения TIFF
гораздо больше, чем программ записи.
Новые теги
Здесь мы предлагаем новые теги, которые помогут классифицировать
цветные изображения и позволят отказаться от наличия отдельного
класса для цветных палитровых изображений. Они не обязательны для
класса TIFF R , но настоятельно рекомендуются для цветных
изображений, создаваемых с помощью графических редакторов,
использующих палитры.
ColorImageType
Tag = 318 (13Eh)
Type = SHORT
Length = 1
Снабжает программы чтения TIFF скорее идеей о том какого типа
данное цветное изображение. Содержит ограниченный набор случаев.
ColorImageType=1
Реалистическое изображение с непрерывными тонами.
.
- 89 -
ColorImageType=2
Синтетическое изображение с использованием строго
ограниченного набора цветов. Такие изображения порождаются
большинством графических редакторов. Для получения списка
используемых цветов см. тег ColorList.
По умолчание принимается 1.
ColorList
Tag = 319 (13Fh)
Type = BYTE или SHORT
Length = число цветов, используемых в изображении, умноженное
на SamplesPerPixel
Список цветов, которые используются в изображении. Использование
этого поля практикуется только для изображений с сильно
ограниченным (обычно меньшим или равным 256) числом цветов. Тег
ColorImageType должен быть равен 2. См. тег ColorImageType.
Список организован как массив троек RGB без выравнивания. Для
троек RGB не гарантирован какой либо порядок. Отметим, что
компоненты красного, зеленого и синего могут иметь типы BYTE или
SHORT. Для большинства задач должно быть достаточно типа BYTE.
Нет умолчаний.
Авторы проекта |
|
