Как сжимаются файлы

Здравствуйте! Не могли бы вы объяснить начинающему пользователю, как сжимаются файлы всякими архиваторами? Хотя бы в общих чертах. А то я с трудом себе представляю, как это вообще может быть.

Совершенно верно, Виталий, это действительно не так просто себе представить, тем более, если не знаешь алгоритма. Но читателям нашего журнала повезло ;), поскольку я в свое время много интересовался алгоритмами сжатия данных и, как программист, даже пробовал писать собственный архиватор.

Сжатие данных (англ. data compression) – алгоритмическое преобразование данных, производимое с целью уменьшения их объема. Применяется для более рационального использования устройств хранения и передачи данных. Процесс сжатия еще называют упаковкой данных или компрессией. Обратная процедура называется восстановлением данных (распаковкой, декомпрессией).

Сжатие основано на устранении избыточности, содержащейся в исходных данных. Простейшим примером избыточности является повторение в тексте фрагментов (например, слов естественного или машинного языка).

Итак, давайте начнем с простого примера. Допустим, у нас есть текстовый файл, который содержит строку текста:

Текст довольно странный, согласитесь, но сейчас мы его сожмем, и он у нас будет занимать меньше места. Основной принцип сжатия весьма прост и сводится к следующему: каждая комбинация подряд повторяющихся символов заменяется одним таким символом и числом его повторений. Т.е. наш исходный текст в сжатом виде будет выглядеть так:

Таким образом, вместо 22 символов мы получили 16 символов. Конечно, такие тексты как наш исходный встречаются довольно редко, не говоря уже о бессмыслице, которая заключена в нем. Но ведь файлы, подвергающиеся сжатию, бывают не только текстовые, но и всякие картинки, музыка, видео, программы.

Данный пример довольно упрощен и не отражает эффективность, которую обычно демонстрируют при сжатии архиваторы. Так у нас получилось сжатие в 22/16 = 1,375 раза, хотя архиваторы, как правило, способны сжимать файлы в 2-10000 раз. Все зависит от повторяемости значений байт в файле.

Например, во времена незабвенной MS-DOS были архиваторы ARJ, PKZIP, HA, RAR, ARC, ACE и упаковщики программ LZEXE и PKLITE. Позднее для операционной системы Windows были созданы WinAce, WinZIP, WinRAR, 7Zip и известный мне упаковщик UPX.

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

Сжатие с потерями можно назвать адаптивным сжатием, и применяется для упаковки изображений, видео и звука, поскольку такие данные сжатию без потерь поддаются весьма незначительно (всего примерно до 2 раз).

Благодаря сжатию с потерями можно добиться многократного уменьшения объема данных, и при отображении распакованных данных человек практически не ощутит разницы между оригиналом.

Действительно, например, текстовые файлы могут сжиматься весьма плотно. Так, например, книга Аркадия и Бориса Стругацких “Трудно быть богом” размером 354 329 байт архиватором WinRAR сжимается до 140 146 байт, т.е. в 2,5 раза.

Файлы программ тоже могут подвергаться сжатию. При этом сжатию как для более плотного хранения на диске, так и сжатию, при котором программа остается программой, но при запуске разжимает сама себя.

Для этого существуют упаковщики программ на подобие UPX и др. Например, мой текстовый редактор Superpad.exe размером 524 288 байт упаковщиком UPX сжимается до 179 200 байт (в 2,9 раза) и при этом может по-прежнему запускаться самостоятельно как программа.

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

Одним из первых алгоритмов сжатия изображений был алгоритм RLE, который я описал выше. Он применяется в формате хранения изображений PCX. RLE является алгоритмом сжатия без потерь. Но в некоторых случаях он мог приводить не к уменьшению объема данных, а к его увеличению.

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

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

Для сравнения, возьмем красивого лягушонка (рис. 1) разрешение 799x599 пикселей (точек) и сохраним в разные форматы хранения изображений. Получим файлы:

frog.bmp - размер 1 437 654 байта и тут, по сути, никакого сжатия и никаких потерь качества, поскольку картинка занимает положенные ей байты в формате Ширина x Высота x 3 байта на пиксель + заголовок формата файла BMP согласно качеству True colors (24 бит/пиксель). Т.е. каждая точка представлена тремя компонентами RGB (Red-красный, Green-зеленый и Blue-синий), каждая из которых занимает один байт.

frog24.png - 617 059 байт, сжатие в 2,33 раза и без потерь – основное свойство формата PNG-24. Данные BMP и PNG практически идентичны.

frog_256colors.gif - 261 956 байт (рис. 2), сжатие в 5,48 раза с потерями, базовая палитра 256 цветов (8 бит/пиксель). Уловить разницу между этим файлом и оригиналом в BMP довольно сложно, как в той игре “Найди десять отличий”.

