Декодирование png. Расчетно-графическая работа. Тема: «BMP, PCX, PNG – форматы. С каким размером сохранять найденные файлы
Общаясь со своими коллегами на различных семинарах и в студии, я пришел к выводу, что для многих единственным преимуществом формата PNG является наличие честной полупрозрачности. Если поискать в интернете информацию об этом формате, несложно заметить, что веб-разработчики разделились на два лагеря. Первые пишут о том, какой этот формат замечательный, оперируя чисто техническими данными, непонятными обычным кодерам и дизайнерам (к примеру, о превосходстве deflate-алгоритмов сжатия над LZW), другие же оставляют комментарии разной степени глупости о бесполезности PNG, не потрудившись даже вникнуть в суть вещей, описанных в спецификации.
Попробуем разобраться, какие преимущества дает этот формат, чтобы научиться ими пользоваться при подготовке иллюстраций для веба.
Начнем с терминологии. Предполагаю, что большинство читателей пользуются фотошопом и встречали там названия PNG-8 и PNG-24. Это не два разных формата, а всего лишь вариации одного и того же PNG. Формат позволяет хранить три типа изображений: greyscale (для описания изображения используется один канал — белый), indexed-colour (используется палитра цветов, как в GIF) и truecolor (используется три канала — RGB).
Самое главное преимущество формата PNG — это, конечно же, новые алгоритмы сжатия. Все помнят, что GIF эффективно сжимает только горизонтальные одноцветные области? Про это ограничение теперь можно забыть:
| GIF, 2568 байт |
|
Вторым важным преимуществом является фильтрация строк (scanline filtering, или delta filters), благодаря которой PNG-упаковщик может получить гораздо более удобные данные для сжатия.
Рассмотрим на примере, как они работают. Возьмем изображение 5×5 пикселей с горизонтальным градиентом и схематично отобразим, как оно может быть сохранено в файле (каждое число — уникальный цвет).
Как видно из примера, GIF-кодировщик отдал бы на сжатие строки, которые плохо упаковываются по горизонтали (потому что одинаковые цвета распространяются по вертикали). А вот как может преобразовать эти данные PNG-кодировщик:
Перед каждой строкой появилась цифра 2. Это — фильтр, который был применен к строке. В данном случае это фильтр Up, который говорит декодеру: «Для текущего пикселя возьми значение пикселя выше и прибавь к нему текущее значение». В нашем случае это 0, потому что цвета текущего и верхнего пикселей не отличаются. А эти данные можно эффективней упаковать, если у нас достаточно большое изображение.
Почему я написал может ? Потому что в нашем идеализированном случае более эффективной была бы такая схема:
Тут применен фильтр 1 под названием Sub, который говорит декодеру: «Возьми значение пикселя левее текущего и прибавь ему текущее значение». В данном случае 1.
После фильтрации все строки (вместе со значениями фильтров) объединяются в одну последовательность, которая затем сжимается deflate-алгоритмами (их обсуждение выходит за рамки этой статьи).
Проверим работу фильтров:
Внимательный читатель может заметить, что фильтры применяются не ко всему файлу целиком, а к строкам. Это значит, что каждая строка может иметь свой фильтр. Получается, что способов фильтрации одного изображения может быть 5 высота картинки. В общем-то, задача хорошего кодировщика как раз заключается в том, чтобы подобрать такие значения фильтров, при которых объем файла будет минимальным. К сожалению, фотошоп не всегда хорошо справляется со своей работой, поэтому на помощь приходят различные утилиты вроде и , которые в большое количество проходов подбирают разные способы фильтрации и стратегии сжатия данных, значительно сокращая тем самым объем некоторых сложных изображений. Однако стоит помнить, что эти программы не гарантируют уменьшение объема для каждого файла, они всего лишь пытаются найти оптимальный способ кодирования данных.
Еще один больной укол фотошопу за то, что он не умеет сохранять изображения в greyscale-режиме, то есть не умеет понижать глубину цвета. Тут нас опять спасут вышеозначенные утилиты, которые по возможности снижают глубину цвета, не ухудшая при этом качества картинки.
|
8167 байт |
6132 байта |
Преимущества greyscale над truecolor очевидны: к примеру, белый цвет в первом случае записывается (в десятичной системе счисления) числом 255, а во втором — 16777215.
Теперь, вооружившись знаниями о хранении данных в формате PNG, мы можем применять их в подготовке изображений для веба. Об этом — в следующих статьях.
Формат PNG (англ. portable network graphics) - растровый формат хранения графической информации, использующий сжатие без потерь по алгоритму Deflate.
PNG был создан как свободный формат (замена GIF), поэтому иногда в Интернете встречается расшифровка в качестве рекурсивного акронима "PNG is Not GIF" (PNG не GIF).
04 января 1995 г., Т. Боутелл предложил в ряде конференций Usenet создать свободный формат, который был бы не хуже GIF (дело в том, что до 11 августа 2006 г. GIF был защищен патентами). Через три недели после публикации идеи были разработаны четыре версии нового формата. Вначале он имел название PBF (Portable Bitmap Format), а нынешнее имя получил 23 января 1995 г. Уже в декабре того же года спецификация PNG версии 0.92 была рассмотрена консорциумом W3C, а с выходом 1 октября 1996 г. версии 1.0 - был рекомендован в качестве полноправного сетевого формата.
Структура формата
Общее строение
Файл состоит из подписи (Signature) и некоторого количества блоков (Chunk), которые содержат информацию о изображении.
- 89 - Символ не существующий (таблица ASCII). Препятствует распознаванию структуры, как текстового файла.
- 50 4E 47 - "PNG" (ASCII запись).
- 0D 0A - CRLF (Carriage-return, Line-feed), перевод строки (DOS).
- 1A - Останавливает вывод файла в DOS (end-of-file), чтобы не выводился текст.
- 0A - LF, перевод строки (Unix).
Блоки данных (Chunks)
Chunks (чанки) - это блоки данных, описывающих записанное изображение, из которых состоит файл. Каждый чанк состоит из 4 секций.
- Длина - Число, описывающее объем содержания блока.
- Тип представляет собой 4 чувствительных к регистру ASCII-символа. Регистры символов (пятый бит, числовая запись символа) в имени различаются неспроста - это флаги, сообщающие декодеру некоторую дополнительную информацию.
- Регистр первого символа определяет является ли данный чанк критическим (верхний регистр) или вспомогательным. Критические чанки должны распознаваться каждым декодером. Если декодер не может распознать критический чанк, он обязан завершить выполнение с ошибкой.
- Регистр второго символа задает "публичность" (верхний регистр) или "приватность" чанка. "Публичные" - официальные, задокументированные, распознаваемые большинством декодеров. Но если понадобится кодировать специфическую информацию, то просто в имени нужно сделать второй символ маленьким.
- Регистр третьего символа оставлен на "будущее". Предполагается, что он будет использоваться для дифференциации различных версий стандарта. Третий символ должен быть большим (версия 1.0 и 1.1). Если он оказался маленьким, все нынешние декодеры должны поступать с чанком, так же как и с любым другим не распознанным (то есть выходить с ошибкой если чанк критический, или пропускать в противном случае).
- Регистр же четвертого символа означает возможность копирования данного чанка редакторами, которые не могут его распознать. Если регистр нижний, чанк может быть скопирован, вне зависимости от степени модификации файла, иначе (верхний регистр) он копируется только, когда при модификации не были затронуты никакие критические чанки.
Например:
Критические:
- IHDR - заголовок файла, содержит основную информацию. Обязан быть первым.
- PLTE - палитра, список цветов.
- IDAT - содержит, собственно, картинку. Рисунок можно разбить на несколько IDAT чанков, для потоковой передачи. Каждый файлй должен содержать хотя бы один IDAT.
- IEND - завершающий чанк, обязан быть последним.
Вспомогательные:
- bKGD - задает основной фоновый цвет.
- cHRM - задаёт CIE 1931 цветовое пространство.
- gAMA - определяет гамму.
- hIST - чанк может хранить гистограмму или общее содержание каждого цвета.
- iCCP - цветовой профиль ICC
- iTXt - содержит текст (UTF-8), возможно сжатый, с необязательной языковой меткой. iTXt чанк с ключевым словом "XML:com.adobe.xmp" может содержать Extensible Metadata Platform (XMP).
- pHYs - содержит предполагаемый размер пикселя и/или отношение сторон.
- sBIT (significant bits) - определяет "цветовую точность" (color-accuracy) изображения (черно-белое, полный цвет, черно-белое с прозрачностью и т.д.), для более простого декодирования.
- sPLT - предлагает использовать палитру, если полный спектр цветов недоступен.
- sRGB - свидетельствует о использовании стандартной sRGB схемы.
- sTER - индикатор стереоскопических представлений.
- tEXt - может содержать текст (ISO/IEC 8859-1), с одной name=value парой.
- tIME - хранит дату последнего изменения.
- tRNS - содержит информацию о прозрачности.
- zTXt - сжатый текст, с теми же ограничениям, что и tEXt.
Контрольная сумма CRC-32. (Циклический избыточный код (англ. Cyclic redundancy check) - алгоритм нахождения контрольной суммы, предназначенный проверять целостность данных. CRC является практическим приложением помехоустойчивого кодирования, основанном на определенных математических свойствах циклического кода.)
Минимальный PNG
Как видно из представленного выше большинство чанков не является обязательными. Для формирования "полноценного" файла необходимо иметь минимальный набор блоков:
| PNG Signature | IHDR | IDAT | IEND |
Блок данных IHDR содержит следующие поля:
- Ширина, 4 Б .
- Высота, 4 Б .
- Битовая глубина (bit depth), определяет количество бит на каждый сэмпл (не пиксель), 1 Б .
- Тип цвета, состоит из 3 флагов 1 (используется палитра), 2 (используется цвет, не монохромное изображение), and 4 (присутствует альфа-канал), 1 Б .
- Метод сжатия. На данный момент доступно только значение 0 - сжатие по алгоритму deflate. Если значение отлично от 0, чанк считается нераспознанным, и декодер рапортует об ошибке. 1 Б .
- Метод фильтрации. Так же, как и в случае сжатия, на данный момент может быть только нулем. 1 Б .
- Interlace(переплетение) метод. Определяет порядок передачи данных. На данный момент доступно 2 значения: 0 (no interlace) и 1 (Adam7 interlace). 1 Б .
Содержит данные, закодированные, в соответствии с полем метода сжатия.
Сигнализирует о конце файла, блок данных не содержит ничего.
Пример
Разберем в HEX-редакторе. (276 Б)
- Signature 8 Б. Как и говорилось ранее она всегда одинаковые.
- IHDR
25 Б. Критический, пропускать нельзя, публичный, задокументированный, будет распознаваться почти всеми декодерами, версия стандарта 1.0 или 1.1.
00 00 00 0D - длина блока 9 Б
49 48 44 52 - "IHDR" (ASCII запись)
00 00 00 28 - ширина 40px
00 00 00 28 - высота 40px
08 - битовая глубина 8
06 - используется палитра
00 - сжатие по алгоритму deflate
00 - метод фильтрации, на данный момент всегда 0
00 - interlace метод. No interlace - IDAT 231 Б
- IEND 12 Б
Список источников
Доброго времени суток!
Вам когда-нибудь хотелось узнать как устроены файлы PNG? Нет? А я все равно расскажу.
Формат PNG(Portable Network Graphics) был изобретен в 1995 году, чтобы стать заменой GIF , а уже в 1996, с выходом версии 1.0, он был рекомендован W3C , в качестве полноправного сетевого формата. На сегодняшний день PNG является одним из основных форматов веб-графики.
Под катом вы найдете общее описание строения PNG-файла, некоторое количество картинок-схем, препарирование в hex-редакторе, и, конечно, ссылку на спецификацию.
Общее строение
Структура PNG в самом общем виде представлена на следующем рисунке.
То есть файл состоит из подписи и некоторого количества блоков(чанков, chunks), каждый из которых несет в себе некоторую информацию (спасибо КО!). Но почему подпись нельзя считать одним из чанков? Давайте разберемся поподробнее.
Подпись файла
Подпись PNG-файла всегда одинакова, состоит из 8 байт, и представляет собой (в hex-записи)Что же это означает?
- 89 - non-ASCII символ. Препятствует распознаванию PNG, как текстового файла, и наоборот.
- 50 4E 47 - PNG в ASCII записи.
- 0D 0A - CRLF (Carriage-return, Line-feed), DOS-style перевод строки.
- 1A - останавливает вывод файла в DOS режиме (end-of-file), чтобы вам не вываливалось многокилобайтное изображение в текстовом виде.
- 0A - LF, Unix-style перевод строки.
Chunks
Чанки - это блоки данных, из которых состоит файл. Каждый чанк состоит из 4 секций.
Разберем эти секции по порядку.
Длина
Ну, с длиной вроде все ясно. Просто числовое значение длины блока данных.Тип (имя)
С типом немного поинтересней. Тип представляет собой 4 чувствительных к регистру ASCII-символа. Регистры символов (пятый бит в числовой записи символа) в имени чанка различаются неспроста - это флаги, которые сообщают декодеру некоторую дополнительную информацию.- Регистр первого символа определяет является ли данный чанк критическим(верхний регистр) или вспомогательным(нижний регистр). Критические чанки должны распознаваться каждым декодером. Если декодер встречает критический чанк, тип которого не может распознать, он обязан завершить выполнение с ошибкой.
- Регистр второго символа задает «публичность»(верхний регистр) или «приватность»(нижний регистр) чанка. «Публичные» чанки - официальные, задокументированные, распознаваемые большинством декодеров. Но если вдруг вам для каких-то своих нужд понадобится кодировать специфическую информацию, то просто в имени чанка сделайте второй символ маленьким.
- Регистр третьего символа оставлен для будущих свершений. Предполагается, что он будет использоваться для дифференциации различных версий стандарта. Для версий 1.0 и 1.1 третий символ должен быть большим. Если он (внезапно!) оказался маленьким, все нынешние декодеры должны поступать с чанком, так же как и с любым другим не распознанным (то есть выходить с ошибкой если чанк критический, или пропускать в противном случае).
- Регистр же четвертого символа означает возможность копирования данного чанка редакторами, которые не могут его распознать. Если регистр нижний, чанк может быть скопирован, вне зависимости от степени модификации файла, иначе (верхний регистр) он копируется только в случае, когда при модификации не были затронуты никакие критические чанки.
Ниже приведен список типов чанков с краткими пояснениями.
Критические чанки
- IHDR - заголовок файла, содержит основную информацию о изображении. Обязан быть первым чанком.
- PLTE - палитра, список цветов.
- IDAT - содержит, собственно, изображение. Рисунок можно разбить на несколько IDAT чанков, для потоковой передачи. В каждом файле должен быть хотя бы один IDAT чанк.
- IEND - завершающий чанк, обязан быть последним в файле.
Вспомогательные чанки
- bKGD - этот чанк задает основной фоновый цвет.
- cHRM используется для задания CIE 1931 цветового пространства.
- gAMA - определяет гамму.
- hIST - в этом чанке может храниться гистограмма или общее содержание каждого цвета в изображении.
- iCCP - цветовой профиль ICC
- iTXt - содержит текст в UTF-8, возможно сжатый, с необязательной языковой меткой. iTXt чанк с ключевым словом "XML:com.adobe.xmp" может содержать Extensible Metadata Platform (XMP) .
- pHYs - содержит предполагаемый размер пикселя и/или отношение сторон изображения.
- sBIT (significant bits) - определяет «цветовую точность» (color-accuracy) изображения (черно-белое, полный цвет, черно-белое с прозрачностью и т.д.), для более простого декодирования.
- sPLT - предлагает палитру для использования, если полный спектр цветов недоступен.
- sRGB - свидетельствует о использовании стандартной sRGB схемы.
- sTER - индикатор стереоскопических изображений.
- tEXt - может содержать текст в ISO/IEC 8859-1 формате, с одной name=value парой для каждого чанка.
- tIME - хранит дату последнего изменения изображения.
- tRNS - содержит информацию о прозрачности.
- zTXt - сжатый текст, с теми же ограничениям, что и tEXt.
CRC
Контрольная сумма CRC-32 . Кстати на днях был топик о ее подсчете в Windows.Минимальный PNG
С общей структурой разобрались. Теперь разберем содержание обязательных чанков. Но какие из них обязательные (не критические, критические обязаны распознаваться декодером, а не присутствовать в каждом файле), и как выглядит минимальный PNG-файл? А вот как:
IHDR
Блок данных в IHDR содержит следующие поля:- Ширина, 4 байта
- Высота, 4 байта
- Битовая глубина (bit depth), определяет количество бит на каждый сэмпл(не пиксель), 1 байт
- Тип цвета, состоит из 3 флагов 1 (используется палитра), 2 (используется цвет, не монохромное изображение), and 4 (присутствует альфа-канал), 1 байт
- Метод сжатия. На данный момент доступно только значение 0 - сжатие по алгоритму deflate . Если значение отлично от 0, чанк считается нераспознанным, и декодер рапортует об ошибке. 1 байт
- Метод фильтрации. Так же, как и в случае сжатия, на данный момент может быть только нулем. 1 байт
- Interlace(переплетение) метод. Определяет порядок передачи данных. На данный момент доступно 2 значения: 0 (no interlace) и 1 (Adam7 interlace). 1 байт
IEND
Сигнализирует о конце файла, блок данных этого чанка не содержит ничего.IDAT
Содержит данные, закодированные, в соответствии с полем метода сжатия в заголовке. Алгоритм декодирования выходит за рамки данной статьи (однако если будут желающие, может появиться в следующей), но в довольно хорошо (и по-русски) описан .Таким образом, простейший PNG-файл (на примере ) выглядит следующим образом. 
Заключение
При написании данной статьи я ставил своей задачей дать читателю общие знания о строении PNG-файла, для более глубокого понимания рекомендуется читать спецификации .Топик на хабре про строение JPEG: habrahabr.ru/blogs/algorithm/102521
Топик на хабре про строение GIF: habrahabr.ru/blogs/algorithm/127083
Спасибо за внимание, буду рад любой критике!
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ
ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ
ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ
НОВОСИБИРСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ
Расчетно-графическая работа
Тема: «BMP, PCX, PNG – форматы»
По курсу «Сетевые информационные технологии »
Выполнил:
Группа:
АВТ-918
Проверил:
Новосибирск, 2013г.
1. Теоретическая часть
1.1. Введение
1.2. PNG – формат
1.2.1. Общая информация
1.2.2. Область применения
1.2.3. Структура файла
1.2.4. Достоинства
1.2.5. Недостатки
1.3. PCX – формат
1.3.1. Общая информация
1.3.2. Область применения
1.3.3. Структура файла
1.3.4. Достоинства
1.3.5. Недостатки
1.4. BMP – формат
1.4.1. Общая информация
1.4.2. Область применения
1.4.3. Структура файла
1.4.4. Достоинства
1.4.5. Недостатки
1.5. Сравнительная характеристика форматов
2. Практическая часть
1. Теоретическая часть
- Особенности растровой графики
Растровая графика описывает изображения с использованием цветных точек - пикселей, расположенных на сетке. Например, серфер в море описывается конкретным расположением и цветом каждой точки изображения, примерно, как в мозаике (фотографии, отсканированные рисунки и т. д.). При редактировании растровой графики изменяются пиксели, а не линии. Растровая графика зависит от разрешения, так как информация, описывающая изображение, прикреплена к сетке определенного размера. При изменении размеров данных файлов, качество может измениться, например, приведет к «разлохмачиванию» краев изображения, поскольку пиксели будут перераспределяться. Вывод растровой графики на устройства с более низким разрешением, чем само изображение, понизит его качество.
Применение растровой графики позволяет добиться качественного изображения, фотографического. Но все это создается за счет большого объема файла и работы вручную, т. е. при редактировании приходится поправлять каждую точку. Даже если использовать инструменты типа линии или примитивов (овалов, квадратов), то результат представляет собой изменение пикселей.
При изменении размеров изображений растровой графики качество ухудшается: при уменьшении - исчезают мелкие детали, а при увеличении картинка может превратиться в набор неряшливых квадратов (увеличенных пикселей).
При печати растровой графики или при просмотре на средствах, имеющих недостаточную разрешающую способность, значительно ухудшается восприятие образа.
- Разнообразие форматов растровой графики
Ни одна область применения компьютера не может похвастаться таким многообразием типов форматов файлов, как графика. Многие фирмы, выпуская графическую программу, создают свой собственных формат файлов, в котором редактор должен идеально сохранять все работы, созданные с его помощью. С увеличением количества существующих графических форматов совмещать их становится все труднее. Поэтому появилось несколько определенных форматов, ставших стандартами. Так, например, для изображений в Интернете в большинстве случаев используются форматы JPG и GIF, а в издательском деле царствует TIFF.
Многие растровые форматы обладают способностью нести дополнительную информацию: различные цветовые модели изображения, вектора, альфа-каналы (дополнительный канал, с помощью которого можно сохранять выделенные или прозрачные области изображения), слои различных типов, интерлиньяж (возможность чересстрочного показа изображения), анимацию, возможности сжатия и многое другое.
Достоинства растровых изображений: способность передать тончайшие нюансы изображения, возможность редактировать индивидуально каждый пиксель, изменяя его параметры. Ну, а принципиальный недостаток один - очень большие размеры полученного файла.
1.2.1. Общая информация
Формат PNG (P ortable N etwork G raphics ) представляет собой растровый формат хранения графической информации, использующий сжатие без потерь по алгоритму Deflate . Данный формат был создан как свободный формат для замены GIF.
Днём рождения PNG можно считать 4 января 1995 года, когда Т. Боутелл предложил в ряде конференций Usenet создать свободный формат, который был бы не хуже GIF. И уже через три недели после публикации идеи были разработаны четыре версии нового формата. Вначале он имел название PBF (Portable Bitmap Format ), а нынешнее имя получил 23 января 1995 года. Уже в декабре того же года спецификация PNG версии 0.92 была рассмотрена консорциумом W3C , а с выходом 1 октября 1996 года версии 1.0 PNG был рекомендован в качестве полноправного сетевого формата.
Формат PNG спроектирован для замены устаревшего и более простого формата GIF, а также, в некоторой степени, для замены значительно более сложного формата TIFF (см. официальный сайт PNG или хронологическую страницу для дополнительной информации).
Формат GIF был разработан фирмой CompuServe в 1987 году и изначально был недоступен для свободного использования. До окончания в 2004 году действия патентов на алгоритм сжатия LZW , принадлежавших Unisys и используемых в GIF, его применение в свободном программном обеспечении было затруднено. На данный момент такие затруднения сняты. PNG же с самого начала использует открытый, непатентованный алгоритм сжатия Deflate , бесплатные реализации которого доступны в Интернете. Этот же алгоритм используют многие программы компрессии данных, в том числе PKZIP и gzip (GNU zip ).
Для передачи анимированных изображений был разработан расширенный формат MNG, опубликованный в середине 1999 года и уже поддерживаемый в различных приложениях, однако пока так и не ставший общепринятым.
Некоторые - в частности, разработчики Mozilla Foundation - критиковали MNG за сложность и большой размер реализации, и отсутствие обратной совместимости с PNG. В 2004 году они разработали формат APNG, который не был принят в качестве официального стандарта разработчиками PNG и MNG, но его поддержка к 2008 году была реализована в тестовых сборках некоторых браузеров и некоторых программах просмотра изображений.
1.2.2. Область применения
Формат PNG предназначен, прежде всего, для использования в Интернете и редактирования графики.
Формат позволяет хранить три типа изображений: greyscale (для описания изображения используется один канал - белый), indexed-colour (используется палитра цветов, как в GIF) и truecolor (используется три канала - RGB). При этом он хранит графическую информацию в сжатом виде, и это сжатие производится без потерь, в отличие, например, от JPEG.
Формат PNG является хорошим форматом для редактирования изображений, даже для хранения промежуточных стадий редактирования, так как восстановление и пересохранение изображения проходят без потерь в качестве. Также, в отличие, например, от TIFF, спецификация PNG не позволяет авторам реализаций выбирать, какие возможности они собираются реализовать. Поэтому любое сохранённое изображение PNG может быть прочитано в любом другом приложении, поддерживающем PNG.
1.2.3. Структура файла
Файл PNG состоит из блоков данных, называющихся chunk "ами. C hunk в общем случае имеет переменную длину. Чтобы отличить один от другого, в каждом chunk "е есть поле типа.
Минимальный PNG-файл должен содержать как минимум сигнатуру и три chunk "a:
IHDR -- заголовок файла
IDAT -- данные, собственно картинка
IEND -- конец файла
Chunk состоит из четырёх полей:
Length -- длина поля данных chunk"а (4 байта)
Type -- поле типа (4 байта)
Data -- поле данных, может быть нулевой длины
CRC -- поле с проверочным кодом для полей Type, Data
Сигнатура PNG-файла содержит всегда 8 байт:
* (decimal) 10 26 10
* (hexadecimal)e 47 0d 0a 1a 0a
* (ASCII C notation) \211 P N G \r \n \032 \n
Сигнатура не является стандартным chunk "ом.
IHDR chunk
Этот chunk содержит основную информацию о картинке: ширина и высоту в пикселях, количество битов на сэмпл (не на пиксель) или количество бит, определяющее размер палитры и т. п.
IEND chunk
Это chunk сигнализирует о конце PNG-файла.
IDAT chunk
Этот chunk содержит данные с графической информацией. Эти данные запакованы в zlib формат. Данные, запакованные в zlib формат, запакованы в формат DEFLATE, который в общем случае предусматривает сжатие информации. Но один из вариантов DEFLATE позволяет хранить данные в контейнерах DEFLATE без сжатия.
Графическая информация, хранящаяся в IDAT chunk "ах, представляет собой набор строк (scanlines ). В формате PNG для более эффективного сжатия предусмотрена фильтрация строк. Для указания используемого фильтра перед данными строки должен следовать один байт. Содержимое означает, какой фильтр используется. В самой простой реализации фильтр можно не использовать (ведь и сжатия никакого не планируется). В этом случае этот байт должен быть равен 0.
Как вариант, одна строка графической информации может упаковываться в один IDAT chunk . Так, например, сделано в Беркут-ЕТ: файл содержит 240 IDAT chunk "ов.
Алгоритмы упаковки данных без сжатия в zlib и deflate форматы очень просты для реализации во встраиваемых системах, поскольку они сводятся к простому формированию заголовков и подсчёту контрольной суммы adler32.
Рис. 1. Структура PNG -файла
На рисунке изображена последовательность chunk "ов, образующих файл PNG. Как уже говорилось, в chunk "и IDAT "укладываются" 240 строк. Перед каждой строкой следует байт, указывающий тип фильтра (значение 0).
На рисунке используются следующие обозначения:
CH - chunk header , содержит длину поля данных и тип chunk "а IDAT
ZH - zlib header ,
DH - DEFLATE header, содержит 5 байт
CC - контрольная сумма crc32 для chunk "a
ZA - контрольная сумма adler32 для данных, упакованных DEFLATE алгоритмом.
Важно, что CC считается для каждого chunk "a, а ZA считается для всего вектора данных, упакованного алгоритмом DEFLATE.
- zlib header
Он содержит 2 байта: 0x78, 0x01
Байт 0х78 означает, что для компрессии данных используется DEFLATE с окном до 32 Кбайт.
Байт 0х01 содержит проверочный бит для первого байта и определяет уровень сжатия "без сжатия".
DEFLATE header
DEFLATE header содержит 5 байт . Первый байт содержит информацию о типе компрессии и о последнем блоке. Если используется тип компрессии "no compression", то первый и последующие блоки должны иметь первый байт 0x00, а последний блок 0x01.
Ещё четыре байта используются для указания длины блока (первые 2 байта) и проверочного поля для длины блока (вторые 2 байта). Другими словами -- LEN и NLEN, где NLEN = 0xffff - LEN.
- png check
PNG check -- это утилита, упрощающая жизнь программисту при отладке кода, создающего PNG. Она проверяет правильность формирования PNG и сообщает, если что-то не так. Например, утилита может отследить, что не сходится контрольная сумма или отсутствует какой-нибудь chunk , и т. п.
1.2.4. Достоинства
PNG обладает более высокой степенью сжатия для файлов с большим количеством цветов, чем GIF, но разница составляет около 5-25 %;
Так же самое главное преимущество формата PNG - это новые алгоритмы сжатия. В отличие от формата GIF, который эффективно сжимает только горизонтальные одноцветные области, формат PNG этим не ограничивается. Для сравнения приведено два изображения в разных форматах. Очевидно, что при почти десятикратной эффективности сжатия потерь в качестве не замечено.
Рис. 2. PNG (372 байта) Рис. 3. GIF (2, 5 Кбайт)
Еще одним важным преимуществом является фильтрация строк (scanline filtering , или delta filters ), благодаря которой PNG-упаковщик может получить гораздо более удобные данные для сжатия.
Например, есть изображение 5×5 пикселей с горизонтальным градиентом. Схематично отобразим, как оно может быть сохранено в файле (каждое число - уникальный цвет).
Рис. 4. Схематичное отображение
Как видно из примера, GIF-кодировщик отдал бы на сжатие строки, которые плохо упаковываются по горизонтали (потому что одинаковые цвета распространяются по вертикали). А вот как может преобразовать эти данные PNG-кодировщик:
Рис. 5. Схематичное отображение (PNG -кодировщик)
Перед каждой строкой появилась цифра 2. Это - фильтр, который был применен к строке. В данном случае это фильтр Up , который говорит декодеру: «Для текущего пикселя возьми значение пикселя выше и прибавь к нему текущее значение». В нашем случае это 0, потому что цвета текущего и верхнего пикселей не отличаются. А эти данные можно эффективней упаковать, если у нас достаточно большое изображение.
1.2.5. Недостатки
К недостаткам формата можно отнести :
а. Не все веб-браузеры одинаково отображают содержимое png-файла. Узким местом являются:
Частичная прозрачность (альфа-канал);
Поддержка прозрачности в палитре;
Гамма-коррекция.
Поддержка расширений PNG с анимацией.
Цветовая коррекция (ICC).
б. Существует одна особенность GIF, которая в PNG не реализована - поддержка множественного изображения, особенно анимации; PNG изначально был предназначен лишь для хранения одного изображения в одном файле.
1.3.1. Общая информация
PCX (PCExchange ) - стандарт представления графической информации, разработанный компанией ZSoft Corporation. Использовался графической программой ZSoft PC Paintbrush (одной из первых популярных графических программ) для MS-DOS, текстовыми процессорами и настольными издательскими системами, такими как Microsoft Word и Ventura Publisher .
Данный формат является не столь популярным аналогом BMP, хотя поддерживается специфическими графическими редакторами, такими как Adobe Photoshop, Corel Draw, GIMP и др. В настоящее время вытеснен форматами, которые поддерживают лучшее сжатие: GIF, JPEG и PNG.
Тип формата - растровый. Большинство файлов такого типа использует стандартную палитру цветов, но формат был расширен из расчета на хранение 24-битных изображений.
PCX - аппаратно-зависимый формат. Предназначается для хранения информации в файле в таком же виде, как и в видеоплате. Для совместимости со старыми программами необходима поддержка EGA-режима видеоконтроллером.
Формат предполагает использование простейшего алгоритма сжатия (Run Length Encoding, RLE) без потерь информации. Алгоритм такого сжатия очень быстрый и занимает небольшой объём памяти, однако не очень эффективен, непрактичен для сжатия фотографий и более детальной компьютерной графики. При сохранении изображения, подряд идущие пиксели одинакового цвета объединяются, и вместо указания цвета для каждого пикселя указывается цвет группы пикселей и их количество. Такой алгоритм хорошо сжимает изображения, в которых присутствуют области одного цвета.
1.3.2. Область применения
Область применения данного формата сокращается, поскольку вытесняется другими форматами. Имеет больше историческое значение, нежели практическое.
Однако, благодаря поддержке многими приложениями и простоте перезаписи, данный формат нередко используется разработчиками при работе с растровой графикой.
Так же данный формат используют многие графические редакторы, в частности Paint . Вместе с форматом TIFF формат PCX является одним из наиболее распространённых форматов, которые используют сканеры.
1.3.3. Структура файла
Файл изображения PCX начинается с заголовка длиной 128 байт. Затем идут закодированные графические данные.
При кодировании используется простой алгоритм, основанный на методе длинных серий. Если в файле запоминается несколько цветовых слоев, каждая строка изображения запоминается по цветовым слоям. Согласно документации Zsoft , это выполняется по приведенной ниже схеме (R - красный слой, G - зеленый слой, B - синий слой, I - слой интенсивности)
Строка изображения 0:
RRR...
GGG...
BBB...
III...
Строка изображения 1:
RRR...
GGG...
BBB...
III...
(и т. д.)
Запоминание по слоям проводится, как правило, для 16-цветных изображений EGA. При стандартной палитре EGA, которая устанавливается по умолчанию BIOS"ом, нулевой слой видео памяти содержит СИНЮЮ компоненту цвета, а не красную. Если же палитра отлична от стандартной, то говорить о том, что слои видео памяти, соотносятся с компонентами цвета вообще затруднительно.
Метод кодирования состоит в следующем:
ДЛЯ каждого байта X, прочитанного из файла. ЕСЛИ оба старших бита X равны 1, то <повторитель> = значению, хранящемуся в 6 младших битах X <данные> = находятся в следующем байте за X. ИНАЧЕ <повторитель> = 1 <данные> = X
Поскольку для насыщения данного алгоритма требуется в среднем 25% неповторяющихся данных и, по меньшей мере, наличие смещения между повторяющимися данными, то размер получаемого файла, как правило, оказывается приемлемым.
Смещение | Обозначение | Длина | Описание / комментарий |
Manufacturer | Постоянный флаг 10 = ZSoft. PCX |
||
Version | Информация о версии: |
||
Encoding | 1 = PCX кодирование длинными сериями |
||
Bits per pixel | Число бит на пиксел в слое |
||
Window | Размеры изображения (Xmin, Ymin) – (Xmax, Ymax) в пикселах включительно |
||
Hres | Горизонтальное разрешение создающего устройства |
||
Vres | Вертикальное разрешение создающего устройства |
||
Colormap | |||
Reserved | |||
NPlanes | Число цветовых слоев |
||
Bytes per Line | Число байт на строку в цветовом слое (для PCX-файлов всегда должно быть четным) |
||
Palette Info | Как интерпретировать палитру: |
||
Filler | Заполняется нулями до конца заголовка |
||
1.3.4. Достоинства
Возможность создания ограниченной палитры цветов (например, 16 или 256 цветов);
Поддерживается большим количеством приложений;
Сжатие производится без потерь.
1.3.5. Недостатки
Не поддерживает цветовые системы, отличные от RGB;
Многочисленные варианты, особенно при работе с цветами, могут делать работу с файлом невозможным;
Неудобная схема сжатия в действительности может увеличивать размеры некоторых файлов.
1.4.1. Общая информация
BMP (от англ. Bitmap Picture) - формат хранения растровых изображений, разработанный компанией Microsoft.
С форматом BMP работает огромное количество программ, так как его поддержка интегрирована в операционные системы Windows и OS/2. Файлы формата BMP могут иметь расширения. bmp, .dib и. rle. Кроме того, данные этого формата включаются в двоичные файлы ресурсов RES и в PE-файлы.
Компания Microsoft также разработала для своих нужд форматы ICO и CUR, которые имеют похожую на BMP структуру. Кроме этого, структуры из этого формата используются некоторыми WinAPI-функциями подсистемы GDI.
Глубина цвета в данном формате может быть 1, 4, 8, 16, 24, 32, 48 бит на пиксель. При этом для глубины цвета меньше 16 бит используется палитра с полноцветными компонентами глубиной 24 бита.
В формате BMP изображения могут храниться, как есть или же с применением некоторых распространённых алгоритмов сжатия. В частности, формат BMP поддерживает RLE-сжатие без потери качества, а современные операционные системы и программное обеспечение позволяют использовать JPEG и PNG (эти форматы встраиваются в BMP как в контейнер).
1.4.2. Область применения
Из-за большого объема изображения и редкого использования сжатия, файлы в данном формате весят слишком много для использования в сети.
Однако же, не смотря на свою «старость», данный формат широко используется для работы в пределах одной машины благодаря интегрированной поддержке в ОС Windows . С данным форматом работают практически все известные программы .
1.4.3. Структура файла
BMP - стандартный формат графических файлов Windows. Подавляющее большинство BMP-файлов хранится без сжатия, что облегчает работу с ними.
BMP-файлы состоят из трех основных частей:
- заголовок;
палитра;
графические данные (значения пикселей).
Заголовок содержит информацию о файле и находящемся в нем графическом изображении. Здесь хранятся параметры изображения (ширина, высота, глубина пикселей), а также количество цветов в нем.
Палитра присутствует только в BMP-файлах, содержащих палитровые изображения (с глубиной пикселей 8 бит и менее). К 8-битным изображениям прикладывается палитра, состоящая не более чем из 256 элементов.
Графические данные - это и есть само изображение. Формат этих данных зависит от глубины пикселей. 8-битные BMP-файлы могут использоваться для работы с 8-битными поверхностями, а 24-битные - для беспалитровых поверхностей.
- Структура заголовка
Данные заголовка BMP-файла хранятся в двух структурах:
BITMAPFILEHEADER и BITMAPINFOHEADER .
Структура BITMAPFILEHEADER присутствует в начале любого BMP-файла и содержит информацию о самом файле. Для нас в этой структуре представляет интерес лишь одно поле - bfType , сигнатура BMP-файла. В BMP-файлах это поле содержит буквы BM (обе буквы - прописные). По содержимому этого поля мы будем убеждаться в том, что выбранные файлы действительно имеют формат BMP.
Структура BITMAPINFOHEADER содержит информацию об изображении, хранящемся в BMP-файле. Эта структура объявляется так:
typedef struct tagBITMAPINFOHEADER {
DWORD biSize;
LONG biWidth;
LONG biHeight;
WORD biPlanes;
WORD biBitCount;
DWORD biCompression;
DWORD biSizeImage;
LONG biXPelsPerMeter;
LONG biYPelsPerMeter;
DWORD biClrUsed;
DWORD biClrImportant;
} BITMAPINFOHEADER, FAR *LPBITMAPINFOHEADER, *PBITMAPINFOHEADER;
Первое поле, biSize , определяет размер структуры BITMAPINFOHEADER в байтах. Если ваша программа создает BMP-файл, это поле заполняется тривиально - достаточно определить размер структуры функцией sizeof . Однако при чтении BMP-файла по содержимому этого поля приходится рассчитывать позицию файла, на которой структура заголовка кончается. Эта мера обеспечивает обратную совместимость, благодаря ей Microsoft в будущем сможет увеличить размер структуры BITMAPINFOHEADER , не нарушая работы существующих приложений.
Поля biWidth , biHeight и biBitCount определяют размеры изображения. Содержимое поля biCompression позволяет узнать, хранится ли изображение в сжатом виде. Поскольку мы не собираемся работать со сжатыми BMP-файлами, необходимо проверить, имеет ли это поле значение BI_RGB (а не BI_RLE8 , свидетельствующее о сжатии файла).
В поле biSizeImage хранится размер графических данных (в пикселях). Однако учтите, что это поле часто оказывается незаполненным (содержит нулевое значение). В таких случаях нам придется самостоятельно вычислять размер графических данных.
Наконец, поле biClrUsed определят количество цветов в палитре (для палитровых изображений). Как и поле biSizeImage , оно часто может быть равно нулю. Это означает, что палитра содержит максимальное количество элементов (256 для 8-битных изображений).
- Палитра
Палитра в BMP-файлах хранится в виде списка структур RGBQUAD , где каждый элемент представляет отдельный цвет. Структура RGBQUAD объявляется так:
typedef struct tagRGBQUAD {
BYTE rgbBlue;
BYTE rgbGreen;
BYTE rgbRed;
BYTE rgbReserved;
} RGBQUAD;
В первых трех полях хранятся цветовые RGB-составляющие. На поле rgbReserved мы не будем обращать внимания (предполагается, что оно равно нулю). Как я упоминал выше, количество структур RGBQUAD в BMP-файле определяется полем biClrUsed . Тем не менее обычно 8-битные BMP-файлы содержат 256 структур RGBQUAD . В 24-битных RGB-файлах структуры RGBQUAD отсутствуют.
- Графические данные
Графические данные в основном представляют собой список пикселей, из которых состоит изображение. Однако каждая горизонтальная строка пикселей должна занимать блок памяти, выровненный по границе параграфа. Следовательно, если количество байт, необходимых для хранения строки пикселей, не кратно четырем, в каждую строку включается от одного до трех дополняющих байт.
При этом для работы с графическими данными BMP-файлов используется концепция шага. Отличие состоит в том, что для графических данных BMP-файлов значение шага программисту придется считать самостоятельно. Впрочем, это не так уж сложно, потому что шаг всегда попадает на ближайшую границу параграфа за концом блока памяти, необходимого для хранения строки пикселей.
Изображения хранятся в BMP-файлах в перевернутом виде, так что первая строка пикселей файла на самом деле является нижней строкой настоящего изображения.
1.4.4. Достоинства
Возможность редактирования почти в любой программе, как стандартной, так и специальной;
Высокое качество изображения.
1.4.5. Недостатки
Абсолютно не подходит для сети Интернет;
Крайне неудачный выбор для последующей распечатки;
Аппаратно-зависимый формат.
JPEG | |||||
Потери при сжатии | |||||
Максимальное число бит на пиксел | |||||
Прозрачность | альфа-канал | ||||
Гамма-коррекция | |||||
Множественное изображение | |||||
Алгоритм сжатия | Deflate(LZ 77) | JPEG | |||
Размер изображения | |||||
Проблемы отображения браузерами | |||||
Цветовая схема | Все доступные | Не поддерживает CMYK | Все доступные | Не поддерживает Indexed color , со CMYK вероятны проблемы при чтении |
В мы рассматривали, как с помощью регулярных выражений можно восстановить данные даже после переформатирования накопителя. Эта статья посвящена анализу структуры файла — второму подходу, используемому в режиме «черновое восстановление». Он намного более точен в определении начала файла и, в зависимости от формата, позволяет узнать полный размер, целостность и размер целой части файла. Возьмем форматы BMP и PNG, которые используются для хранения растровых изображений, и на их примере рассмотрим какие возможности могут быть получены с помощью анализа структуры. Формат BMPОписание формата можно найти, например, на сайте Microsoft или в Wikipedia (русская и английская). Если оставить только значимые для нас подробности, то файл BMP выглядит следующим образом: Упрощенная структура файл BMP Где Bitmap File Header – это структура следующего вида: Здесь важно, что
Благодаря заголовку мы можем:
С помощью полей этой структуры можно выполнить дополнительные проверки, которые снизят шанс ложного срабатывания:
Большую часть файла занимают данные изображения. В большинстве случаев, это несжатые данные. Цвет каждого пикселя кодируется определенным числом бит, а затем они записывают последовательно друг за другом. Это, к сожалению, означает, что данные могут быть произвольными и их проверить никак нельзя. Подведем итог. Формат BMP позволяет достаточно точно находить начало файлов и точно определять их полный размер, даже для поврежденных файлов. Но нет возможности узнать целый файл или нет, а также узнать размер валидной части, если он поврежден. Формат PNGPNG – еще один формат хранения растровых изображений, но уже со сжатием (но без потери качества как в jpeg). Его спецификацию можно найти на сайте W3C . Она занимает не один десяток печатных страниц. Однако, для восстановления данных достаточно знать совсем немного. Любой файл PNG начинается с последовательности из 8 байт: 89 50 4E 47 0D 0A 1A 0A. Затем идет последовательность chunk’ов - кусочков на которые разбит весь png файл. Упрощенная структура файла PNG Структура chunk’а:
То есть, для каждого chunk’а указаны:
И последнее, что нужно знать -последовательность chunk’ов не может быть произвольной. В спецификации приведены 2 схемы следования chunk’ов друг за другом:
Последовательность chunk’ов с PLTE
Последовательность chunk’ов без PLTE Внутри прямоугольника записан тип chunk’а. Черта «|» означает, что должен быть или один или другой chunk. А символы сверху обозначают сколько раз он может встречаться:
Такой формат очень удобен для поиска и проверки файла:
В отличии же от формата BMP, для поврежденного файла нельзя узнать его полный размер. С каким размером сохранять найденные файлы?Мы разобрались с тем, какие возможности для восстановления данных заложены в форматах BMP и PNG. Рассмотрим теперь различные случаи с целыми и поврежденными файлами. Это поможет нам правильно интерпретировать результаты поиска. При поиске по шаблону GREP мы выставляли размер до следующего найденного заголовка, другого способа узнать размер у нас не было. Анализ структуры может дать больше информации, но и логика принятия решения здесь сложнее. Когда мы находим файл BMP, мы имеем информацию только о его полном размере и можем проверить лишь небольшую часть в начале.
Нельзя ручаться за данные, которые находятся после проверенного размера. Если файл, например, фрагментирован, то следующий заголовок может быть найден уже внутри «полного размера»:
В этой ситуации размер файла при сохранении из режима ограничивается смещением до следующего заголовка, чтобы наверняка захватить целую часть (ее мы не можем определить автоматически). Если внутри «полного размера» других заголовков не найдено, то он и будет использован, т.к. сохранять больше данных нет смысла. Возможно это целый файл, для которого схема будет выглядеть уже так:
Если мы нашли целый PNG файл, то все очень просто. Мы проверили его от начала до конца, знаем его размер и уверены, что он целый.
Более сложная ситуация, если PNG файл поврежден.
Нам не удалось проверить очередной chunk, поэтому известно, что файл поврежден. Проверенный размер будет покрывать все целые chunk’и. Целая часть может оказаться больше. Файл будет сохранен до следующего заголовка, т. к. полный размер неизвестен (его можно получить только проверив успешно файл до конца). Форма «чернового восстановления»
Форма режима «черновое восстановление» С помощью анализа структуры мы можем получить значительно больше информации чем при простом поиске по шаблонам GREP. Рассмотрим как она отображается на форме чернового восстановления.
В «черновом восстановлении» файлы ищутся как с помощью шаблонов GREP, так и с помощью анализа структуры. Поле GREP на панели с категориями заполнено только у первых.
Записи на панели с результатами тоже отличаются.
В режиме есть панель «метаданные», в нее попадает различная полезная информация, полученная при анализе файла по структуре. Например, для Boot NTFS (на скриншоте) можно узнать размер раздела, размер кластера, кластер с MFT0 и его копией. Пример с картой памяти из фотоаппаратаВ прошлой статье был пример с отформатированной картой памяти. Тогда мы не использовали анализ внутренней структуры файлов. Теперь выполним поиск с параметрами по-умолчанию.
Результаты выполнения «чернового восстановления» Мы нашли такое же количество файлов JPEG. Однако результата стал намного более наглядным и точным:
ЗаключениеНа примере форматов BMP и PNG мы разобрали как в «черновом восстановлении» ищутся файлы на основе знаний о структуре. Очевидно, что такой подход дает намного более качественный результат, чем поиск с помощью регулярных выражений. Но алгоритмы проверки - это часть комплекса, и их нельзя добавить также легко как очередной шаблон GREP. Изначально, режим «черновое восстановление» разрабатывался как последний рубеж при восстановлении данных. Он применялся лишь в тех случаях, когда остальные методы не дали удовлетворительных результатов. Но с развитием комплекса режим стал находить все больше применений при решении самых разных задач. О них мы обязательно напишем в следующих статьях. Леоненко Александр |
