Первоначально опубликовано на Что должен знать каждый разработчик о растровых изображениях (лучше отформатирован там с изображениями).
Практически каждый разработчик иногда использует растровые изображения в своих программах. Или, если не в их программировании, то на веб-сайте, в блоге или семейных фотографиях. Тем не менее, многие из нас не знают компромиссов между GIF, JPEG или PNG-файлами - и здесь есть некоторые существенные различия. Это короткий пост по основам, который будет достаточным для большинства, и хорошее начало для остальных. Большую часть этого я узнал как разработчик игр (вкл. Enemy Nations ), где вам нужно глубокое понимание графики.
Растровые изображения в основном сохраняют цвет каждого пикселя. Но есть три ключевых компонента:
- Сохранение самого значения цвета. Наиболее
из нас знакомы с RGB, где это
хранит красный, зеленый и синий
Компонент каждого цвета. Это
на самом деле наименее эффективный метод
как человеческий глаз может видеть тонкое
различия по некоторым частям
цветовая гамма больше, чем у других.
Это также неэффективно для многих
общие операции над цветом, такие как
проясняю это. Но это
самый простой для самых распространенных
задачи программирования и так стало
стандарт.
- Прозрачность
каждый пиксель. Это важно для
край непрямоугольных изображений.
диагональная линия, чтобы сделать лучше, будет
быть комбинацией цвета из
линия и цвет
базовый пиксель. Каждый пиксель нуждается
иметь свой уровень прозрачности
(или на самом деле непрозрачность) устанавливается от 0%
(показать базовый пиксель) до 100%
(показать только пиксель из
образ).
- Растровые метаданные. это
информация об изображении, которое
может варьироваться от таблицы цветов и
разрешение владельцу
изображение.
Сжатие
Растровые изображения занимают много данных. Или, если быть более точным, они могут занимать много байтов. Сжатие было основным драйвером новых растровых форматов на протяжении многих лет. Компрессия может быть трех видов: с уменьшением палитры, с потерями и без потерь.
В первые дни уменьшение палитры было наиболее распространенным подходом. Некоторые программы использовали растровые изображения, которые были черно-белыми, поэтому 1 бит на пиксель. Теперь это выдавливает это. И во времена Windows 3.1 16 цветных изображений (4 бит / пиксель) все еще широко использовались. Но основное использование было в случае 8-бит / 256 цветов для растрового изображения. Эти 256 цветов соответствовали бы палитре, которая была частью растрового изображения, и эта палитра содержала 24-битный цвет для каждой записи. Это позволило программе выбрать 256 цветов из полного спектра, который наилучшим образом отображал изображение.
Этот подход был довольно хорош и в основном не удался для плоских поверхностей, у которых был очень медленный переход по поверхности. Это также столкнулось с большой проблемой на ранних этапах работы с сетевыми и оконными операционными системами - потому что видеокарты были также 8-битными системами с единой палитрой для всего экрана. Это было хорошо для игры, которая владела целым экраном, но не для случаев, когда изображения из разных источников разделяли экран. Решением этой проблемы является создание стандартной веб-палитры, и большинство браузеров и т. Д. Используют эту палитру, если существует конфликт палитры.
Наконец, было несколько промежуточных решений, таких как 16 бит / пиксель, которые обеспечивали весь спектр, но с грубым уровнем детализации, где человеческий глаз мог видеть скачки в изменениях оттенка. Это нашло небольшое использование, потому что цены на память упали, а видеокарты быстро подскочили с 8-битных до 24-битных за год.
Далее идет сжатие с потерями. Сжатие - это поиск шаблонов, которые повторяются в файле, а затем во втором случае просто указывают на первый запуск. Что если у вас есть серия из 20 пикселей, в которой во втором прогоне единственное различие состоит в том, что два пикселя имеют более красную величину, равную 1? Человеческий глаз не может увидеть эту разницу. Таким образом, вы меняете второй прогон в соответствии с первым и вуаля, вы можете сжать его. Большинство схем сжатия с потерями позволяют установить уровень потерь.
У этого подхода есть одна серьезная проблема, когда вы используете один цвет для обозначения прозрачности. Если этот цвет сдвинут на один бит, он больше не будет прозрачным. Вот почему форматы с потерями использовались почти исключительно для изображений, а не в играх.
Наконец приходит без потерь. Это где программа сжимает сопли из изображения без потери информации. Я не собираюсь углубляться в то, что / как из этого, за исключением того, что я хочу подчеркнуть, что сжатие изображений занимает значительно больше времени, чем их распаковка. Так что отображение сжатых изображений - быстро. Сжатие изображений - не так быстро. Это может привести к ситуациям, когда по соображениям производительности вы не хотите хранить в формате без потерь на лету.
Прозрачность
Прозрачность поставляется в трех вариантах. (Если вы знаете художника, который создает веб-контент, попросите его прочитать этот раздел. Удивительно, сколько людей ничего не понимают в этом вопросе.) Первый вариант - нет - растровое изображение представляет собой прямоугольник и затемняет каждый пиксель под ним.
Вторым является растровое изображение, где обозначенное значение цвета (большинство используют пурпурный, но это может быть любой цвет) означает прозрачное. Таким образом, отображаются другие цвета, а пурпурные пиксели не отображаются, поэтому отображается основной пиксель. Это требует рендеринга изображения на выбранном цвете фона и краевых пикселей, которые должны быть частично изображением, а частично пикселем фона, а затем частично цветом фона. Вы видите это на практике с 256 цветными значками, где они имеют идеальные края на белом фоне, но имеют странный эффект белого ореола на своих краях на черном фоне.
Третий вариант - это 8 бит прозрачности (то есть 256 значений от 0 до 100%) для каждого пикселя. Это то, что подразумевается под 32-битной битовой картой, это 24-битный цвет и 8 бит прозрачности. Это обеспечивает изображение с более тонкими градациями, чем может различить человеческий глаз. Одно слово предупреждения при общении с художниками - все они могут создавать «32-битные растровые изображения». Но 95% из них производят те, в которых для каждого пикселя установлена непрозрачность 100%, и не имеют представления о всем процессе и необходимости прозрачности. (Художники игр - заметное исключение - они делают это вечно.) Для хорошего примера того, как сделать это правильно, взгляните на Icon Experience - я думаю, что их растровые изображения превосходны (мы используем их в AutoTag).
Разрешение
Многие форматы имеют разрешение, обычно обозначаемое как DPI (количество точек на дюйм). При просмотре фотографии это обычно не проблема. Но возьмите пример диаграммы, представленной как растровое изображение. Вы хотите, чтобы текст на диаграмме был читабельным, и, возможно, вы хотите, чтобы он печатался чисто на принтере с разрешением 600 точек на дюйм, но на экране вы хотите, чтобы 600 точек, которые занимают дюйм, отображаются с использованием всего 96 пикселей. Разрешение предоставляет эту возможность. DPI не существует в некоторых форматах и является необязательным в других (примечание: он не требуется ни в каком формате, но его обычно нет в PNG).
Важной проблемой DPI является то, что при рендеринге растрового изображения пользователю может потребоваться возможность увеличивать и / или печатать с разрешением принтера, но отображать с более низким разрешением - вам необходимо предоставить возможность вызывающей программе установить DPI. Есть очень мощная графическая программа, которая бесполезна, за исключением стандартного просмотра на мониторе - потому что она рендерится с разрешением 96 точек на дюйм, и все. Не ограничивайте свое использование.
Форматы файлов
Итак, какие форматы файлов вы должны использовать? Давайте перейдем от самого полезного к наименее полезному.
PNG - 32-битное (или менее) сжатие без потерь, небольшой размер файла - что не нравится. Более старые версии некоторых браузеров (например, Internet Explorer) отображали прозрачные пиксели не совсем белого цвета, но более новые версии обрабатывают это правильно. Используйте это (в 32-битном режиме, используя 8 бит для прозрачности) для всего.
ICO - Этофайл значков, используемый для представления приложений на рабочем столе и т. д. Это набор растровых изображений, каждое из которых может иметь любое разрешение и битовую глубину.Для их сборки он использует только 32-битные файлы png от 16x16 до 256x256.Если вашей операционной системе или приложению требуется меньшая битовая глубина, она уменьшится на лету - и сохранит 8 битов прозрачности.
JPEG - только 24-битный (т.е. без прозрачности), с потерями, маленькийразмеры файлов.Нет смысла использовать этот формат, если у вас нет значительного числа людей, использующих старые браузеры.Это неплохой формат, но он уступает PNG без каких-либо преимуществ.
GIF - 8-битный, с потерями, очень маленький размер файла.GIF имеет две уникальные особенности.Во-первых, вы можете поместить несколько растровых изображений GIF в один файл с задержкой, установленной между ними.Затем он будет проигрывать тех, кто дает вам анимированные растровые изображения.Это работает в любом браузере до версии 0.9 и имеет меньший размер файла, чем флэш-файл.С другой стороны, это всего лишь 8 бит, и в современном мире это выглядит плохо (хотя некоторые художники могут делать удивительные вещи всего с 8 битами).Он также имеет заданный цвет как прозрачный, поэтому он изначально поддерживает прозрачность (из вкл / выкл).Это полезно, если вам нужны анимированные растровые изображения без лишних затрат флэш-памяти или если пропускная способность является серьезной проблемой.
BMP (также называемый DIB) - от 1 до 32-битных файлов без потерь большого размера.Есть один случай, чтобы использовать это - когда скорость является первостепенной проблемой.Многие двумерные игровые программы, особенно до выпуска доступных сегодня графических карт, сохраняют все растровые изображения как BMP / DIB, поскольку не требуется распаковка и экономия времени является критической, когда вы пытаетесь отобразить 60 кадров в секунду для игры.
TIFF - любая битовая глубина, любое сжатие (с потерями или без потерь), все, включая кухонную раковину - и не лучше, чем PNG.По сути, правительство и некоторые крупные компании решили, что им нужен «стандарт», чтобы программное обеспечение в будущем все еще могло читать эти старые файлы.Весь этот аргумент не имеет смысла, так как PNG отвечает всем требованиям.Но для некоторых клиентов (например, федерального правительства) это TIFF вместо PNG.Используйте это, когда клиент запрашивает это (но в противном случае используйте PNG).
Все остальное - устарело.(Примечание: многие не согласны со мной по поводу того, что другие форматы меньше. Они есть, но память и дисковое пространство почти свободны.) Если вы создаете растровый редактор, то непременно поддержите чтение / запись всех форматов.Но для других целей - придерживайтесь указанных выше форматов 2 + 4.