Сжатие изображений

Само слово «сжатие» подразумевает некое обратимое преобразование исходных данных, в результате которого они начинают занимать меньший объем. Важно помнить, что далеко не все данные в принципе могут быть сжаты, ведь в противном случае мы бы могли, сжимая их несчетное множество раз, упаковать произвольную информацию в один бит, а впоследствии распаковать этот бит до изначального вида. А это, естественно, не так.

Для успешного сжатия информации в исходных данных должны прослеживаться закономерности и повторяющиеся элементы, за счет которых и достигается уплотнение при упаковке (выражаясь академически — в ней должна наблюдаться автокорреляция).

Способов упаковки — великое множество. Поэтому, вместо того чтобы перечислять их, я приведу простенькую классификацию, сопровождая ее примерами, затрагивающими тему статьи.

Для начала, компрессия бывает физическая и логическая. Логическая подразумевает понимание того, какие именно данные подвергаются сжатию, и смысловую замену одних информационных блоков на другие, более короткие. Типичный пример — вместо строки «Лучшие компьютерные игры» мы пишем аббревиатуру «ЛКИ». Смысл при этом не теряется, а длина строки сокращается во много раз. Применительно к графике логическая компрессия наблюдается во всех векторных форматах. Вместо того, чтобы описывать каждую точку линии, мы, имея в виду, что это именно линия, задаем координаты ее начала и конца, толщину и цвет. В итоге имеем ту же линию, заданную всего парой чисел, вместо огромного массива бессвязных точек, описанных по отдельности. Вот что представляет собой логическое сжатие. С физическим еще проще — это любые другие его виды.

Еще сжатие бывает универсальное и специализированное. В первом случае программа-архиватор не имеет ни малейшего понятия, какого рода данные ей предстоит упаковывать, и относится к ним просто как к набору произвольных байт. По таким алгоритмам работают любые архиваторы широкого профиля: RAR, ZIP, ARJ и т.п. Специализированные алгоритмы сжатия, наоборот, созданы для упаковки данных определенного типа. Разумеется, это точно такие же байты, как и любые другие, — ну нету в природе «графических» или «музыкальных» байтов. Тем не менее знание специфики позволяет предугадать и учесть многие закономерности, ею вызванные. В графических файлах, например, соседние пиксели очень часто близки по цвету. Следовательно, если хранить только разницу между ними, в большинстве случаев можно значительно сэкономить объем. Этой, а также еще сотней других особенностей и пользуются алгоритмы упаковки графики.

Естественно, специализированные компрессоры гораздо лучше справляются с упаковкой привычных им данных — в этом очень легко убедиться. Возьмем средних размеров фотографию и сохраним ее в BMP. А потом попробуем упаковать разными способами — с помощью универсальных архиваторов, а также средствами упаковки GIF 256 цветов и JPEG с минимальными потерями, и посмотрим на коэффициенты сжатия.
Степень сжатия в зависимости от способа упаковки.

Результат достаточно очевиден. RAR закономерно работает лучше ZIP, но ни один из универсальных архиваторов не дотягивает по эффективности до графических форматов сжатия.

Наконец, сжатие еще бывает с потерями и без потерь. Тут бытует еще одно популярное заблуждение, что сжатие с потерями синонимично некачественному, плохому сжатию в отличие от хорошего — которое, естественно, обходится без потери данных. Это утверждение в корне неверно. Потери при компрессии — явление полезное и преднамеренное. Зная специфику восприятия изображений человеческим глазом, программа-упаковщик сознательно «выбрасывает» несущественные, неразличимые глазом детали, за счет чего объем файла сокращается во много раз, а на вид картинка остается прежней. Именно по этому принципу работает алгоритм упаковки JPEG — варьируя степень потерь в каждом конкретном случае, пользователь может найти компромисс между качеством и объемом.

Считается, что, в отличие от JPEG, формат GIF предлагает сжатие без потерь. Это не совсем так. Во-первых, для сохранения картинки в формате GIF ее необходимо преобразовать в 256-цветную, и, если изначальный материал был полноцветным (допустим, RGB 24bit), мы потеряем часть оттенков именно при этом преобразовании — они будут заменены на самые близкие. Кроме того, чтобы еще уменьшить размер файла, количество цветов можно сократить хоть до двух, и, если в исходном изображении их было больше, часть информации неизбежно потеряется. Утверждение об отсутствии потерь справедливо только в том случае, если при сохранении в GIF мы не урезаем изначальную палитру.

На заметку: есть простой способ проверить, есть ли потери при том или ином способе упаковки. Сохраните исходный файл в неупакованном виде — к примеру, image1.bmp. Затем упакуйте его в нужный графический формат, сохраните и откройте в графическом редакторе. Снова сохраните полученную картинку без компрессии — image2.bmp. Если потери данных не произошло, эти файлы должны быть полностью идентичны. Выполните системную команду fc.exe /b image1.bmp image2.bmp > report.txt. В текстовый файл запишется отчет о результатах сравнения.