Также известен как: Portable Network Graphics Format
Тип | Растровый |
Цвета | От 1-бита до 48-бит |
Сжатие | Разновидность LZ77 |
Максимальный размер изображения | 2Г x 2Г пикселей |
Формат чисел | "Старший в младшем" |
Больше одного изображения в файле | Нет |
Разработчик | Томас Бутелл, Том Лейн и многие другие |
Платформы | Все |
Поддерживается приложениями | Многими коммерческими пакетами и бесплатными пакетами с коммерческой лицензией |
См. также | GIF |
Комментарии:
Формат PNG хорошо продуман и разработан, и скорее всего он заменит формат GIF
от фирмы CompuServe.
PNG (произносится "Пинг") - растровый формат, предназначенный для хранения и передачи растровых изображений: черно-белых и альфа данных - до 16 бит, а цветных - до 48 бит (truecolor). Он использует прогрессивный метод сжатия без потерь, позволяет сохранять в файле палитру, текстовую информацию и обеспечивает прозрачность.
Содержание:
Организация файла
Детальное описание
Дополнительная информация
Формат PNG создан, как альтернатива формату GIF от CompuServe, потому что фирма CompuServe, владея правами на этот формат, запрещало свободное использование метода сжатия LZW (сжатие, используемое в GIF - файле) в программных продуктах. (См. статьи на тему юридических аспектов метода сжатия LZW в Главе 9, Сжатие Данных.) В шутку аббревиатуру PNG рекурсивно расшифровывают - "PNG's Not GIF" ("ПНГ - Не ГИФ").
PNG создавался как простой и легко распространяемый формат, содержащий в себе все преимущества формата GIF, абсолютно бесплатный и без всяких лицензионных прав и разногласий.
PNG и GIF89a обладают следующими свойствами:
Ниже перечислены преимущества PNG над GIF в общих чертах:
А следующие возможности PNG в формате GIF вообще отсутствуют:
Но, всё же, некоторые особенности GIF не найдены в PNG версии 1.0:
В отличие от многих других форматов, создатели которых (2-3 программиста) не заботятся о дальнейшем его развитии, PNG был создан особым комитетом, в состав которого вошли заинтересованные в этом специалисты и противники GIF (в список авторов спецификации PNG версии 1.0 вошли 23 фамилии) во главе с Томасом Бутеллом.
PNG считается одним из лучших форматов, так как позволяет дополнять формат возможностями, не нарушая его функциональности и не требуя изменения уже существующих программных пакетов, работающих с форматом PNG, а спецификация формата является наиболее полной и понятной.
PNG файл или поток данных состоит из 8-байтовой опознавательной подписи, за которой следуют 3 или более независимых блоков данных, соответствующих определённой структуре. Каждый блок имеет своё собственное определение внутреннего формата. Они читаются по очереди, от начала к концу файла или потока данных.
Некоторые другие форматы также используют структуру из блоков данных. Наиболее известные среди них: GIF, IFF и RIFF. Данные в этих форматах читаются от начала к концу. Это избавляет от надобности прыгать по файлу, используя начальную адресацию. Это также позволяет без проблем использовать эти форматы с сетевыми протоколами и протоколами передачи данных. Несмотря на то, что эти форматы обычно описываются, как форматы файлов, более точным определением будет поток данных, сохранённый в файле.
В формате PNG определено 4 типа стандартных блоков, иначе именуемых критические блоки, которые должны поддерживаться любой программой чтения и записи PNG. Далее следует перечень этих блоков:
Заголовочный блок содержит основную информацию о данных изображения и должен быть первым блоком в потоке данных PNG (не допускается более одного заголовочного блока).
Палитра несёт в себе данные таблицы цветов, связанный с данными изображения. Этот блок присутствует только если данные изображения используют палитру и должен находиться перед этими данными.
Блок данных изображения содержит в себе само изображение, и допускается несколько таких блоков в потоке данных, причём все они должны вплотную примыкать друг к другу.
Замыкающий блок изображения должен находиться в конце файла или потока данных PNG.
Среди этих блоков, IHDR, IDAT и IEND должны присутствовать в любом потоке данных PNG.
Рассмотрим 2 типичных вида PNG файлов: один с цветовой палитрой, один без.
Подпись |
Блок IHDR |
Блок IDAT |
Блок IEND |
Подпись |
Блок IHDR |
Блок PLTE |
Блок IDAT |
Блок IEND |
Как видите, разница межу 2 типичными форматами PNG лишь в наличии блока с палитрой.
Необязательные блоки, именуемые вспомогательные блоки, могут быть игнорированы программой чтения и необязательны для включения в файл программами записи PNG файлов. Тем не менее, отсутствие поддержки вспомогательных блоков может сказаться на непрвальном отображении изображения PNG. Оно может быть слишком затемнённым, слишком светлым или вообще отображаться в совершенно другом виде, не задуманном создателем этого изображения. Рекомендуется поддержка и использование большинства стандартных и вспомогательных блоков (в частности, блока Контрастности Изображения) программами, работающими с PNG.
Вместе критические и вспомогательные блоки, определённые в спецификации PNG, соответствуют термину стандартные блоки. Люди, создающие разные спецификации PNG, ведут список дополнительных блоков, именуемых иначе специальные блоки, подлежащие огласке. Эти блоки имеют специальное применение и используются гораздо реже стандартных блоков. Список этих специальных блоков время от времени должен обновляться. Некоторые приложения могут создавать частные, закрытые для общего доступа блоки для данных, которые не должны читаться другими приложениями.
Ниже вкратце описаны все стандартные и специальные блоки, объявленные в издании 1.0 спецификации PNG и связанной с ней документации. Блоки распределены в относительном (но не единственно возможном) порядке, в котором они могут быть организованы в потоке данных PNG.
Тип блока | Многократный | Необязательный | Положение в файле |
---|---|---|---|
IHDR |
Нет |
Нет |
Первый блок |
cHRM |
Нет |
Да |
Перед PLTE и IDAT |
gAMA |
Нет |
Да |
Перед PLTE и IDAT |
sBIT |
Нет |
Да |
Перед PLTE и IDAT |
PLTE |
Нет |
Да |
Перед IDAT |
bKGD |
Нет |
Да |
После PLTE и перед IDAT |
hIST |
Нет |
Да |
После PLTE и перед IDAT |
tRNS |
Нет |
Да |
После PLTE и перед IDAT |
oFFs |
Нет |
Да |
Перед IDAT |
pHYs |
Нет |
Да |
Перед IDAT |
sCAL |
Нет |
Да |
Перед IDAT |
IDAT |
Да |
Нет |
Вместе с остальными блоками IDAT |
tIME |
Нет |
Да |
В любом месте |
tEXt |
Да |
Да |
В любом месте |
zTXt |
Да |
Да |
В любом месте |
fRAc |
Да |
Да |
В любом месте |
gIFg |
Да |
Да |
В любом месте |
gIFt |
Да |
Да |
В любом месте |
gIFx |
Да |
Да |
В любом месте |
IEND |
Нет |
Нет |
Последний блок |
Подпись PNG длиной в 8 байт содержит информацию для определения файла или потока данных, в согласии со спецификацией PNG.
typedef struct _PngSignature { BYTE Signature[8]; /* Идентификатор (всегда 89504E470D0A1A0Ah) */ } PNGSIGNATURE;
Подпись содержит 8 байт со значениями: 89h 50h 4Eh 47h 0Dh 0Ah 1Ah 0Ah ("‰PNG\r\n\n"). Эта на вид беспорядочная последовательность значений имеет довольно много практических назначений. Значение первого байта - 89h - 8-битовое значение, указывающее на то, что файл содержит двоичные данные. Если бы каждый 8-й бит был бы вырван из файла (7-битовый канал данных), то первый байт принял бы значение 09h, что указало бы на причину, по которой испорчен файл.
Остальные байты имеют следующее назначение:
После подписи следуют 3 или более блоков данных PNG. Все блоки PNG имеют одинаковый основной формат и могут содержать переменное количество данных.
typedef struct _PngChunk { DWORD DataLength; /* Размер поля данных в байтах */ DWORD Type; /* Код, идентифицирующий тип блока */ BYTE Data[]; /* Собственно данные, хранящиеся в блоке */ DWORD Crc; /* CRC-32 значение полей Type и Data */ } PNGCHUNK;
DataLength - число байтов в поле Data. Это значение может варьироваться от 0 до 231-1.
Type - 4-х байтовый код, идентифицирующий тип хранящихся данных в блоке. Каждый байт в этом поле может содержать значение заглавного или прописного латинского символа таблицы ASCII (A-Z, a-z). На пример, тип блока IHDR будет выражен значением 69484452h в поле Type. Программа чтения PNG должна рассматривать коды Type как 32-битовые буквенные значения, не являющиеся символьными строками. Возможность чтения кодов типов как символов таблицы ASCII существует лишь для удобства человеку.
Поле Data - собственно данные, хранящиеся в блоке. Это поле может иметь нулевую длину, если не существует связанных с ним данных.
Crc - CRC-32 значение, просчитываемое для полей Type и Data. Это значение используется для определения, являются ли данные повреждёнными. В PNG используется алгоритм CRC, определённый в ISO 3309 и ITU-T V.42.
Блоки бывают размером от 12 байт (не содержат данных) до (231-1)+12 байт. Блоки всегда выравниваются по границам байтов, и поэтому никогда не требуется выравнивание заполнением.
Этот раздел описывает стандартные блоки, которые должны поддерживаться любой программой чтения и записи PNG.
Заголовочный блок содержит информацию о данных изображения в PNG файле. Этот блок должен быть первым блоком в потоке данных PNG и следует непосредственно за подписью PNG. Область данных заголовочного блока составляет 13 байт и имеет следующий формат:
typedef struct _IHDRChunk { DWORD Width; /* Ширина изображения в пикселях */ DWORD Height; /* Высота изображения в пикселях */ BYTE BitDepth; /* Количество битов на пиксель и образец */ BYTE ColorType; /* Индикатор интерпретации цвета */ BYTE Compression; /* Индикатор типа сжатия */ BYTE Filter; /* Индикатор типа фильтра */ BYTE Interlace; /* Тип использованной схемы чересстрочной развёртки */ } IHDRCHUNK;
Поля Width и Height - высота и ширина растрового изображения в пикселях. Принимают значения от 1 до 231-1.
BitDepth - количество битов на пиксель для изображений с индексированными цветами и количество битов на образец для чёрно-белых изображений и полноцветных изображений (24 бита). У индексированных изображений BitDepth может принимать значения 1, 2, 4 и 8. У чёрно-белых - 1, 2, 4, 8 и 16. У полноцветных изображений без альфа данных, а также у чёрно-белых изображений с альфа данными, BitDepth может принимать только значения 8 и 16.
ColorType определяет способ интерпретации данных изображения. Принимаемые значения (вид изображения): 0 (чёрно-белое), 2 (полноцветное), 3 (индексированное изображение), 4 (чёрно-белое с альфа данными) и 6 (полносветное с альфа данными).
Compression определяет вид сжатия данных изображения. В настоящее время единственное допустимое значение - 0, означающее, что использован метод сжатия Defalte. Другие методы сжатия будут определены в будущих добавлениях PNG.
Filter определяет вид фильтрования, применённый к данным изображения перед сжатием. На сегодняшний день, единственное допустимое значение - 0, означающее, что был применён метод фильтрования adaptive, описанный в спецификации PNG. Другие методы фильтрования будут определены в будущих добавлениях PNG. Значение поля filter не указывает, были ли данные изображения профильтрованы; на это указывает байт filter type в начале каждой строки развёртки. Данные изображения не обязательно должны быть профильтрованы перед сжатием.
Interlace определяет чересстрочный алгоритм, используемый для хранения данных изображения, или, если быть более точным, порядок передачи пиксельных данных. Принимаемые значения - 0 (нет чересстрочности) и 1 (чересстрочность Adam7).
Палитра (PLTE) всегда присутствует в потоках данных PNG, содержащих изображения с индексированными цветами (когда поле Color заголовочного блока имеет значение 3). Полноцветные потоки данных PNG (значения поля Color - 2 и 6) также могут содержать палитру, предназначенную для разбития данных изображения на подгруппы приложениями, не поддерживающими полноцветную палитру. Поток данных PNG не может содержать более одной палитры.
Палитра может быть размером от 3 до 768 байт и имеет следующий формат:
typedef struct _PLTEChunkEntry { BYTE Red; /* Красный компонент (0 = чёрный, 255 = максимум оттенка) */ BYTE Green; /* Зелёный компонент (0 = чёрный, 255 = максимум оттенка) */ BYTE Blue; /* Синий компонент (0 = чёрный, 255 = максимум оттенка) */ } PLTECHUNKENTRY; PLTECHUNKENTRY PLTEChunk[];
PLTEChunk - массив, содержащий от 1 до 256 элементов, каждый из которых содержит 3 поля: Red, Green и Blue, хранящие соответственно значения красного, зелёного и синего цветов для данного элемента палитры.
блок данных изображения (IDAT) содержит собственно данные изображения. В соответствии со спецификацией PNG эти данные всегда хранятся в сжатом виде. Данные изображения могут быть разбиты на несколько IDAT блоков, чтобы программе записи PNG было легче буферизировать сжатые данные изображения. У сжатого потока данных нет пределов, потому IDAT блок может быть в размере от 0 до 231-1 байт.
Последний блок потока данных PNG - замыкающий блок изображения (IEND). Этот блок не содержит никаких данных.
В PNG v1.0 определено 10 вспомогательных блоков, которые могут присутствовать в потоке данных PNG. Информация некоторых из этих блоков обеспечивает правильную интерпретацию данных изображения (например, Image Gamma - контрастность изображения). Краткое описание формата поля Data каждого их таких блоков приведено ниже. Полная информация об этих блоках содержится в спецификации формата PNG.
Блок Фонового Цвета определяет цвет фона изображения. Замечание: некоторые программы чтения PNG могут игнорировать этот блок и использовать цвет фона по их усмотрению.
Формат данных этого блока зависит от формата данных изображения, определяемого значением поля ColorType блок IHDR. Для изображений с индексированными цветами (ColorType = 3), данные длиной 1 байт содержат индекс цвета палитры, используемого в качестве фона.
typedef struct _bKGDChunkEntry { BYTE Index; /* Индекс цвета фона в палитре */ } BKGDCHUNKENTRY;
В чёрно-белых изображениях с данными или без данных альфа канала (ColorType = 0 или 4), блок цвета фона длиной 2 байта содержит уровень оттенка серого, используемого в качестве цвета фона.
typedef struct _bKGDChunkEntry { WORD Value; /* Значение уровня серого у фона */ } BKGDCHUNKENTRY;
У полноцветных изображений с данными или без данных альфа канала (ColorType = 2 и 6), блок цвета фона три 2-байтовых значений, определяющих цвет фона в формате RGB.
typedef struct _bKGDChunkEntry { WORD Red; /* Уровень красного в цвете фона */ WORD Green; /* Уровень зелёного в цвете фона */ WORD Blue; /* Уровень синего в цвете фона */ } BKGDCHUNKENTRY;
Блок Основных Цветов и Белой Точки содержит информацию о RGB значениях, основанных на 1931 CIE цветовом координатном пространстве XYZ. Определены цвета только по осям x и y, и они представлены в виде значений, помноженных на 100 000.
typedef struct _cHRMChunkEntry { DWORD WhitePointX; /* Значение Белой Точки по x */ DWORD WhitePointY; /* Значение Белой Точки по y */ DWORD RedX; /* Значение Красного по x */ DWORD RedY; /* Значение Красного по y */ DWORD GreenX; /* Значение Зелёного по x */ DWORD GreenY; /* Значение Зелёного по y */ DWORD BlueX; /* Значение Синего по x */ DWORD BlueY; /* Значение Синего по y */ } CHRMCHUNKENTRY;
Блок контрастности изображения содержит значение изначальной контрастности в соответствии с изначальным изображением. Это значение - контрастность, помноженная на 100 000. Замечание: настоятельно рекомендуется авторами PNG обрабатывать блок контрастности.
typedef struct _gAMAChunkEntry { DWORD Gamma; /* Значение контрастности */ } GAMACHUNKENTRY;
Блок Гистограммы изображения содержит данные о приблизительной частоте использования каждого цвета в палитре. Этот блок содержит массив 2-байтовых элементов, по одному на каждый элемент палитры.
typedef struct _hISTChunkEntry { WORD Histogram[]; /* Данные гистограммы */ } HISTCHUNKENTRY;
Блок Фактического Размера в Пикселях определяет разрешение, предназначенное для отображения изображения.
typedef struct _pHYsChunkEntry { DWORD PixelsPerUnitX; /* Пикселей на единицу измерения, ось X */ DWORD PixelsPerUnitY; /* Пикселей на единицу измерения, ось X */ BYTE UnitSpecifier; /* 0 = неизвестная, 1 = метрическая единица измерения */ } PHYSCHUNKENTRY;
Блок Значимых Битов определяет битовую глубину данных изображения. Если программе записи PNG необходимо сохранить данные изображения с неподдерживаемой битовой глубиной, данные нужно дополнить до следующей ближайшей поддерживаемой битовой глубины. Например, стобы сохранить RGB данные с разрешением 5 бит на пиксель в формате PNG (RGB555), данные изображения необходимо дополнить до 8-битовой глубины (RGB888). Блок значимых битов будет содержать битовую глубину изначальных данных.
Формат данных этого блока может быть 4 разных видов в зависимости от данных изображения, определённых в поле ColorType блока IHDR:
/* Чёрно-белое изображение (ColorType = 0) */ typedef struct _sBITChunkEntry { BYTE GrayscaleBits; /* Значимые биты чёрно-белого изображения (ColorType 0) */ } SBITCHUNKENTRY;
/* Полноцветное изображение или изображение с индексированными цветами (ColorType = 2 или 3) */ typedef struct _sBITChunkEntry { BYTE RedBits; /* Значимые биты Красного */ BYTE GreenBits; /* Значимые биты Зелёного */ BYTE BlueBits; /* Значимые биты Синего */ } SBITCHUNKENTRY;
/* Чёрно-белое изображение с данными альфа канала (ColorType = 4) */ typedef struct _sBITChunkEntry { BYTE GrayscaleBits; /* Значимые биты чёрно-белых данных */ BYTE AlphaBits; /* Значимые биты альфа канала */ } SBITCHUNKENTRY;
/* Полноцветное изображение с данными альфа канала (ColorType = 6) */ typedef struct _sBITChunkEntry { BYTE RedBits; /* Значимые биты Красного */ BYTE GreenBits; /* Значимые биты Зелёного */ BYTE BlueBits; /* Значимые биты Синего */ BYTE AlphaBits; /* Значимые биты Альфа Канала */ } SBITCHUNKENTRY;
Блок Текстовых Данных обычно используется для хранения информации, предназначенной для чтения человеком, (как, например, название и автор изображения, уведомление об авторских правах и т.п.) хранящейся внутри PNG файла. Данные этого блока имеют следующий формат:
typedef struct _tEXtChunkEntry { char Keyword[]; /* Тип информации, содержащейся в поле Text */ BYTE NullSeparator; /* Нулевой разделительный символ (NULL) */ char Text[]; /* Текстовые данные */ } TEXTCHUNKENTRY;
Поле Keyword может быть размером от 1 до 79 байт и может содержать любые печатаемые символы кодовой страницы Latin-1 включая пробелы, кроме нулевого символа (NULL).
Поле NullSeparator - 1 байт со значением 0. Это поле разделяет поля Keyword и Text.
Поле Text - собственно символьные данные, хранящиеся в блоке. Длина этого символа определяется из значения поля DataLength в заголовке блока.
Значение поля Keyword содержит ключевые слова, связанные с данными поля Text. Ниже приведён список ключевых слов, содержащихся в поле Keyword в PNG 1.0:
Название |
Автор |
Описание |
Авторские права |
Время создания |
Программное обеспечение |
Отказ от права |
Предупреждение |
Исходник |
Комментарии |
Дополнительные ключевые слова могут быть объявлены через общедоступную регистрацию или могут создаваться отдельными приложениями.
Блок Времени Последнего Изменения Изображения содержит время последнего изменения изображения (а не время создания) и имеет следующий формат:
typedef struct tIMEChunkEntry { WORD Year; /* Значение года (например 1996) */ BYTE Month; /* Значение месяца (1-12) */ BYTE Day; /* Значение дня (1-31) */ BYTE Hour; /* Значение часа (0-23) */ BYTE Minute; /* Значение минуты (0-59) */ BYTE Second; /* Значение секунды (0-60) */ } TIMECHUNKENTRY;
Блок Прозрачности содержит значение прозрачного (ключевого) PNG изображения, не содержащего соответствующих альфа данных. Значения пикселей для полноцветных и чёрно-белых изображений, совпадающих с прозрачным цветом, считаются прозрачными (альфа значение - 0), остальные же считаются непрозрачными.
Изображения с индексированными цветами содержат массив альфа значений, максимум по одному на элемент палитры. Эти значения прозрачности обрабатываются абсолютно как альфа значения. Элементам палитры, не имеющим значений прозрачности, присваивается значение по умолчанию 255 (абсолютно непрозрачные).
Допустимы 3 формата данных в этом блоке, в зависимости от формата данных изображения, на которые указывает поле ColorType блока IHDR:
/* Чёрно-белое изображение (ColorType = 0) */ typedef struct _tRNSChunkEntry { WORD TransparencyValue; /* Цвет прозрачности */ } TRNSCHUNKENTRY;
/* Полноцветное изображение (ColorType = 2) */ typedef struct _tRNSChunkEntry { WORD RedTransValue; /* Красная составляющая цвета прозрачности */ WORD GreenTransValue; /* Зелёная составляющая цвета прозрачности */ WORD BlueTransValue; /* Синяя составляющая цвета прозрачности */ } TRNSCHUNKENTRY;
/* Изображение с индексированными цветами (ColorType = 3) */ typedef struct _tRNSChunkEntry { BYTE TransparencyValues[]; /* Цветы прозрачности */ } TRNSCHUNKENTRY;
Блок Сжатых Текстовых Данных используется для хранения больших по размеру текстовых данных в сжатом формате. Формат этого блока такой же, как и у блока текстовых данных, с тем лишь отличием, что поле Text содержит данные, сжатые методом Deflate, используемым в формате PNG для сжатия данных изображения.
Данные Изображения PNG представлены в растровом виде со строками развёртки, направленными слева направо и сверху вниз. Пиксели всегда уплотнены в этих строках и не дополняются битами для выравнивания границы байтов между пикселями. Пиксели размером менее 8 бит упакованы в байт крайнего левого пикселя, занимая наиболее значимые биты в байте.
Строки развёртки всегда начинаются на стыках байтов и всегда должны дополняться до ближайшего стыка байтов в конце. Перед каждой строкой развёртки также находится байт типа фильтра, который используется при сжатии и извлечении изображения. Этот байт определяет тип алгоритма фильтрования, использованного при обработке данной линии развёртки. Этот байт присутствует всегда, даже когда фильтрование не было применено.
Значения данных изображения глубиной цвета до 8 бит могут быть преобразованы в цветовую палитру либо сохранены в растровых данных в виде чёрно-белых значений. Полноцветные пиксели всегда хранятся в виде 3-х составляющих (красный, зелёный, синий соответственно). Также 4-я составляющая (Альфа канал) может быть включена в каждый полноцветный пиксель.
Чёрно-белые и цветные индексированные растровые изображения содержат по одной составляющей на пиксель, образуя односоставные пиксели. Каждая составляющая в изображении всегда одного и того же размера. Этот размер называется битовой глубиной, равной количеству битов в составляющей. Одиночная составляющая может быть глубиной от 1 до 16 битов. Для изображений с индексированными цветами, битовая глубина определяет максимальное количество цветов в палитре. Форматом PNG не определяется, но и не устраняется двухуровневое растровое отображение.
Многосоставные пиксели содержат 2 или более составляющих на пиксель. Эти составляющие могут быть 8 и 16 битовые, но все составляющие изображения должны быть одного и того же размера. Многосоставные пиксели могут быть от 16 до 64 битов.
Например, типичный чёрно-белый пиксель содержит одну составляющую. Типичный 24-битовый пиксель в формате RGB - три 8-битовых составляющих, а нетипичный 64-битовый пиксель в формате RGBA будет содержать 4 16-битовых пикселя. Обратите внимание, что односоставные и многосоставные пиксели, использующие отличные от 8- и 16-битовых составляющие, должны использовать составляющие ближайшей допустимой глубины. Например, для хранения 10-битовой составляющей, вы должны использовать 16-битовую. Неиспользуемые биты либо забиваются нолями (не рекомендовано для составляющих глубиной менее 8 бит, но для больших глубин забивание нолями позволит значительно улучшить сжатие), либо линейным увеличением масштаба заполняют диапазон допустимых значений (рекомендовано). Создатели PNG рекомендуют быстрый метод увеличения масштаба путём дублирования самых крайних слева значащих битов.
Чёрно-белые и полноцветные изображения глубиной от 8 до 16 битов также могут содержать не сопоставленные данные альфа канала, называемые альфа маской. Если используются данные альфа маски, каждый чёрно-белый или полноцветный пиксель содержит дополнительно значение альфа канала для данного пикселя. Изображения с индексированными цветами могут содержать альфа канал в блоке прозрачности.
Альфа значение определяет уровень прозрачности пикселя. Минимальное значение битовой глубины (всегда 0) указывает на абсолютную прозрачность, а максимальное значение либо отсутствие как таковое альфа маски указывает на полную непрозрачность.
Данные изображения PNG обычно хранятся в виде последовательности линий развёртки, начинающейся от первой строки вверху изображения и заканчивающейся последней строкой внизу изображения. Данные изображения PNG также могут храниться в специальной чересстрочной структуре для прогрессивного отображения этих данных от низкого полного разрешения.
Прогрессивное отображение очень удобно при получении PNG файла через медленный канал связи (например, канал, соединяющий ваш Web-браузер с Интернетом). Эффект постепенного прояснения обычно позволяет пользователю разглядеть изображение до его окончательного отображения. Это свойство очень полезно для изображений-меню на Web-странице или для изображения, нестоящего времени, затраченного на его загрузку.
Все программы чтения PNG должны интерпретировать чересстрочные данные изображения, хотя программе просмотра совсем не обязательно уметь осуществлять прогрессивное отображение.
Типичная чересстрочная схема, также используемая в формате GIF, просто реорганизует порядок хранения строк развёртки. Например, строки файла будут хранится не в последовательном порядке (0, 1, 2, 3, 4, 5, 6,...), а в чересстрочном (0, 8, 4, 9, 2, 10, 5,...). Формат GIF использует такую же чересстрочную схему, и данные сохраняются (или передаются) в 4 этапа: 1/8, 1/8, 1/4 и 1/2.
В PNG несколько иной подход: создание чересстрочного изображения в 7 этапов по схеме Adam7 (в честь создателя Адама М. Костелло). Первые 6 этапов в этой схеме предназначены для интерпретации всех чётных строк (0, 2, 4, 6,...), а последний 7-й для заполнения оставшихся нечётных сток (1, 3, 5, 7...).
Вместо того, чтобы содержать пиксели для всей строки, исходные 6 этапов содержат лишь некоторые определённые пиксели через строку. В первых 2 этапах содержится 1/64-я всех пикселей изображения, в 3-ем - 1/32-я, в 4-ом - 1/16-я, в 5-м - 1/8, в 6-м - 1/4, а в заключительном 7-м этапе - 1/2 данных изображения.
Изображение на экране постепенно создаётся сначала из квадратов 8x8, затем из прямоугольников 4x8, затем из квадратов 4x4, затем из прямоугольников 2x4, затем из квадратов 2x2 и затем из прямоугольников 1x2. В заключительном этапе заполняются все пиксели нечётных строк.
Чересстрочность Adam7 позволяет намного быстрее прогрессивно отображать пиксели на экране, чем если бы отображались полностью сроки развертки. Пиксели в изображении также расположены в более удобной для человеческого глаза схеме, позволяя разглядеть изображение после загрузки 20% - 30% данных этого изображения, в сравнении с 50% или более данных, необходимых для данных GIF.
Заметьте, что ценой за чересстрочную схему PNG будет размер данных, пропорционально влияющий и на скорость их передачи. Чересстрочная схема GIF просто реорганизует порядок хранения строк развёртки и не имеет значительного влияния на размер строки развертки. В схеме PNG, каждый этап, кроме последнего, содержит несмежные пиксели, например, 1-й этап содержит каждый 8-й пиксель с каждой 8-й строки.
В среднем эти пиксели менее связаны, чем соседние пиксели, поэтому сжатие менее эффективно на чересстрочных данных, чем на последовательных, а, следовательно, конечный файл обычно на 10% больше. В целях, при которых чересстрочность выгодна, излишний размер окупает себя в более быстром отображении изображения.
Чересстрочность Adam7 осуществляется по фильтровальной схеме, приведённой ниже. Несжатые данные PNG преобразуются в чересстрочные данные сперва путём наложения шаблона 8x8 на всё изображение. Затем данные 7 раз сканируются, и значения пикселей под шаблоном определяют значения пикселей, сохраняемых или передаваемых по сети во время каждого этапа.
1 |
6 |
4 |
6 |
2 |
6 |
4 |
6 |
7 |
7 |
7 |
7 |
7 |
7 |
7 |
7 |
5 |
6 |
5 |
6 |
5 |
6 |
5 |
6 |
7 |
7 |
7 |
7 |
7 |
7 |
7 |
7 |
3 |
6 |
4 |
6 |
3 |
6 |
4 |
6 |
7 |
7 |
7 |
7 |
7 |
7 |
7 |
7 |
5 |
6 |
5 |
6 |
5 |
6 |
5 |
6 |
7 |
7 |
7 |
7 |
7 |
7 |
7 |
7 |
Данные изображения PNG всегда хранятся в сжатом виде. Данные изображения сжимаются по методу, сходному методу Deflate, с применением предугадывания значений пикселей с последующим сжатием разности. Метод сжатия Deflate был создан Филом Катзом, и используется также в приложении архивации файлов pkzip. Этот метод сжатия без потерь является быстрым, хорошо документированным, бесплатно доступным и совместимым со многими платформами.
Метод Deflate - разновидность алгоритма сжатия LZ77, запатентованного (4,464,650) Лемпелом, Зивом, Кохеном и Истманом в 1981 году. Метод Deflate использует передвигающееся по данным окно переменного размера и случайным образом сортированные таблицы для распознавания структуры данных и сжатия их кодировкой Хаффмана. В PNG используется разновидность Deflate без случайных таблиц, и поэтому на него не влияют условия правовых притязаний и лицензионных соглашений.
Данные изображения могут быть оптимизированы перед сжатием. Фильтрование нормализует значения байтов в строках развёртки, позволяя алгоритму сжатия Deflate быть более эффективным и выдавать более сжатые данные.
Все алгоритмы фильтрования применяются к байтам в строках развёртки, а не к пикселям. При наличии любых данных альфа канала в данных строк развёртки они тоже фильтруются. А т.к. один алгоритм фильтрования не очень эффективен, если его применить ко всему изображению, каждая строка развёртки фильтруется отдельно, и к ней может быть применён любой или никакой алгоритм фильтрования.
Некоторые виды предсказывающих фильтров определены для использования с данными изображения PNG. Фильтрование применяется до сжатия, и обратное фильтрование применяется после извлечения данных изображения, восстанавливая их до изначального значения. Все фильтры PNG полностью обратимы и фильтруют без потерь.
Фильтр "Перед" сохраняет разность между значением байта текущего пикселя и значения соответствующего байта предыдущего пикселя (прогнозирующий фильтр). Этот метод позволяет вычислить разности одинаковой составной в нескольких многосоставных пикселях. Такой же прогнозирующий алгоритм используется в формате данных TIFF.
Фильтр "Сверху" сохраняет разность между байтом текущего пикселя и соответствующим байтом соответствующего пикселя в предыдущей строке развёртки. "Средний" фильтр сохраняет разницу между текущим пикселем и средним арифметически значений пикселей над и слева от текущего пикселя.
Фильтр "Траектории" использует линейную функцию для подсчёта значения. Ближайший совпадающий байт слева, верху или сверху слева используется в качестве прогнозирующего значения.
Полная спецификация PNG, документация по оглашаемым специальным блокам, инструментальные средства для внедрения PNG, и примеры PNG изображений доступны.
Текущая спецификация PNG находится на следующей Web странице:
http://sunsite.unc.edu/boutell/png.html
и следующих FTP сайтах:
ftp://swrinde.nde.swri.edu/pub/png/documents/
ftp://ftp.uu.net:/graphics/png/documents/
Наилучший источник информации о PNG и ресурсы находятся на сайте PNG группы Грега Роулофа:
http://quest.jpl.nasa.gov/PNG/
Вопросы о PNG можно задать службе рассылки новостей comp.graphics.misc, по адресу:
либо главному автору спецификации PNG Томасу Боутеллу:
E-mail: boutell@boutell.com
Разработчики PNG могут подписаться на PNG рассылку. Пошлите e-mail по адресу png-info@uunet.uu.net.
Другие PNG рассылки:
png-list@dworkin.wustl.edu | Основное обсуждение PNG |
png-announce@dworkin.wustl.edu | Объявления, связанные с PNG |
png-implement@dworkin.wustl.edu | Обсуждение о внедрении |
Вышеприведённые рассылки содержат Основное обсуждение PNG, объявления, связанные с PNG, и Обсуждение о внедрении PNG. Для дополнительной информации пошлите e-mail по адресу majordomo@dworkin.wustl.edu с единственным словом "help" в тексте письма.
Официальный FTP архив PNG:
ftp://ftp.uu.net/graphics/png/
Пример внедрения PNG в программу чтения и записи PNG на языке C доступен по адресу:
ftp://ftp.uu.net/graphics/png/src/
Тестовые изображения PNG для самоконтроля находятся на:
ftp://ftp.uu.net/graphics/png/images/
Материалы о PNG, включая зеркала всех сайтов, находятся на:
ftp://ftp.uu.net/graphics/png/ и на:
ftp://swrinde.nde.swri.edu/pub/png/
Все программы на этом сайте находятся в состоянии бета тестирования и должны использоваться с осторожностью. В случае вопросов, ошибки не в спецификации, а в коде.
Группа 42 - авторы библиотеки поддержки PNG формата LIBPNG. Их Web страница содержит раздел, посвящённый разработчикам, который включает библиотеку LIBPNG, спецификацию формата PNG , библиотеку сжатия, и набор тестовых изображений. Бесплатная версия библиотеки находится в наличии. Координаты Группы 42:
Group 42, Inc.
Телефон: 800-520-0042
Телефон: 513-831-3400
E-mail: info@group42.com
WWW: http://www.group42.com/
Хороший обзор PNG находится в статье Лии Даниела Крокера:
"PNG: Переносимый сетевой графический формат" в Журнале Доктора Добба том 20, номер 232 от Июля 1995, страницы 36-44.
В текстовом формате вышеупомянутая статья находится на:
ftp://ftp.mv.com/pub/ddj/1995/1195.07/ptot.zip
Статья о PNG от CompuServe:
http://www.compuserve.com/new/news_rel/png2.html
Copyright © 1996, 1994 O'Reilly & Associates, Inc. All Rights Reserved.