Png структура: структура изображений в формате PNG. Разбираем на примере — UNDERPOWERED
Структура PNG | LAMPCORE
Написать комментарий
Все операции будем проводить при помощи шестнадцатеричного HEX-редактора Translhextion
Скачать( внутри справка в формате .chm и шрифт в .ttf):
Translhextion_LampCore_Ru
Открываем Translhextion, перетягиваем в окно изображение формата png, рассматриваем байты.
PNG(сокращение от Portable Graphic Network) — это растровое изображение, которое имеет следующую структуру:
Первые 8 байт это сигнатура PNG, всегда одна и та же:
89 50 4E 47 0D 0A 1A 0A
Первый байт 89 — идентификация типа файла, для систем, где ожидается, что первые два байта будут идентифицировать тип файла. Первый байт выбирается не как ASCII-символ для того, чтобы файл не был распознан как текст, также это исправляет плохую передачу файла, которая очищает 7-ой бит.
Второй, третий и четвертый 50 4E 47 — PNG в текстовом формате ASCII
Пятый, шестой 0D 0A — конец строки и перевод(DOS, CR+LF)
Седьмой 1A — EOF, End Of Fil, конец файла (DOS)
Восьмой байт 0A — LF, перевод строки(Unix)
После идут несколько обязательных фрагментов(chunks), блоков с данными — IHDR, IDAT, IEND
Пример первых 8-ми байт блока IHDR:
00 00 00 0D 49 48 44 52
Первые 4 байта фрагмента это размер фрагмента:
00 00 00 0D — размер 13 байт.
После идет тип(имя) фрагмента:
49 48 44 52 — IHDR в ASCII
Далее после имени фрагмента, идет его описание:
IHDR состоит из 13 байт, пример:
00 00 00 80 00 00 00 7F 08 03 00 00 00
Первые 4 байта — 00 00 00 80 это ширина изображения, в десятичной системе 128
Вторые 4 байта — 00 00 00 7F это высота изображения, в десятичной системе 127
Девятый байт — 08 количество бит, соответственно изображение 8-ми битное
Десятый байт — 03 тип цвета, имеет три варианта:
1 — Используется палитра
2 — Цветное изображение, не монохромное
3 — Альфа канал
Так как у нас изображение имеет прозрачность, то стоит байт 03
Одиннадцатый байт — 00 метод сжатия, всегда 0
Двенадцатый байт — 00 метод фильтрации, всегда 0
Тринадцатый и последний байт IHDR — 00 переплетение(interlace), 00 — нет переплетения, 01 — переплетение Adam7
Последние 4 байта фрагмента — это контрольная сумма CRC32, рассчитывается, исходя из предыдущих байт фрагмента, байты для расчета, включают имя фрагмента и его данные, но не включают поле длины фрагмента!То есть для расчета берутся байты 49 48 44 52 00 00 00 80 00 00 00 7F 08 03 00 00 00
На данный момент имеем:
89 50 4E 47 0D 0A 1A 0A — сигнатура PNG
00 00 00 0D 49 48 44 52 — Длина и описание блока данных(IHDR)
00 00 00 80 00 00 00 7F 08 03 00 00 00 — Значения полей блока данных IHDR
10 24 3A 35 — Контрольная сумма CRC32 блока данных IHDR
В итоге начало файла выглядит так:
89 50 4E 47 0D 0A 1A 0A 00 00 00 0D 49 48 44 52 00 00 00 80 00 00 00 7F 08 03 00 00 00 10 24 3A 35
IDAT — содержит данные самого изображения
IEND — говорит о конце файла, не имеет полей, значение фиксировано:
49 45 4E 44 AE 42 60 82
В текстовом представлении выглядит как — » IEND®B`‚»
ОЦЕНИТЕ ДАННУЮ ПУБЛИКАЦИЮ:
Отправить рейтинг
Средний рейтинг / 5. Количество оценок:
Мы сожалеем, что эта публикация Вас не устроила.
Напишите, пожалуйста, что Вам конкретно не понравилось, как можно улучшить статью?(оценка будет засчитана только при наличии отзыва)
Отправить отзыв
Спасибо за ваш отзыв!
Простое введение в особенности формата
Greg Roelofs, <[email protected]>
http://pobox.com/~newt
Иван Зенков, <[email protected]>
Dimok Busheff, <[email protected]>
Данный документ предназначен для разъяснения некоторых
особенностей формата PNG обычным пользователям, по
этому здесь вы не увидите акцентирования внимания на таких вещах как
свобода PNG от патентов, поскольку они в первую
очередь касаются лишь программистов. Встречающаяся техническая
информация призвана объяснить пользователю почему различные
приложения не работают так как он от них этого ожидает. В случае
тестов с производительностью (особенно в сравнении с другими
графическими форматами) предполагается, что используемая реализация
находится PNG на уровне лучших реализации
freeware-кодеров. Обратите внимание, что в настоящие
время возможны проблемы даже при использовании некоторых популярных
(и дорогих) графических редакторов.
Вот ещё несколько страниц сторонних авторов, с различными
взглядами на PNG:
Примечание:
Прошу вас особенно обратить внимание на то, что весь
нижеприведённый текст это по сути перевод A
Basic Introduction to PNG Features (ни о каком GFDL
здесь и речи быть не может). По ходу дела я буду высказывать своё
скромное мнение на счёт PNG в частности и графики
вообще (и вот это мнение уже может распространяться под GFDL).
Если найдёте какие-то неточности, устаревшие фрагменты в данном
документе или новые особенности и недостатки PNG не
описанные здесь, то Greg ждёт от
вас писем. Ну, а я в свою
очередь жду исправлений, дополнений и так далее, к самому переводу.
Область применения
Формат PNG (Portable Network Graphics)
спроектирован для замены устаревшего и более простого формата GIF,
а также в некоторой степени для замены значительно более комплексного
формата TIFF (см. официальный
сайт PNG или хронологическую
страницу для дополнительной информации). В данном документе мы
сосредоточимся на двух основных направлениях в использовании формата.
Первое, использование во всемирной паутине (WWW) и
второе, графическое редактирование.
Для вэб PNG действительно имеет три основных
преимущества перед GIF: альфа-каналы (переходная
прозрачность), гамма-коррекция (межплатформенное управление яркостью
изображения), двумерная чересстрочность (метод прогрессивной
развёртики). Он обладает превосходным уровнем сжатия по сравнению с
GIF, но различия колеблются около 5-25%, что не так
уж и много для того, чтобы подвигнуть людей использовать только этот
формат. Существует одна особенность GIF которую PNG
не пытается воспроизвести, это поддержка множественного
изображения, особенно мультипликации, PNG был
предназначен лишь для одного изображения. Существует очень схожий с
PNG расширенный формат называемый MNG,
завершён в середине 1999 года и уже поддерживается в различных
приложениях,
но MNG и PNG имеют различные
расширения и различные цели.
Для редактирования изображения, как профессионального так и не
очень, PNG предоставляет отличный формат, даже для
хранения промежуточных стадий редактирования. Поскольку сжатие
происходит полностью без потерь и поскольку формат поддерживает
48-битный «truecolor» или 16-битный
«grayscale«, сохранение, восстановление и
пересохранение изображения проходят без потерь в качестве в отличии
например от стандартного JPEG (даже с максимально
высоким уровнем качества). В отличие от TIFF PNG
спецификация не позволяет авторам реализаций привередничать
выбирая какие возможности они собираются реализовать; как результат,
любое сохранённое PNG изображение в одном
приложении, может быть прочитано в любом другом приложении
поддерживающим PNG.
За перечислением плюсов PNG, прошу обратить ваше
внимание, что часто для обмена целостными «truecolor»
изображениями (особенно фотографическими) JPEG —
почти всегда лучший выбор. Хотя сжатие JPEG
производиться с потерями при которых могут появляться артефакты, их
всё же можно минимизировать, а вот размер файла даже на
высококачественном уровне значительно меньше, чем в случае с
форматами сжатия без потерь, вроде того же PNG.
Также например для чёрно-белого изображения, особенно текста или
рисунков, сжатие TIFF Group 4 или формат JBIG
часто значительно лучше подходит, чем 1-битный «greyscale»
PNG.
Примечание:
В последнем случае я с автором всё таки не согласен. Да
действительно часто предпочтительней использовать JPEG,
особенно для фотографий. Но это лишь в том случае, когда изображение
не имеет для вас первичного приоритета, то есть второстепенно.
Отправляя же например свою фотографию девушке, я бы не рискнул
сохранить её в JPEG. Не говоря уже о таких случаях,
когда я девушке отправляю не свою фотографию, а изображение своего
рабочего стола. В последнем случае все эти артефакты всё равно
проявятся и испортят общее впечатление от моих огромных SVG
иконок. В случае же с чёрно-белыми изображениями из выше
перечисленного я бы вообще ничего использовать не стал. По мне дак,
для таких задач (а подразумевались отсканированная документация) я бы
вообще использовал замечательный формат DjVu, о
котором уже как-то писал.
Сжатие
PNG обладает лучшим уровнем сжатия без потери
информации и без патентных отчислений, но к сожалению далеко не все
реализации полностью используют доступные возможности и даже те
которые таковые возможности используют, могут быть неправильно
применены.
PNG поддерживает три основных типа изображения,
это: «truecolor«, «grayscale»
и индексированное на основе палитры (8-битный). JPEG
поддерживает только два первых, а GIF лишь третий
(хотя при использовании серой палитры может фальсифицироваться и
«grayscale«). Плотность сжатия происходит
из способности смешивать различные типы изображения в одном PNG
файле. Заставляя приложение сохранить 8-битное изображение как
24-битный «truecolor» (или RGB),
в результате вы не получите маленького файла. Это может быть
неизбежно в случае когда оригинал был изменён с добавлением более 256
цветов (например если в качестве фона был добавлен сплошной
градиент), но многие изображения преднозначеные для сети, состоят из
256 цветов, а иногда и всего из нескольких (например из десяти).
Основная ошибка, это включение слишком большого количества данных
палитры в PNG изображение. Эта ошибка наиболее
заметна при конвертировании небольших GIF
изображений (маркеров, кнопок и др.) в формат PNG.
Эти изображения занимают в среднем 1000 байт и содержат 256 вводных в
палитру данных из которых необходимы лишь 50, что приводит более чем
к 600 байтам потраченного впустую пространства.
Примечание:
Имеется введу сохранение индексированного изображения в RGB,
RGBA или просто с лишними данными в палитре, то есть
лишними цветами.
Другая ошибка, использовать один тип фильтра сжатия или его
неправильную подборку. Фильтры сжатия будут описаны ниже, с их
помощью можно добиться поразительного различия в уровне сжатия
изображения. Хотя на самом деле это не та особенность с которой
должен экспериментировать пользователь.
Под конец ещё несколько слов о сжатии. Механизм сжатия может быть
установлен на быстрый или качественный уровень. Часто «качественное
сжатие» предпочтительнее, но иногда может быть выбран
промежуточный уровень, например для повышения интерактивной
производительности. Обычно (независимо от настроек) различия в
размере файлов минимальны, но порой они бывают просто огромны.
Примечание:
Обратите внимание, что какой бы уровень сжатия вы не выбрали,
качество изображения абсолютно не изменится измениться лишь время его
загрузки.
Для дополнительной информации относительно механизма сжатия PNG
и алгоритма CRC-32 посетите официальный
сайт zlib. Для альтернативной реализации алгоритма сжатия
посетите официальный сайт 7-Zip и
почитайте «Введение
в компрессию» для описания сжатия вообще. Для инструментария
оптимизации и сжатия PNG изображений, посетите
страницу со списком конвертеров
(особое внимание обратите на pngcrush и SmartSaver).
Примечание:
Автор не упомянул наверное одну из лучших программ в своём роде,
называется она OptiPNG
(542KB) и доступна «as-is» под несколько
операционных систем (существует ещё версия OptiPNG Plus,
но у неё с «public-domain» проблемы).
Лучшей OptiPNG я посчитал из-за простоты
использования хотя бы по сравнению с тем же pngcrush,
о котором упоминалось выше.
Итак, за собственно сам уровень сжатия в OptiPNG
отвечают следующие ключики:
- -i: тип чересстрочности (0-1)
- -zc: уровни сжатия zlib
(1-9), по умолчанию 9 - -zm: уровни памяти zlib
(1-9), по умолчанию 8 - -zs: стратегии сжатия zlib
(0-2) - -f: дельта-фильтры PNG
(0-5)
Справку по остальным ключам программы можно получить набрав
optipng —help, впрочем нам они всё равно не
понадобиться, как не понадобятся и выше перечисленные ключики.
Разработчик OptiPNG позаботился о пользователях,
снабдив программу специальным ключом оптимизации -o
(0-7), по умолчанию 2. По сути ключ -o это
определённая комбинация из вышеперечисленных ключей. Так -o2
будет -zc9 -zm8 -zs0-2 -f0,5, а -o3
будет -zc9 -zm8-9 -zs0-2 -f0,5, самым же эффективным
является -o7 тест с которым я и покажу.
Для теста было выбрано олигархическое полотно замечательного
художника Владимира
Куша, предварительно обработанное GIMP’ом
(стабильная версия 1.2) и сохранённое в RGBA как PNG
с отключёнными параметрами и степенью сжатия 9. В результате было
получено изображение в 135168 байт, если верить моему кривому du.
Сжатие производилось OptiPNG версии 0.4.3,
осуществлялось командой optipng -k -o7, ключ -k
нужен, чтобы при оптимизации не был удалён оригинальный файл. В
результате файл с оптимизированным изображением весил 118784 байт
полагаясь на тот же du.
Как видите, оптимизация налицо, и всё это без каких-нибудь потерь
в качестве (да в случае с PNG их и не могло быть).
Так первое изображение (слева) это оригинал сохранённый в GIMP‘е
(помните максимальный уровень сжатия?), второе — оптимизированный
вариант.
«Чудо» — скажете вы и будете в корне неправы, ведь
чудеса если и бывают, то явно не в данном случае. Нет это
действительно было не чудо, это была ещё одна распространённая
ошибка. Некоторые люди создавая новое изображение в GIMP‘е
(да и других редакторах) выбирают прозрачный фон в качестве заливки
(в диалоге «Новое изображение» GIMP‘а даже
раздел «Тип заливки» имеется), и, почему-то, им кажется,
что раз прозрачный, то и на размере это не отразиться. Разумеется, на
размере это отражается, и отражается в большую сторону, поскольку
добавляется альфа-канал (помните, что изображение я сохранил в
RGBA?). OptiPNG, как программа
умная, всё это замечает и удаляет, предоставляя нашему вниманию
нормальное изображение. GIMP за сим же процессом ещё
при сохранении не следит полагаясь на благоразумность пользователя.
Бороться с ошибкой можно выбирая в качестве заливки какой-нибудь цвет
ещё при создании изображения (в GIMP‘е начиная с
версии 1.3, можно вообще на задавать заливку, получив весьма странный
нулевой фон). А OptiPNG действительно замечательная
программка, она позволяет избавить PNG файл не
только от программных ошибок, но и от людских тоже. Советую, особенно
для оптимизации больших коллекций, Бог знает кем и как созданных
изображений.
Фильтры сжатия
Фильтры сжатия — способ преобразования графических данных
(разумеется без потерь) для улучшения уровня сжатия. Каждая
горизонтальная линия в изображении может иметь один из пяти типов
фильтров. Выбор какой именно фильтр из пяти использовать для каждой
строки, это скорей больше чёрная магия, чем наука. Однако, по крайней
мере один действительно хороший алгоритм не только известен, но даже
описан в спецификации
PNG и реализован в свободно доступном программном обеспечении.
Вероятно найдутся алгоритмы которые будут работать ещё лучше, но пока
это не было центральной областью исследований.
Посредством примера (по общему признанию критический и
нереалистичный случай), 512
x 32,768 изображение содержит все 16,777,216 возможные в 24-бита
цвета, сжимается более чем в 300 раз лучше с фильтрацией,
чем без. Несжатое изображение весило 48MB, сжатое, но без фильтров
36MB, а версия
с фильтрами всего 115,989 байт (0.1 MB). Более того, Paul
Schmidt создал 4096
x 4096 версию размером 59,852 байт, с общим коэффициентом сжатия
841:1, что более чем в 600 раз лучше версии без фильтров.
Ted Samuels пропустил всё это через утилиту Ken‘а
Silverman‘а PNGOUT (ссылки на
другие конвертеры ищите на специальной
странице) и урезал до 57,549 байт, добившись тем самым
коэффициента в 875:1 (см. эту
страницу для загрузочной версии и дополнительной информации).
Более реалистичный пример с океанографическими данными NASA
на сайте Ocean ESIP.
Цифровые карты отображающие различные физические измерения, могут
быть динамически сгенерированы в GIF или PNG.
PNG версии неизменно равны одной-пятой версии GIF,
благодаря фильтрам сжатия. Для примера, карта показывающая высоту
поверхности северо-восточного Тихого океана 1 Августа 1997 года (во
время El Niño) занимает 70,090 байт в GIF,
и всего 13,880 байт в PNG
(см. главу Алгоритмы
фильтров из PNG
спецификации).
Как измерение, всё это просто кажется нереалистичным, однако
заметьте, что эти, с виду гиперсжатые, PNG могут
самостоятельно быть сжаты с дополнительным коэффициентом где-нибудь
приблизительно от 21 до 97 (в зависимости от изображения) простым
применением gzip. Конечно, gzip PNG
не так ужасно полезны в большинстве случаев, а вот MNG
хорош для всего, сокращая размер на 456 байт.
Альфа-каналы
Также известный как маска-канал, альфа-канал это просто
способ объединить переходную прозрачность с изображением. Принимая во
внимание, что GIF поддерживает простую бинарную
прозрачность (это когда любой пиксель может быть либо полностью
прозрачным, либо абсолютно непрозрачным), PNG
позволяет 254 уровня частичной прозрачности между нормальным
изображением (или 65,534 уровня прозрачности для специальных «очень
безумных» форматов, но здесь мы больше концентрируемся на
изображениях, используемых в интернете).
Все три типа PNG изображений («truecolor«,
«grayscale» и индексированная палитра)
могут содержать альфа-информацию, хотя обычно она применяется лишь с
«truecolor» изображениями. Вместо того,
чтобы сохранять три байта для каждого пикселя (красный, зелёный и
синий), сохраняются четыре: красный, зелёный, синий и альфа, таким
образом получается RGBA. Вся эта переходная
прозрачность позволяет вам создавать замечательные «спецэффекты»,
хорошо выглядящие на любом фоне. Например эффекта фотовиньетки, для
портрета, можно добиться путём установки полностью непрозрачной
центральной области (то есть для лица и плеч), прозрачной остальной
обстановки и с созданием плавного перехода между двумя этими
различными областями. Рассматривая изображение в браузере типа Arena,
портрет будет плавно осветляться на белом фоне, и затемняться на
чёрном. Ещё один идеальный спецэффект с альфа-прозрачностью, это
отбрасывание тени. Так на изображениях ниже показан тукан, в первом
случае отбрасывающий тень на красочный фон, во втором на свою копию.
Эта особенность с прозрачность наиболее важна для маленьких
изображений, обычно используемых на вэб-страницах, вроде цветных
(круглых) маркеров или причудливого текста.
Альфа-смешивание позволяет использовать другой эффект, а именно
сглаживание (anti-aliasing) создавая иллюзию гладких кривых
на сетке прямоугольных пикселей плавно изменяя их цвета, что
позволяет добиться округлых и кривых изображений, хорошо отображаемых
как на белом (к примеру), так и на любом другом фоне. Таким образом
одно и тоже изображение может быть многократно использовано в
нескольких местах без «призрачного» эффекта, свойственного
GIF изображениям.
Примечание:
Я не очень-то понял, в чём заключается этот «призрачный
эффект». Было несколько вариантов, среди которых наибольшую
проблему в GIF у меня вызывали изображения созданные
для одного фона, но наложенные на другой, приблизительно так же, как
я сделал со знаменитым зверьком O’Reilly
Network, только ещё хуже.
Конечно эффективная замена GIF-кнопкам и иконкам
должна быть сравнима по размеру, и часто приходится исключать
«truecolor» RGBA
изображения. Впрочем точно также PNG поддерживает
альфа-информацию и в случае с индексированными изображениями, просто
это намного труднее осуществить. Изображение в PNG с
альфа-индексацией — это изображение, чья палитра обладает
альфа-информацией, связанной с ней, а не индексированное изображение
с полной альфа-маской. Другими словами каждый пиксель соответствует
данным из палитры с красными, зелёными, синими и альфа компонентами.
Так, если вы хотите получить яркие красные пиксели с четырьмя
различными уровнями прозрачности, вам потребуется использовать четыре
отдельных ячейки в палитре, чтобы их индексировать (все четыре ячейки
обладают идентичными RGB компонентами, но альфа
значения различаются). Если вы хотите чтобы все ваши цвета
имели четыре уровня прозрачности, вам проще сократить общее
количество доступных цветов с 256, до 64. В основном только некоторые
цвета нуждаются более чем в одном уровне прозрачности, и выяснение
какие именно, процесс требующий определённой мудрости. Можно
взглянуть на программу pngquant,
которая конвертирует 32-битные RGBA PNG
в 8-битные изображения с RGBA-палитрой. Для
программистов доступен исходный код программы.
Для более лучшего объяснения с красивыми примерами, смотрите главу
«Прозрачность
и сглаживание» замечательной WWW4 статьи
Chris‘а Lilley‘я Не
просто декорация: Качественная графика для вэб.
Примечание:
К стати, поразительная вещь, но GIMP, кажется, об
этом не в курсе. Сколько раз я не пытался сохранить в нём прозрачное
индексированное PNG изображение, мои попытки
оканчивались неудачей. То есть RGBA пожалуйста,
«grayscale» на здоровье, а вот чтоб
индексированное с прозрачностью, ни в какую. Что же всё таки делать,
если понадобилось небольшое прозрачное изображение? Ну, выход, как
всегда, есть, и о нём уже говорилось выше, нужно просто использовать
pngquant (24KB).
В начале я создал обычное RGBA изображение, взяв
за основу уже индексированную когда-то картинку (не очень сильно) с
персонажем замечательной игры DROD.
Затем командой pngquant 64 rgba.png получил нужное
мне индексированное изображение с прозрачностью. Там где 64, я
установил количество необходимых мне цветов, а rgba.png
это файл первого изображения. Думаю несложно догадаться, что первое
изображение это и есть мой первоначальный вариант (весил он 12288
байт), а второе это индексированный вариант с прозрачностью (занимал
всего 8192 байт).
Индексированное подобным образом изображение, успешно отобразили
GQview (не создав иконки
в предварительном просмотре), Opera
и Mozilla. Проблемы были
разумеется с GIMP‘ом (версии 1.2, 1.3) и
Konqueror’ом (версии 3.1.4).
Впрочем, несмотря на все минусы, единственным способом уменьшить
размер PNG файла, помимо сжатия, остаётся
индексирование. А в случае когда с индексированием необходим ещё и
альфа-канал, pngquant становиться практические
незаменимым инструментом. И очень жаль, что свободное ПО таких
масштабов как GIMP не знает всех возможностей
формата PNG, да ещё и при том, что исходники того же
pngquant доступны «as-is«.
Гамма-коррекция
Гамма-коррекция существует для исправления различий того, как
компьютеры (а особенно мониторы) интерпретируют цветовые значения.
Вэб-дизайнеры, вероятно, знают случаи, когда созданные на Macintosh
изображения выглядят слишком тёмными на PC, или
созданные на PС выглядят слишком светлыми на Mac‘ах.
Изображение, которое хорошо смотрится на SGI Workstation,
не хочет отображаться на Macintosh или PC.
Изображение созданное на одном PC неверно
отображается на всех остальных.
Гамма-информация — частичное решение. Это способ связи некоего
числа с компьютерной системой отображения, в попытке характеризовать
хитрую физику, скрывающуюся в пределах цифро-аналогового конвертера
графической карты (RAMDAC) и в высоковольтной
электронной пушке монитора.
Параметр гамма — это только приближение к действительности. Лучшей
аппроксимацией является использование так называемых значений
цветности (chromaticity values — также поддерживаемых в
PNG), в качестве той же гаммы, но даже это лишь
приближение. Самое лучше решение, доступное на данный момент, это
использование системы управления цветом (которая опять же
поддерживается PNG через расширение фрагментом
sRGB). Стоит, однако, сказать, что для большинства
людей достаточно лишь установить гамму изображения и настроить гамму
системного монитора.
Для дополнительной информации смотрите руководства Chris‘а
Lilley: гамма,
цветность
и управление
цветом, или почитайте «Гамма-руководство»
в дополнении к спецификации
PNG. Для более детальной технической информации смотрите «FAQ:
Гамма и цвет» Charles‘а Poynton‘а,
официальный сайт Интернационального
Цветового Консорциума, домашнюю страницу sRGB
или главу «Гамма-коррекция»
в статье Chris‘а Lilley Не
просто декорация: Качественная графика для вэб.
Чересстрочность
Чересстрочность или прогрессивная развёртка, была известна на
протяжении долгого времени. GIF стал поддерживать её
с 1989-го, TIFF приблизительно в тоже время (хотя не
стандартизированным путём), JPEG с начала 90-ых
(хотя это не было широко распространено до 1996-го). Метод
чересстрочности PNG концептуально схож с GIF
и визуально подобен прогрессивному JPEG (то есть,
двухмерен).
Вот GIF анимация (автор Willem
van Schaik), показывающая преимущества двухмерной чересстрочной
схемы PNG, по сравнению с одномерной версией GIF.
Первое, на что следует обратить внимание, так это на то, что пока
видна приблизительно одна восьмая изображения в GIF,
PNG изображение уже становиться видимым сразу же
после выполнения первого прохода. Первый проход PNG
это только 1/64-ая часть данных изображения. Первый проход GIF
1/8-ая. К тому времени, когда первый проход GIF
завершился, уже были отображены четыре прохода PNG,
и в отличие от GIF-пикселей, растянутых с
коэффициентом 8:1, пиксели PNG были растянуты лишь
на 2:1. Более того, на самом деле в нечётных проходах никакого
растяжения нет вообще и только чётные растягиваются вертикально на
2:1. Это означает, что, например, внедрённый в изображение текст
будет доступен для чтения в два раза быстрее, в PNG
изображении.
Смотрите чересстрочную
демонстрацию PNG для «увеличенного» взгляда на то, как
PNG отображает чересстрочные пиксели, или читайте
главу «Представление
данных» из PNG
спецификации для деталей относительно чересстрочной схемы формата
PNG.
Проверка целостности файла
PNG поддерживает три основных типа проверки
целостности, для помощи программам в работе с файлами. Первый и самый
простой — 8-байтная магическая сигнатура в начале любого PNG
изображения. Позволяет обнаружить наиболее основное повреждение файла
— передачу бинарного файла в текстовом (или ASCII)
режиме. На большинстве систем, окончание строки в текстовых файлах
отмечается символом возврата каретки (CR), символом
перевода строки (LF), либо и тем и другим сразу.
Macintosh используют CR, UNIX
системы используют LF, все остальные не UNIX
системы на PC (DOS, Windows
3.x/95/NT, OS/2) используют CR/LF.
Магическая сигнатура PNG грамотно включает как
CR/LF, так и LF. Так, для теста
передадим в текстовом режиме изображение, на DOS-машину,
к LF будет добавлен CR. На
UNIX-системах, CR/LF будут
преобразованы в обычный LF. На Macintosh
и CR/LF, и LF будут преобразованы в
CR. Для того, чтобы узнать произошло ли текстовое
искажение, достаточно взглянуть на первые восемь, девять байт файла
(команда file в UNIX спроектирована
специально для таких вещей). Имейте введу, что проблема не в
испорченной сигнатуре, реальная проблема состоит в том, что символы
CR и LF в данных изображения могут
быть опознаны не как конец строки или текст, а как значения пикселей
или более абстрактные лексемы компрессора, и все эти символы будут
также преобразованы, таким образом разрушая изображение.
Второй тип проверки целостности известен как 32-разрядный
циклический контроль избыточности или CRC-32.
PNG изображение делится на логические кусочки данных
и с каждым кусочком связываются CRC-данные. Если
хотя бы один бит в кусочке будет изменён, значение повреждённых
данных перестанет соответствовать сохранённым CRC-данным
оригинального кусочка. Подобные вещи легко можно проверить не
декодируя изображение, фактически это может быть проверено на лету во
время загрузки, если программное обеспечение достаточно грамотно для
подобных действий.
Третий тип проверки целостности применим лишь к кусочку/кусочкам
данных изображения и схож с CRC-значениями. Так где
CRC-значения кусочков изображения обращается к
фильтрованным, сжатым данным в кусочке, контрольная сумма
Adler-32 обращается к завершённому потоку
распакованных данных (независимо от того, сколько кусочков
изображения могли быть охвачены). В действительности это используется
лишь в библиотеках сжатия самого нижнего уровня как средство проверки
плохо кодирующего/декодирующего программного обеспечения.
Для более подробной информации смотрите главу «Структура
файла» из спецификации
PNG.
Произношение
Нет второстепенных вопросов для авторов почти совершенного
формата! Да, действительно, даже акроним и произношение были главными
темами обсуждения. Причина этому конечно GIF. Кто-то
произносит с мягким «G», как «джемпер», кто-то с
жёстким, как «гараж» и никто в действительности не знает
почему. Но, чтоб вы знали в данном случае правильным будет мягкое
«G», поскольку так говорят сами авторы.
PNG всегда пишется по буквам «PNG»
(или Portable Network Graphics) и произносится как «пинг»,
а не «пинджи» или «пэ эн гэ» (впрочем вполне
нормально, что люди не говорящие на английском произносят PNG
по буквам).
Для более чётких инструкций относительно данного вопроса, смотрите
введение
в PNG спецификации.
Примечание:
Под конец пара слов относительно использования данного формата в
вэб, а точнее относительно связанных с этим проблем. Первая из них, и
о ней уже много говорили, это патент на LZW
(замечательный алгоритм сжатия применяющийся в GIF,
не хочу сказать лишнего, но мне кажется, что он сжимает лучше, чем
все эти zlib, используемые в PNG)
принадлежащий Unisys. Хорошая новость в том, что
патент на территории США истёк 20 Июня, 2003 года. Плохая в том, что
он всё ещё действует на территории таких стран как Италия, Франция,
Канада, Германия, Англия и Япония. Понятно, что Россия всегда в
стороне от подобных вопросов, и каждый что-то решает для себя.
Удивительно то, что альтернатива-то в лице PNG,
да и не альтернатива даже, а нечто большее, уже существует давно. То
есть действительно PNG большее, ведь он используется
во всех современных desktop-системах, его альфа-прозрачность это
просто праздник какой-то и для рабочих столов, и для интернета. Здесь
другая проблема, Internet Explorer его не
поддерживает, точней не поддерживает прозрачность. С этим есть
несколько способов борьбы,
в определённой мере они действенны. Вообще в подобные вопросы я бы
даже вникать не стал. То, что Microsoft не
поддерживает формат, проблемы Microsoft, а не
формата.
Огорчает не только Microsoft (и я об этом уже
говорил), огорчает свободное программное обеспечение. Все эти
странные проблемы с тем же Konqueror‘ом… Я уже не
говорю о GIMP‘е. Не говорю хотя бы потому, что не
использовал все эти новые версии 2.0. Просто надеюсь, там всё
исправили.
Copyright 2004, Иван Зенков
Данный документ (кроме отдельно указанных частей, переводного
текста и др.) распространяется в соответствии с GNU
Free Documentation License опубликованной Free
Software Foundation и изготовлен в полном соответствии
со стандартами w3 консорциума.
Все торговые марки, названия и логотипы использованные или
упомянутые в этом документе, принадлежат своим владельцам.
Остальные мои статьи можно найти на моей страничке
на сайте Rus-Linux.net
Если вам понравилась статья, поделитесь ею с друзьями:
Структура PNG-файла: основные и вспомогательные фрагменты (chunks): nabbla1 — LiveJournal
После написания PNGRepack у меня появился спортивный интерес — просмотреть все файлы PNG на своём компьютере и выяснить, чего интересненького в них напихано кроме непосредственно изображений?
Впрочем, интерес не только спортивный — до сих пор PNGRepack относилась к не относящимся к делу фрагментам очень лояльно — записывала их в преобразованный файл, как ни в чем не бывало, хотя от многих из них вполне можно избавиться, а другие, напротив надо нежить, холить и лелеять, и вообще при обработке изображений обращать на них пристальное внимание.
Сегодня про общую структуру и про фрагменты tEXt, zTXt, iTXt, tIME, pHYs и gAMA.
До сих пор не знаю, как слово chunk правильно перевести на русский, пущай будет фрагмент. Каждый фрагмент начинается с 4-х байт длины, затем название из 4-х латинских букв, затем непосредственно данные, а в конце — 4-байтная контрольная сумма CRC. Из того, как построено название, уже можно много почерпнуть.
Если первая буква заглавная, значит фрагмент «критический», т.е считается, что без него изображение не удастся посмотреть ни в каком виде, и если хоть один из критических фрагментов отсутствует, декодер должен грязно выругаться. Критических фрагментов сейчас 4: IHDR (Image Header), PLTE (Palette), IDAT (Image Data) и IEND (Image End). Уже здесь возникает неоднозначность — палитра критически важна только для изображений, у которых ColorType = COLOR_PALETTE, для остальных она допустима (правильный декодер должен попытаться ей воспользоваться, если монитор может отображать одновременно лишь ограниченное число цветов), но как правило отсутствует.
Соответственно, строчная буква означает, что фрагмент «вспомогательный» (Ancillary), т.е что-то похожее отобразится и если их проигнорировать, но зачем-то их все-таки запихнули, наверное, не зря.
Если последняя буква у вспомогательного фрагмента заглавная, значит, что при изменении самого изображения они тоже, возможно, должны определенным образом измениться, поскольку зависят от этого изображения, например, tRNS (transparency) отвечает за «простую прозрачность» (cheap transparency), когда либо один из цветов назначается прозрачным, он-то и записан в tRNS, либо нескольким первым цветам палитры приписываются значения прозрачности. Если какое-то приложение открыло tRNS, ничего не зная о том, что это за зверь, а потом после работы с изображением перемешало палитру, то ничего хорошего не выйдет, и считается лучшим выходом либо вообще выкинуть tRNS после такого издевательства, либо и вовсе не браться за редактирование изображения, если в нем есть такие вспомогательные фрагменты с заглавной последней буквой. Впрочем, это правило мало кто соблюдает, да и расплывчатое оно. Почему gAMA (значение гамма-коррекции) так уж зависит от самой картинки — мне непонятно. Собственно, строчная последняя буква есть только у текстовых фрагментов и у pHYs (pHysical size), хранящего разрешение картинки при сканировании, скажем, 600 dpi.
И наконец, вторая буква названия фрагмента заглавная, если он «публичный», т.е утвержден высочайшим советом и входит в спецификацию, и строчная, если он «частный», таковые тоже существуют, но известно о них немного. Скажем, Adobe Fireworks использовала формат PNG в качестве базового, но добавила туда свои собственные фрагменты mkBS, mkTS, mkBF, prVW и др., чтобы хранить что-то вроде слоёв и векторов, чтобы можно было сохранить проект в PNG, а позже открыть его и продолжить работать как ни в чем ни бывало. О том, как они устроены, Adobe не распространяется. На эти штуки я натыкался, они могут занимать приличные объемы, и если мы не собираемся редактировать эту картинку в Fireworks, их следует удалить.
(что такое FACECAFE — не знаю. Похоже на рекламный слоган: «Хороший mkBT начинается с FACECAFE»)
Теперь рассмотрим, наконец, фрагмент каждого типа подробнее.
Текстовые фрагменты (tEXt, zTXt, iTXt)
Произвольный текст, добавленный к изображению. Например, таким образом можно записать EXIF, хотя фотографии обычно все-таки хранятся в JPG. tEXt — самый простой, несжатый текст, каждый фрагмент содержит название (keyword) и непосредственно текст. zTXt (zipped text) — то же самое, только текст сжат тем же самым zlib (оставлена возможность под другие форматы сжатия, но пока доступен только CompressionMethod=0, что означает zlib), а iTXt (international text) имеет кодировку не Latin-1, как два предыдущих, а UTF-8, причем текст может быть сжатым, а может и нет, а кроме Keyword добавляются еще поля Language и Translated keyword.
(Пожалуй, самое нетривиальное, что встретилось мне в текстовых полях)
Для Keyword определены стандартные значения Title, Author, Description, Copyright, Creation Time, Software, Disclaimer, Warning, Source, Comment, но можно использовать и любые другие.
Ничего особенно интересного в этих полях я не находил, чаще других попадается Software — многие графические редакторы заполняют его своим названием, это продукты Adobe, Gimp, Paint.net и другие. Чрезвычайно бесят пустые поля, когда у изображения целый набор этих текстовых фрагментов — Title, Author, Description, но текст у них вообще отсутствует. В PNGRepack добавлена галочка удалять такие пустые поля без лишних вопросов.
Метка времени tIME
В стандарте сказано, что это должно быть время последнего изменения изображения, оттого последняя буква заглавная (отредактировал изображение — будь добр и время переписать!). Довольно скучная вещь, но может пригодиться.
Физические размеры пикселя (разрешение) pHYs
Совсем короткий фрагмент, но очень важный при обработке сканов — многие программы этого толка отталкиваются не от размера изображения в пикселях, а от физического размера бумаги, чтобы обложка в 600 dpi и последующие страницы в 300 dpi в итоге отображались бы в одном масштабе. Как правило, в pHYs записывается горизонтальное и вертикальное разрешение в пикселях на метр, которые легко пересчитать в пиксели на дюйм.
Возможен вариант, когда единица измерения не указана, тогда узнать реальное разрешение нельзя, только «соотношение сторон пикселя» — такой информацией было бы полезно снабдить кадр анаморфного видео, чтобы можно было корректно отобразить его на экране. Создатели формата рекомендуют проверять, являются ли пиксели «квадратными» у изображения и растягивать его в нужную сторону, если нет, чтобы не получить вытянутые морды. Пока ни одного изображения с «безразмерным» разрешением мне не встретилось.
Снова видим эфемерность регистра последней буквы — тут она строчная, но очевидно же, что при масштабировании изображения нам придется поменять и физическое разрешение. Не удивлюсь, если создатели формата кидали монетку, чтобы определить, где буква будет заглавной, а где строчной.
Гамма-коррекция gAMA
Самый неоднозначный фрагмент. Задумка была хорошая — на разных операционных системах свои соглашения, с какой гаммой показывать изображения, соответственно, (128,128,128) может означать немножко разный цвет, и почти никогда это не будет 50% серый, который ближе к (192,192,192), в общем, хотелось авторам навести некоторый порядок, но почему-то, вместо того, чтобы обозначить, как закодирована яркость в изображении (1 означало бы, что линейно, а число отличное от 1 — наличие степенной зависимости), они постановили, что гамма будет говорить просмотрщику, в какой мере надо еще преобразовать эти пиксели, прежде чем в линейном виде подать на монитор! Это привело к большой путанице, и я не уверен, что хоть где-то её обработка сделана корректно. Вот те немногие гаммы, что я находил в изображениях:
Кажется, вот оно, корректное применение — мы предупреждаем просмотрщик, что вместо стандартной для sRGB гаммы в 2.2 мы задаем 2.4, и просмотрщик теперь чуть-чуть подкорректирует значения и получит качественную картинку. НЕ ТУТ-ТО БЫЛО!!! Согласно спецификации, в gAMA должно заносится значение, обратное гамме, в данном случае 1/2.4 = 0.42. То, что программы продолжают беспалевно сохранять сюда саму гамму вместо обратной величины, и никто этого не заметил — дурной признак.
Продолжение следует.
«Черновое восстановление» (Часть 2: Анализ форматов)
В прошлой статье мы рассматривали, как с помощью регулярных выражений можно восстановить данные даже после переформатирования накопителя. Эта статья посвящена анализу структуры файла — второму подходу, используемому в режиме «черновое восстановление». Он намного более точен в определении начала файла и, в зависимости от формата, позволяет узнать полный размер, целостность и размер целой части файла.
Возьмем форматы BMP и PNG, которые используются для хранения растровых изображений, и на их примере рассмотрим какие возможности могут быть получены с помощью анализа структуры.
Формат BMP
Описание формата можно найти, например, на сайте Microsoft или в Wikipedia (русская и английская). Если оставить только значимые для нас подробности, то файл BMP выглядит следующим образом:
Упрощенная структура файл BMP
Где Bitmap File Header – это структура следующего вида:
Здесь важно, что
- поле bfType должно всегда иметь значение «BM» — это та самая сигнатура на основе которой мы задавали шаблон GREP в прошлой статье;
- bfSize содержит полный размер файла;
- bfReserved1 и bfReserved2 должны содержать нули в текущих версиях формата;
- bfOffBits — содержит смещение к данным изображения.
Благодаря заголовку мы можем:
- определить начало BMP файла, проверив значение bfType, bfReserved1 и bfReserved2;
- узнать полный размер файла из поля bfSize;
Далее идет DIB Header. В зависимости от версии формата это могут быть разные структуры, но все они достаточно похожи, рассмотрим BITMAPINFOHEADER:
С помощью полей этой структуры можно выполнить дополнительные проверки, которые снизят шанс ложного срабатывания:
- biSize — содержит точный размер структуры BITMAPINFOHEADER;
- biBitCount – количество бит используемых для хранения одного пикселя, не может быть произвольным, а только из множества [0, 1, 4, 8, 16, 24, 32];
и так далее.
Большую часть файла занимают данные изображения. В большинстве случаев, это несжатые данные. Цвет каждого пикселя кодируется определенным числом бит, а затем они записывают последовательно друг за другом. Это, к сожалению, означает, что данные могут быть произвольными и их проверить никак нельзя.
Подведем итог. Формат BMP позволяет достаточно точно находить начало файлов и точно определять их полный размер, даже для поврежденных файлов. Но нет возможности узнать целый файл или нет, а также узнать размер валидной части, если он поврежден.
Формат PNG
PNG – еще один формат хранения растровых изображений, но уже со сжатием (но без потери качества как в jpeg). Его спецификацию можно найти на сайте W3C. Она занимает не один десяток печатных страниц. Однако, для восстановления данных достаточно знать совсем немного.
Любой файл PNG начинается с последовательности из 8 байт: 89 50 4E 47 0D 0A 1A 0A.
Затем идет последовательность chunk’ов — кусочков на которые разбит весь png файл.
Упрощенная структура файла PNG
Структура chunk’а:
Структура PNG Chunk
То есть, для каждого chunk’а указаны:
- размер данных chunk, если пустой, то это 0;
- тип – 4 ASCII символа;
- собственно данные chunk’а, если есть;
- контрольная сумма, которая рассчитывается для Chunk Type и Chunk Data.
И последнее, что нужно знать —последовательность chunk’ов не может быть произвольной. В спецификации приведены 2 схемы следования chunk’ов друг за другом:
Последовательность chunk’ов с PLTE
Последовательность chunk’ов без PLTE
Внутри прямоугольника записан тип chunk’а. Черта «|» означает, что должен быть или один или другой chunk. А символы сверху обозначают сколько раз он может встречаться:
А символы имеют следующие значения:
- + – один или несколько раз;
- 1 – только один раз;
- ? – ноль или один раз;
- * – ноль или несколько раз.
Такой формат очень удобен для поиска и проверки файла:
- легко определить начало файла по первым 8 байтам;
- файл целый, если собралась корректная последовательность chunk’ов с корректными контрольными суммами, иначе файл поврежден;
- если файл целый, то мы знаем его размер — от начала до IEND включительно;
- если последовательность не собралась – файл поврежден, но размер его валидной части больше или равен смещению до конца последнего валидного chunk’а.
В отличии же от формата BMP, для поврежденного файла нельзя узнать его полный размер.
С каким размером сохранять найденные файлы?
Мы разобрались с тем, какие возможности для восстановления данных заложены в форматах BMP и PNG. Рассмотрим теперь различные случаи с целыми и поврежденными файлами. Это поможет нам правильно интерпретировать результаты поиска.
При поиске по шаблону GREP мы выставляли размер до следующего найденного заголовка, другого способа узнать размер у нас не было. Анализ структуры может дать больше информации, но и логика принятия решения здесь сложнее.
Когда мы находим файл BMP, мы имеем информацию только о его полном размере и можем проверить лишь небольшую часть в начале.
Файл BMP
Нельзя ручаться за данные, которые находятся после проверенного размера. Если файл, например, фрагментирован, то следующий заголовок может быть найден уже внутри «полного размера»:
Поврежденный файл BMP
В этой ситуации размер файла при сохранении из режима ограничивается смещением до следующего заголовка, чтобы наверняка захватить целую часть (ее мы не можем определить автоматически).
Если внутри «полного размера» других заголовков не найдено, то он и будет использован, т.к. сохранять больше данных нет смысла. Возможно это целый файл, для которого схема будет выглядеть уже так:
Целый файл BMP
Если мы нашли целый PNG файл, то все очень просто. Мы проверили его от начала до конца, знаем его размер и уверены, что он целый.
Целый файл PNG
Более сложная ситуация, если PNG файл поврежден.
Поврежденный файл PNG
Нам не удалось проверить очередной chunk, поэтому известно, что файл поврежден. Проверенный размер будет покрывать все целые chunk’и. Целая часть может оказаться больше. Файл будет сохранен до следующего заголовка, т. к. полный размер неизвестен (его можно получить только проверив успешно файл до конца).
Форма «чернового восстановления»
Форма режима «черновое восстановление»
С помощью анализа структуры мы можем получить значительно больше информации чем при простом поиске по шаблонам GREP. Рассмотрим как она отображается на форме чернового восстановления.
Панель категорий
В «черновом восстановлении» файлы ищутся как с помощью шаблонов GREP, так и с помощью анализа структуры. Поле GREP на панели с категориями заполнено только у первых.
Панель с результатами
Записи на панели с результатами тоже отличаются.
- Если мы можем ответить целый файл или нет, то возле него будет отображена цветная отметка: зеленая — для целых, красная — для поврежденных.
- В поле Size хранится размер, с которым файл будет сохранятся («размер при сохранении»). Выше мы рассмотрели как он выбирается для разных случаев.
- Поле Checked Size содержит «проверенный размер». В дальнейшем мы рассмотрим где можно применять эту информацию.
- Поле Comment содержит комментарий, содержание которого зависит от конкретного формата файла. Для изображений BMP и JPG отображается высота и ширина картинки, а для загрузочного сектора NTFS (Boot NTFS) размер раздела и кластера.
Панель метаданных
В режиме есть панель «метаданные», в нее попадает различная полезная информация, полученная при анализе файла по структуре. Например, для Boot NTFS (на скриншоте) можно узнать размер раздела, размер кластера, кластер с MFT0 и его копией.
Пример с картой памяти из фотоаппарата
В прошлой статье был пример с отформатированной картой памяти. Тогда мы не использовали анализ внутренней структуры файлов. Теперь выполним поиск с параметрами по-умолчанию.
Результаты выполнения «чернового восстановления»
Мы нашли такое же количество файлов JPEG. Однако результата стал намного более наглядным и точным:
- у файлов появилась отметка целостности; с помощью фильтра можно отобрать и сохранить только целые файлы;
- у целых jpeg’ов размер определен с точный размер до байта, а не до следующего заголовка как при поиске GREP;
- заполнено поле comment и появились «Метаданные», из них можно узнать размер изображения, модель камеры, дату съемки и пр.
Заключение
На примере форматов BMP и PNG мы разобрали как в «черновом восстановлении» ищутся файлы на основе знаний о структуре. Очевидно, что такой подход дает намного более качественный результат, чем поиск с помощью регулярных выражений. Но алгоритмы проверки — это часть комплекса, и их нельзя добавить также легко как очередной шаблон GREP.
Изначально, режим «черновое восстановление» разрабатывался как последний рубеж при восстановлении данных. Он применялся лишь в тех случаях, когда остальные методы не дали удовлетворительных результатов. Но с развитием комплекса режим стал находить все больше применений при решении самых разных задач. О них мы обязательно напишем в следующих статьях.
Леоненко Александр
Разработчик Data Extractor
Практическая стеганография. Скрытие информации в изображениях PNG / Блог компании VDSina.ru — хостинг серверов / Хабр
На хакерских конкурсах и играх CTF (Capture The Flag) иногда попадаются задачки на стеганографию: вам дают картинку, в которой нужно найти скрытое сообщение. Наверное, самый простой способ спрятать текст в картинке PNG — прописать его в одном из цветовых каналов или в альфа-канале (канал прозрачности). Для выявления подобных «закладок» есть специальные инструменты, такие как stegsolve, pngcheck и stegdetect, иногда конкурсантам приходится вручную повозиться с фильтрами в GIMP или Photoshop.
Однако прогресс не стоит на месте — и в последнее время всё чаще используются другие способы скрытия данных, например, PNG-наполнение. Посмотрим, как это делается.
Начнём с небольшого теоретического введения по «невидимым» частям PNG.
На экране компьютера при отображении картинки цвета создаются сочетанием красного, зелёного и синего компонентов. Эти три цветовые плоскости называются каналами. Обычно они записываются как RGB.
Кроме этих трёх каналов, в PNG может быть ещё четвёртый канал, называемый альфа (обозначается буквой А) для определения уровня прозрачности. Полученное изображение RGBA определяет видимые цвета и степень прозрачности.
В большинстве графических форматов альфа-канал является значением от 0% до 100% (или от 0 до 255 в байтах). Значение 0% (чёрный) обозначает место на изображении, где должна быть полная прозрачность — тут значение RGB игнорируется, и полностью виден фон под картинкой. Значение альфа-канала 100% (белый) означает, что каналы RGB полностью непрозрачны. Промежуточные значения определяют, насколько нужно смешать фон со значением RGB-пикселя.
Альфа-градиент в PNG
Значения альфа-градиента обычно используются для наложения изображения на другое изображение или на веб-страницу. Альфа-градиенты есть в PNG, WebP, ICO, ICN и других растровых форматах. Формат GIF поддерживает только логическое значение (пиксель либо прозрачен, либо нет).
Альфа-канал — только один из вариантов для размещения скрытого текста. Переходим к PNG-наполнению (padding) для прямой записи данных в бинарный файл.
Формат PNG достаточно прост. Каждый файл начинается с восьми стандартных байт подписи, вот её десятичные значения: 137 80 78 71 13 10 26 10
. Первый байт выбран за пределами ASCII, чтобы никакой редактор случайно не принял изображение за текстовый файл. Следующие три байта соответствуют буквам P, N, G. Затем разрыв строки DOS (13 10), маркер DOS окончания файла (26), чтобы программа type не выдавала весь бинарный мусор, и маркер Unix новой строки.
После заголовка начинаются блоки данных (chunks) со стандартной структурой. Сначала идёт блок IHDR с указанием ширины и высоты изображения, цветового пространства, количества бит на пиксель, методом сжатия, методом фильтрации и указанием наличия/отсутствия чересстрочного кодирования. Для ширины и высоты выделено по четыре байта, для остальных параметров — по одному байту.
Затем следует опциональный блок tEXt с текстовыми метаданными, например, с названием программы, которая сгенерировала данный файл PNG. В текстовые блоки можно записывать текстовую информацию в открытом виде.
За IHDR и tEXt следуют блоки IDAT со сжатыми значениями RGB или RGBA для растровых пикселей. При рендеринге PNG обрабатывается IHDR, выделяется буфер в памяти для изображения, данные извлекаются из сжатого формата и попиксельно записываются в буфер. Файл PNG завершается блоком IEND.
В конце каждого блока записана контрольная сумма CRC для этого блока, которая вычисляется по стандартному алгоритму.
Обычно изображения PNG содержат 8 или 16 бит информации на каждый канал RGB или RGBA, то есть выходит от трёх до восьми байт на пиксель. В таком формате все байты заняты полезной информацией о цвете и прозрачности, так что в конце каждой строки графического изображения у нас нет места для записи произвольных данных.
Но для задач стеганографии нужно знать, что PNG поддерживает и меньшую глубину цвета: 1 бит (2 цвета), 2 бита (4 цвета) и 4 бита (16 цветов). В такой ситуации получается, что в одном байте хранится информация о нескольких пикселях. Вот здесь и появляется теоретическая возможность для «горизонтального» наполнения PNG посторонними данными. Если ширина картинки в пикселях не кратна восьми, то в последнем байте строки остаётся неиспользуемые биты, которые все вместе формируют целый неиспользуемый «столбец пикселей».
В случае 1-битного изображения в конце каждой строки может остаться до 7 свободных бит, которые не будут обработаны парсером. В случае 2-битного изображения в последнем байте остаётся до 3 свободных бит. Онлайновый инструмент FotoForensics находит такие неиспользуемые «столбцы пикселей» в изображениях PNG.
Впрочем, PNG-картинки с малой глубиной цвета встречаются очень редко, поэтому и данный метод стеганографии можно считать экзотикой. Если вам попалось PNG-изображение с 2, 4 или 16 цветами, один этот факт уже вызывает подозрение и может инициировать проверку PNG-наполнения по столбцам.
Совсем другое дело — PNG-наполнение за границами картинки. Это более простой метод стеганографии, который позволяет спрятать в изображении гораздо больше информации.
PNG-наполнение за границами картинки (post-pixel padding) часто используется в различных играх, головоломках и конкурсах, не только хакерских. Вот как работает этот метод:
- Берём изображение PNG (с любой глубиной цвета).
- Вставляем секретную информацию в нижнюю часть картинки.
- Сохраняем PNG, не используя чересстрочное кодирование.
- Открываем файл в hex-редакторе.
- Находим блок IHDR. Он располагается в начале файла после восьми обязательных байт подписи и помечен как IHDR.
- Первые четыре байта после метки IHDR — это ширина файла, следующие четыре байта — высота. Уменьшаем это значение c
00 00 01 9D
(413 пикселей), например, до00 00 01 7E
(382 пикселя). - Не забудьте пересчитать четыре байта CRC (в формате PNG вычисляется значение CRC для каждого блока данных, в том числе для IHDR), которые записаны в конце блока. Если вы не можете посчитать CRC самостоятельно, посмотрите это значение в любом PNG-файле с аналогичными значениями блока IHDR.
Получаем результат.
Обратите внимание, что секретные данные остались в нижней части изображения. Размер файла не изменился: 335 906 байт. Просто парсер теперь не обрабатывает эти пиксели — и нижняя часть картинки не демонстрируется на экране.
Несложно догадаться, что в «секретной» части картинки можно спрятать не только текстовую надпись, но и произвольные данные. Например, мы можем записать туда запароленный архив RAR. Картинка с секретным посланием может быть опубликована на Habrastorage или любом другом общедоступном хостинге. Послание получит только тот человек, с которым вы заранее договорились о способе передачи информации и согласовали пароль. Таким способом вредоносные программы могут передавать полезную нагрузку через Хабр и другие общедоступные хостинги.
На правах рекламы
VDS для размещения сайтов — это про наши эпичные! Все серверы «из коробки» защищены от DDoS-атак, автоматическая установка удобной панели управления VestaCP. Лучше один раз попробовать 😉
PNG формат: особенности, плюсы и минусы | Дизайн, лого и бизнес
На настоящий момент формат PNG, расшифровывающийся как Portable Network Graphics – один из популярнейших растровых форматов в сфере веб-дизайна. Решение о разработке было принято в 1995 году на конференции, где обсуждалась необходимость создания аналога GIF-формата. Так как последний подразумевал оплату соответствующей лицензии, предполагалось, что новый формат станет более доступным. В результате появился непатентованный PNG, ставший прославленному GIF достойным конкурентом. (О других графических форматах читайте здесь)
PNG: плюсы и минусы
Формат в основном используется для работы в интернете и в графических редакторах.
К его преимуществам относятся:
- Возможность сжатия файла с незначительными потерями или вовсе без них. Рисунок сохраняет исходное качество вне зависимости от интенсивности сжатия;
- Возможность сколько угодно сохранять объект в процессе работы, а потом видоизменять снова. Изначальное качество не меняется;
- Цветовой диапазон формата шире, нежели у GIF. PNG-8 работает с 256 цветами, PNG-24 – с 16,7 млн. цветов;
- Поддержка альфа-канала. Эта функция позволяет плавно сочетать изображение с фоном за счет уменьшаемой прозрачности. Уровни прозрачности по количеству соответствуют доступным цветам и могут варьироваться от предельной контрастности до полного растворения;
- Возможность создания и комбинирования слоев;
- Доступность включения в материал метаданных (при необходимости сохранения авторской информации).
- Компактный размер изображений.
В числе недостатков можно выделить:
- Отсутствие режима анимации;
- Затруднения при работе с полноцветными типами изображений;
- Невозможность сохранять в одном файле сразу несколько рисунков (попытки добавить формату эту функцию предпринимались, но пока не получили всеобщего признания).
Из списка преимуществ становится ясно, чем PNG в первую очередь привлекает интернет-дизайнеров. Его «изюминка» – возможность сохранить картинку на вырезанном (прозрачном) фоне. Такая функция очень важна при работе с сайтами, дизайном продукции. В частности, большинство логотипов создаются именно в формате PNG, поскольку являют собой фигурное изображение без фона. (Подробнее про виды логотипов читайте в нашей статье)
Сфера применения
Логотипы – лишь частный пример того, как может использоваться формат. Элементы с прозрачным фоном необходимы для оформления веб-страниц, создания эффектного текста, объемных и рельефных изображений, при различных техниках печати и гравировки. Фактически этот формат применяется во всех сферах дизайна, где необходимо наличие прозрачного фона и возможность трансформировать рисунок без потери качества.
Создайте логотип за 5 минут
Нажмите кнопку «Создать» и мы бесплатно создадим варианты логотипа, на основе которых можно разработать фирменный стиль.
Твитнуть
Поделиться
Поделиться
Отправить
Класс!
Отправить
Другие статьи
Оптимизация без потери качества: PNG
Последние несколько месяцев в Айри прошли в напряженном поиске и отборе лучших решений для уменьшения размера файлов. Размер веб-страниц постоянно увеличивается, и изображения занимают существенную часть в суммарном объеме загружаемых данных.
Чтобы понимать, как именно изображения для веб-страниц могут быть оптимизированы, нужно разобраться в структуре файлов изображений. Мы начнем с PNG.
Структура PNG файлов
PNG-файл, в первом приближении, состоит из заголовков (чанков), содержащих служебную информацию (в том числе, и информацию о цветовой схеме), палитре (в случае использования индексированных цветов), фильтров и цветовых данных (преобразуемых через фильтры). Это накладывает следующие ограничения на возможности оптимизации файла:
- Можно удалить неиспользуемые для отображения файла на веб-страницах чанки.
- Можно уменьшить или преобразовать палитру файла для лучшего сжатия.
- Можно использовать другую комбинацию фильтров, позволяющих записать цветовую информацию, используя меньшее количество байт.
- Можно использовать другие алгоритмы сжатия информации в заголовках, палитре, фильтрах и цветовых данных.
В связи с этим все инструменты оптимизации PNG разбиваются на 4 группы:
- Для удаления ненужных чанков из файла.
- Для квантования / кластеризации / упорядочивания палитры (как реализовать кластеризацию палитры). Любое уменьшение палитры относится к техникам с потерями качества изображения, но визуально изображение может быть почти неотличимо от оригинала. Упорядочивание палитры улучшает ее последующее сжатие, на качество изображения не влияет. Также для оптимизации может быть применено перевод неиндексируемого изображения (с небольшим количеством цветов) в индексируемое.
- Для подбора наиболее оптимальных фильтров для изображения.
- Для максимального сжатия всех частей файла.
Если ориентироваться на достаточно подробный разбор инструментов оптимизации PNG, то можно выделить наиболее эффективные утилиты для выполнения тех или иных операций с PNG-файлами:
Утилиты для оптимизации PNG
Удаление чанков из изображения поддерживают почти все утилиты, для этой цели в равной мере подойдут pngout или TruePNG. Также хорошая утилита для работы с чанками в графических файлах — это exiftool.
Для квантования/постеризации лучше всего подойдут pngquant, pngnq-s9 или TruePNG. Преобразования палитры без потери качества выполняют pngoptimizer, pngrewrite и TruePNG.
В области подбора наилучших алгоритмов фильтрации изображений лучше всего справляются TruePNG и pngwolf. Поскольку используются разные алгоритмы, то лучшего эффекта можно добиться, комбинируя оба инструмента.
Наконец, для максимального сжатия изображения лучше всего использовать PNGZopfli или ZopfliPNG.
Подводя итог, лучшей комбинацией инструментов для комплексной оптимизации PNG-файлов на текущий момент является TruePNG, pngwolf и ZopfliPNG.
Для Мака можно использовать связку ImageAlpha и ImageOptim.
Все-в-одном
Для использования в рабочем процессе указанных утилит лучше всего подойдет пакет Image Catalyst — он автоматизирует почти все описанные техники оптимизаций для работы над группой файлов.
Для удобства пользователей облака Айри мы внедрили оптимизацию всех изображений на постоянной основе. Некоторые техники оптимизации небезопасны для финального результата, поэтому они вынесены в настройку «Продвинутая», которая работает с тарифного плана Марс.
В среднем, уменьшение размера изображений позволяет сократить размер изображений на 35-50%, это очень значительное достижение для скорости сайта, и может быть выполнено полностью автоматически при подключении сайта к Айри.
PNG Спецификация: файловая структура
PNG Спецификация: файловая структура
REC-png.html
Рекомендация W3C 01 октября 1996 г.
Предыдущая страница
Следующая страница
Содержание
Файл PNG состоит из подписи PNG , за которой следует ряд
из кусков . В этой главе определяется подпись и основные
свойства чанков. Отдельные типы блоков обсуждаются в
Следующая глава.
3.1. Подпись файла PNG
Первые восемь байтов файла PNG всегда содержат следующие
(десятичные) значения:
137 80 78 71 13 10 26 10
Эта подпись указывает, что оставшаяся часть файла содержит
одно изображение PNG, состоящее из серии фрагментов, начинающихся с
фрагмент IHDR и заканчивается фрагментом IEND.31) -1 байт.
при изучении файлов PNG, коды типов могут состоять только из прописных букв.
и строчные буквы ASCII (A-Z и
a-z, или 65-90 и 97-122 в десятичной системе счисления). Однако,
кодеры и декодеры должны обрабатывать коды как фиксированные двоичные значения,
не символьные строки. Например, было бы неправильно
представляют код типа IDAT эквивалентами EBCDIC
эти буквы. Дополнительные соглашения об именах для типов блоков:
обсуждается в следующем разделе.
Это поле может быть нулевой длины.
на предыдущих байтах в блоке, включая код типа блока и
поля данных блока, но не включая
поле длины. CRC присутствует всегда, даже для
чанки, не содержащие данных.
См. Алгоритм CRC.
Длина данных блока может составлять любое количество байтов до максимального;
поэтому разработчики не могут предполагать, что чанки выровнены по какому-либо
границы больше байтов.
Чанки могут появляться в любом порядке, с учетом ограничений, наложенных на
каждый тип чанка. (Одно заметное ограничение заключается в том, что IHDR должен
появляются первым, а IEND — последним; Таким образом
Блок IEND служит маркером конца файла.) Несколько блоков
того же типа, но только если это специально разрешено для
тот тип.
См. Обоснование:
Макет чанка.
3.3. Соглашения об именах блоков
Коды типа блока назначаются так, чтобы декодер мог
определить некоторые свойства блока, даже если он не распознает
введите код.Эти правила предназначены для безопасного и гибкого расширения
формата PNG, позволяя декодеру решать, что делать, когда он
встречает неизвестный кусок. Правила именования обычно не соответствуют
Интересно, когда декодер распознает тип блока.
Четыре бита кода типа, а именно бит 5 (значение 32) каждого байта, являются
используется для передачи свойств чанка. Этот выбор означает, что человек может
считать присвоенные свойства в зависимости от того, каждая ли буква
код типа в верхнем регистре (бит 5 равен 0) или нижнем регистре (бит 5 равен 1).Однако декодеры должны проверять свойства неизвестного фрагмента путем
численное тестирование указанных битов; проверка, есть ли у персонажа
в верхнем или нижнем регистре неэффективно и даже неверно, если
Используется определение регистра, зависящее от локали.
Стоит отметить, что биты свойств являются неотъемлемой частью
имя блока, и, следовательно, фиксированы для любого типа блока. Таким образом,
ТЕКСТ и текст будут несвязанными типами блока
коды, а не один и тот же кусок с разными свойствами. Декодеры должны
распознавать коды типов простым четырехбайтовым буквальным сравнением; это
некорректно выполнять преобразование регистра для кодов типов.
Семантика битов свойств:
- Вспомогательный бит: бит 5 первого байта
- 0 (верхний регистр) = критический, 1 (нижний регистр) = вспомогательный.
Фрагменты, которые не являются строго необходимыми для значимого
отображение содержимого файла называется «вспомогательными» фрагментами.
Декодер обнаруживает неизвестный фрагмент, в котором вспомогательный бит
равно 1, можно спокойно игнорировать фрагмент и перейти к отображению изображения. В
фрагмент времени (tIME) является примером вспомогательного фрагмента.Чанки, необходимые для успешного отображения файла
содержимое называется «критическими» блоками. Декодер обнаруживает
неизвестный фрагмент, в котором вспомогательный бит равен 0, должен указывать на
пользователю, что изображение содержит информацию, которую нельзя безопасно интерпретировать.
Блок заголовка изображения (IHDR) является примером критического блока. - Частный бит: бит 5 второго байта
- 0 (верхний регистр) = общедоступный, 1 (нижний регистр) = частный.
Публичный блок — это блок, который является частью спецификации PNG или
зарегистрированы в списке общедоступных типов блоков специального назначения PNG.Приложения также могут определять частные (незарегистрированные) блоки для своих
собственные цели. Имена частных чанков должны быть в нижнем регистре.
вторая буква, в то время как публичным чанкам всегда будут назначаться имена с
заглавные вторые буквы. Обратите внимание, что декодерам не нужно проверять
бит свойства private-chunk, поскольку он не имеет функционального значения;
это просто административное удобство для обеспечения того, чтобы общественные и
частные имена чанков не конфликтуют. Видеть
Дополнительные типы чанков
и рекомендации для энкодеров:
Использование приватных чанков. - Зарезервированный бит: бит 5 третьего байта
- В файлах, соответствующих этой версии PNG, должен быть 0 (верхний регистр).
Значение регистра третьей буквы имени блока:
зарезервировано для возможного будущего расширения. В настоящее время все чанк
имена должны содержать третьи буквы в верхнем регистре. (Декодеры не должны
однако жалуются на третью букву в нижнем регистре, поскольку в некоторых будущих версиях
спецификации PNG может определять значение этого бита. это
достаточно для обработки фрагмента с третьей строчной буквой в том же
как и любой другой неизвестный тип чанка.) - Бит Safe-to-copy: бит 5 четвертого байта
- 0 (верхний регистр) = копировать небезопасно, 1 (нижний регистр) = безопасно копировать.
Этот бит свойства не представляет интереса для чистых декодеров, но он
необходимы редакторам PNG (программам, изменяющим файлы PNG). Этот бит
определяет правильную обработку нераспознанных фрагментов в файле, который
модифицируется.Если бит безопасной копии фрагмента равен 1, фрагмент может быть скопирован в
измененный файл PNG независимо от того, распознает ли программа фрагмент
типа, и независимо от степени модификации файла.Если бит безопасной копии фрагмента равен 0, это означает, что фрагмент
зависит от данных изображения. Если программа сделала любое
изменения в критических блоков, включая добавление, модификацию,
удаление или изменение порядка критических фрагментов, затем нераспознанных небезопасных
фрагменты должны быть скопированы в выходной файл PNG , а не .
(Конечно, если программа распознает фрагмент,
он может выбрать вывод соответствующим образом измененной версии.)Редактору PNG всегда разрешено копировать все нераспознанные фрагменты, если он
только добавил, удалил, изменил или переупорядочил вспомогательных фрагментов .Это означает, что вспомогательные блоки не могут
зависят от других вспомогательных частей.Редакторы PNG, которые не распознают критический фрагмент , должны
сообщить об ошибке и вообще отказаться от обработки этого файла PNG. В
Безопасный / небезопасный механизм предназначен для использования с дополнительными блоками.
Бит безопасного копирования всегда будет равен 0 для критических фрагментов.Правила для редакторов PNG обсуждаются далее в
Правила упорядочивания фрагментов.
Например, имя гипотетического типа блока «bLOb» имеет
биты собственности:
bLOb <- 32-битный код типа чанка, представленный в текстовой форме |||| ||| + - Бит безопасного копирования равен 1 (строчная буква; бит 5 равен 1) || + - Зарезервированный бит равен 0 (заглавная буква; бит 5 равен 0) | + --- Частный бит равен 0 (заглавная буква; бит 5 равен 0) + ---- Вспомогательный бит равен 1 (строчная буква; бит 5 равен 1)
Следовательно, это имя представляет собой вспомогательный, общедоступный, безопасный для копирования фрагмент.31 год
срок.
Практический расчет CRC всегда использует предварительно рассчитанный
таблица, чтобы значительно ускорить вычисления. Видеть
Пример кода CRC.
Предыдущая страница
Следующая страница
Содержание
.
Структура PNG изображения | Векторные и PSD файлы
структура молекулы формы s и t
1200 * 1200
структура человеческого мозга
1200 * 1200
днк структурные элементы цепочки в виде сфер
1200 * 1200
молекулярные структурные элементы косметической текстуры ДНК
1200 * 1200
структура мозга нервная система анатомия человеческая схема медицина векторная иллюстрация
4167 * 4167
глянцевый синий структура спирали ДНК 3d элемент
1200 * 1200
голубая сфера молекулярная структура 3d элемент
1200 * 1200
структура молекулы ДНК атом нейроны научный фон для медицины наука технология иллюстрация молекулы химии на синем фоне с копией пространства для вашего текста
1200 * 1200
3000 * 3000
структура человеческого тела
1200 * 2025
розовая ДНК молекулярная структура косметические элементы
1200 * 1200
синяя структурная химическая молекула
3000 * 3000
рисованная диаграмма структуры человеческого органа почки вектор свободный материал
2000 * 2000
структура глаза иллюстрация глазного яблока
2500 * 2500
градиент многоцветный структура сфера
14173 * 14173
абстрактная синяя структура
14173 * 14173
абстрактная футутристическая структура спирали ДНК генетика биология наука
молекула 1200 * 1200
15 00 * 1500
позвоночник структура человеческого тела
2999 * 4000
технологическая смысловая молекулярная структура
2492 * 2908
медицинская структура человеческого тела органы
2000 * 3500
4476 * 4476
абстрактная геометрическая 3d структура сплетения изолированные многоугольные формы связаны концепция декоративные объекты в футуристическом стиле
8000 * 8000
структура компания сотрудничество группа иерархия люди команда
5556 * 5556
абстрактный круговой технологический фон
800 * 800
раскрашенная вручную иллюстрация атомной структуры образования
2048 * 2048
реклама стирального порошка
800 * 8
синий молекулярная структура
1200 * 1200
реальный выстрел внутренней структуры маракуйи фрукты
3000 * 3000
красочный дым темно-красный
3000 * 3000
реалистичная 3d структура коронавируса
1200 * 1200
медицинская структура человека
2000 * 3500
бесплатные структуры PNG изображения | Векторные и PSD файлы
желтый абстрактный цвет рамки бесплатно png и psd
2500 * 2500
официальная одежда бесплатно png и psd
1200 * 1200
синий дым абстрактная рамка искусства бесплатно png и psd
2500 * 2500
официальная одежда бесплатно png
1200 * 1200
последний векторный баннер для видео png скачать бесплатно
1200 * 1200
/ourmid/pngtree-gold-glitter-background-border-png-png-image_563425.jpg" alt="gold glitter background png png free download, Glitter, Gold, Golden PNG and Vector"/>
золотой блеск фон png png скачать бесплатно
1905 * 1905
ночь розовый фон png скачать бесплатно
1200 * 1200
векторный дизайн баннера png скачать бесплатно
1200 * 1200
исламский фон люстра лампа ид аль адха png скачать бесплатно
1200 * 1200
красочный дым абстрактная рамка бесплатно
25 00 * 2500
красочный фон брызги краски png скачать бесплатно
1200 * 1200
тропических пальмовых листьев png скачать бесплатно
1200 * 1200
оранжевый png png скачать бесплатно
2000 * 2000
значок whatsapp логотип whatsapp значок whatsapp бесплатный шаблон
800 * 800
красные волнистые формы на прозрачном фоне png и векто png скачать бесплатно
2000 * 2000
логотип камеры бесплатно шаблон дизайна
1200 * 1200
свободная красная стрелка для вытягивания элементов
1200 * 1200
свободная творческая тяга
1200 * 1200
бесплатная нижняя третья новостная лента
1200 * 1200
оранжевый логотип samurai esports для игрового талисмана или дизайн логотипа без подергивания шаблон
1200 * 1200
png свободная пряжка градиент современная геометрическая квадратная граница геометрическая форма неправильная геометрическая граница
2000 * 2000
плавающее падающее перо png скачать бесплатно
1200 * 1200
современные этикетки с бесплатной доставкой
4076 * 4076
вишневый цветок вектор png скачать бесплатно
800 * 800
социальные сети YouTube видео png скачать бесплатно
1200 * 1200
огонь шаблон дизайна логотипа вектор бесплатно шаблон дизайна логотипа
4167 * 4167
векторный дизайн баннера лента фотошоп png скачать бесплатно
1200 * 1200
бесплатно скачать вектор инфографики
1200 * 1200
1200 * 1200
красочный цветочный дизайн границы png скачать бесплатно
1200 * 1200
рисовать монограммы и границы бесплатно дизайн шаблона
1200 * 1200
логотип бомбардировщика череп киберспорт талисман шаблон бесплатный шаблон дизайна логотипа
1200 * 1200
ресницы дизайн логотипа вектор бесплатный шаблон дизайна логотипа
4167 * 4167
красочный цветочный дизайн границы png скачать бесплатно
1200 * 1200
1200 * 1200
расплавленный ф png скачать бесплатно
1200 * 1200
структурированных изображений PNG | Векторные и PSD файлы
структура молекулы днк атом нейроны научный фон для медицины наука технология иллюстрация молекулы химии на синем фоне с копией пространства для вашего текста
1200 * 1200
ДНК структурные элементы цепи, такие как сферы
1200 * 1200
молекулярные структурные элементы косметической текстуры ДНК
1200 * 1200
структура мозга анатомия нервной системы человека схема медицины векторная иллюстрация
4167 * 4167
медицинские органы структуры человека
2000 * 3500
структура молекулы днк атом нейроны научный фон для медицины наука технология иллюстрация молекулы химии на синем фоне с копией пространства для вашего текста
1200 * 1200
днк структурная диаграмма элементы красоты
9000 4 1200 * 1200
молекулярная структура карбонат кальция caco3 вектор
5000 * 5000
косметические элементы с молекулярной структурой розовой ДНК
1200 * 1200
комбинация сферических элементов с молекулярной структурой ДНК
1200 * 1200
синяя структурная химическая молекула
3000 * 3000
диаграмма структуры химической ДНК
2480 * 3508
структура глаза иллюстрация глазного яблока
2500 * 2500
днк структурные косметические элементы
1200 * 1200
градиентная многоцветная структура сфера
14173 * 14173
зубной имплант вектор структура имплантата коронка абатмент винт реалистичная изолированная иллюстрация
5000 * 5000 90
5000 * 5000
ab синяя структура
14173 * 14173
абстрактная векторная структура ДНК медицинская наука фон
1200 * 1200
физика молекулярной структуры биология малая молекула
1500 * 1500
2000 * 2000
Структура человеческого тела
2999 * 4000
Голубая сфера молекулярная структура 3d элемент
1200 * 1200
квадратная белая фоторамка тень на прозрачном
4476 * 4476 * 44
Глянцевая синяя структура спирали ДНК 3-й элемент
1200 * 1200
Исследования молекулярной структурной биологии
2480 * 3508
абстрактный круговой технологический фон
800 * 800
800 * 800
день независимости 75 тахун индонезия мерд eka
2100 * 2100
Раскрашенная вручную иллюстрация атомной структуры образования
2048 * 2048
медицинская структура человека
2000 * 3500
красочный дымчатый
3000
красочный дым
3000
металлическая ДНК 3d структура
1200 * 1200
дом недвижимость недвижимость здание логотип вектор
3338 * 3338
абстрактные градиентные сетки волны 3d каркас технологии волнистых форм и футуристические декоративные объекты
5000 * 5000
абстрактные геометрические фигуры
1200 * 1200
структура человеческого тела
1200 * 2025
векторный сетевой фон абстрактный многоугольник
1200 * 1200
штриховка химической структуры
2000 * 2000
структура молекулы формы s и t
1200 * 1200
абстрактные цифровые технологии геометрические белые границы
800 * 800
вектор деревянный фон доски
800 * 800
.