frog_64colors.gif - 187 473 байта (рис. 3), сжатие в 7,67 раза с потерями, базовая палитра уплотнена до 64 цветов (6 бит/пиксель). А вот тут цвета уже блеклые, но вполне сходное с оригиналом изображение. Особенно это заметно, если посмотреть на глаз лягушонка.

Особое место занимает в сжатии и хранении изображений формат JPEG. Поэтому ему хочу уделить особое внимание. Алгоритм JPEG в наибольшей степени пригоден для сжатия фотографий и картин, содержащих реалистичные сцены с плавными переходами яркости и цвета. Наибольшее распространение JPEG получил в цифровой фотографии и для хранения и передачи изображений с использованием сети Интернет.

С другой стороны, JPEG малопригоден для сжатия чертежей, текстовой и знаковой графики, где резкий контраст между соседними пикселями приводит к появлению заметных артефактов. Такие изображения целесообразно сохранять в форматах без потерь, таких как TIFF, GIF, PNG или RAW.

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

JPEG не должен использоваться и в тех случаях, когда недопустимы даже минимальные потери, например, при сжатии астрономических или медицинских изображений. В таких случаях может быть рекомендован предусмотренный стандартом JPEG режим сжатия Lossless JPEG (который, к сожалению, не поддерживается большинством популярных кодеков) или стандарт сжатия JPEG-LS.

Описание алгоритма сжатия JPEG довольно не простое, поэтому кто захочет, может ознакомиться с ним по ссылке http://el-izdanie.narod.ru/gl4/4-3.htm. Ну и для сравнения сожмем нашу исходную картинку с разным уровнем качества:

frog100%.jpg – 216 168 байт, сжатие в 6,65 раза, потери якобы 0%, т.е. 100%-е качество картинки, но даже на это рассчитывать я бы не стал. Поверьте, отличия есть, правда, на глаз абсолютно неотличимые.

frog60%.jpg – 85 910 байт, сжатие в 16,7 раза, т.е. качество картинки 60%, но картинка снова кажется одинаковой, хотя, если присмотреться к участкам с однородным фоном или мелким деталям, то заметны артефакты в виде смазанности или квадратных одноцветных сегментов.

frog20%.jpg – 36 426 байт, сжатие в 39,5 раз, качество картинки 20% от исходного изображения, но по-прежнему картинка еще способна обмануть неискушенный глаз, но на однородном фоне отчетливо видны одноцветные угловатые сегменты, а мелкие детали окончательно потеряли свои четкие очертания.

Это один из самых первых и самых распространенных форматов хранения видео. Несколько раз модернизировался. Но в упрощенном виде, можно сказать, что алгоритм очень напоминает сжатие как в JPEG, но с учетом того, что первый кадр видео всегда является исходным и оригинальным, а последующие кадры хранят лишь разницу между предыдущим и следующим кадрами. Благодаря этому каждый последующий кадр является предсказуемым с точки зрения распаковки (рис. 4 и 5).

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

Однако, из-за движения каких-либо объектов в кадре (или самой камеры) использование подобия соседних кадров было неполным. Технология компенсации движения позволяет находить похожие участки, даже если они сдвинуты относительно предыдущего кадра.

Компенсация движения (англ. Motion Compensation) – один из основных алгоритмов, применяемых при обработке и сжатии видеоданных. Алгоритм использует сходство соседних кадров в видео последовательности и находит векторы движения отдельных частей изображения (обычно блоков 16x16 и 8x8).

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

Практически в любом видео соседние кадры похожи, имеют общие объекты, которые, как правило, смещаются друг относительно друга. И совершенно естественно желание закодировать видео так, чтобы объекты не кодировались многократно, а просто описывались некоторые их смещения.

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

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

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

Звук и музыка могут без потерь, либо с потерями храниться в формате WAV. Например, формат WAV (Windows PCM) не предусматривает сжатие и хранит звуковой сигнал в оригинале, если можно так выразиться.

Формат WAV (ACM Waveform), по сути, является контейнером и может хранить звук, сжатый по алгоритму MPEG layer 3, либо хранить музыку в формате MP3, хотя много и других форматов OGG, FLAC и д.р.

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

На нашем сайте можно не только бесплатно скачать игры, но и документацию и книги по программированию на MIDLetPascal, Turbo Pascal 6, Turbo Pascal 7, Borland Pascal, по программированию устройств Sound Blaster, Adlib, VESA BIOS, справочник Norton Guide и много другой полезной информации для программистов, включая примеры решения реальных задач по созданию резидентных программ.

Как сжимаются файлы

Как это происходит?

Какие архиваторы бывают

На сколько сжимаются разные файлы

Текстовые

Программы

Изображения

JPEG

MPEG

Звук и музыка