Как и всем, кто много работет с графикой (дизайнеры, фотографы, иллюстраторы, и т.д.), мне периодически приходится сталкиваться с сжатием больших объемов графических данных.
Сейчас возникла нужда сжать приличное количество (несколько десятков гигабайт) и я решил провести эксперимент — чем же лучше всего сжимать такое количество.
Для экспериментов был выбран довольно типичный для меня вариант: папка с JPG и PSD исходинками, общим объемом примерно в 1гб (1053мб).
Внутри 40 JPG файлов общим объемом в 70мб и PSD 979mb. По сути, соревнование и будет за сжатие PSD. Собственно, JPG файлы практически совсем не жмутся, смысла их паковать иначе как для более удобной транспортировки нет.
Внутри PSD, кстати, особой «халявы» для архиваторов типа дублей слоев тоже нет — в каждом файле всего по два слоя — «сплошной» слой изображения и еще один слой с его обведенной маской. Но само изображение внутри картинок «похожее». В моем случае — разные виды «горок» бейсбольных мячей. Не знаю, насколько это повлияло на общий результат.
Важный ворнинг для тех, кто пришел сюда поискать хороший архиватор: на данные имеет смысл смотреть ТОЛЬКО для тех же или схожих условий архивации — большие (сотни мегабайт, гигабайты в одном архиве) объемы данных и psd файлы. Для других условий (например кучи отдельных архивчиков, текстовые файлы, музыка и т.д.) результаты могут быть абсолютно другими — некоторые алгоритмы лучше работают с одними форматами, некоторые — с другими.
Получилась такой список результатов, кому интересны комментарии и выводы — они ниже:
Встроенный архиватор Total Commandera, формат ZIP — 675mb (медленный)
7zip, формат ZIP, алгоритм Deflate, словарь 32кб, слово 256, качество «Нормальное» — 646mb
7zip, формат ZIP, алгоритм Deflate, словарь 32кб, слово 256, качество «Максимум» — 644mb
7zip, формат ZIP, алгоритм Deflate, словарь 32кб, слово 64, качество «Максимум» — 644mb (100кб выигрыша у слова размером 256)
7zip, формат ZIP, алгоритм Deflate, словарь 32кб, слово 256, качество «Ультра» -643mb
7zip, формат ZIP, алгоритм Deflate64, словарь 64кб, слово 256, качество «Нормальное» — 633mb
7zip, формат ZIP, алгоритм Bzip2, словарь 900кб, качество «Нормальное» — 505mb (лучший вариант открываемый обычным зипом)
7zip, формат ZIP, алгоритм PPMd, — пропущен, нереально долгая упаковка.
7zip, формат ZIP, алгоритм LZMA, словарь 64mb, слово 256, «нормально» — 211mb (не распакуется обычным ZIPом в тотале, оболочке винды и т.д.)
7zip, формат 7z, алгоритм LZMA2, словарь 128мб, слово 256, блок «непрерывный», качество «ультра» — 208мб.
7zip, формат 7z, алгоритм LZMA2, словарь 128мб, слово 256, блок «непрерывный», качество «ультра» — 208мб.
7zip, формат 7z, алгоритм LZMA2, словарь 256мб, слово 256, блок 2гб, качество «норм» — 208мб.
Чтобы не читать простыни текста, простой и короткий вывод: сжимать большие объемы PSD файлов лучше всего архиватором 7zip с алгоритмом LZMA и большими размерами словарей.
Ну а если интересны нюансы — читайте дальше ;)
Для начала я протестировал стандартный архиватор встроенный в Total Commander т.к. обычно в повседневных делах пользуюсь им.
В настройках тотал сообщает, что в нем прописаны древние как гавно мамонта классические pkzip и pkunzip, что «по возможности использует внутренний распаковщик» и использует «NT-zip 2». Судя по всему это какойто очень древний вариант, т.к. пакует тотал ОЧЕНЬ медленно. Вероятно всего использовать многопоточность тотал не умеет совсем.
Результат сжатия: 675mb. Как оказалось — худший, хотя и не особо сильно уступает «дефолтному 7zip». Вообщем, как очень удобный паковщик мелких наборов тотал вполне подходит, но вот если надо чегото хорошо поархивировать — вариант явно не лучший.
Далее был проверен популярный и бесплатный, вроде даже опенсорсный архиватор 7zip. Как и положено хорошему архиватору, 7зип сразу при упаковке позволяет настроить тип алгоритма, качество сжатия и размеры словарей. Многопоточность при этом поддерживается и на 8 потоках пакует 7zip довольно бодро.
Для него были проверены разные варианты алгоритмов и словарей. По умолчанию для zip формата 7zip предлагает алгоритм Deflate.
Размер словаря стоит в максимальные 32кб а размер слова — 256
Результат при нормальной степени сжатия: 646mb, при максимальной: 644, при «ультра» — 643. Т.е. каждый шаг дает жалкие доли процента выиграша (и теряет при этом в скорости).
Выставление размера слова в 64 ухудшает сжатие всего на 100кб — это уже сотые доли процента.
При выборе алгоритма Deflate64 размер словаря можно выставить в 64кб (против 32 у обычного). При нормальном сжатии это дало 633мб — больше чем ультра при обычном 32кб словаре.
При этом, очевидно, вся эта пляска с настройками «дефлята» не имеет смысла — выигрываются какието крохи.
Следующим был выставлен алгоритм Bzip2, который резко дал заметно лучший результат — 505mb! Т.е. если «дефляты» ужимают гдето на треть, Bzip2 — сразу в два раза. С учетом того, что сжатые таким образом файлы открываются обычным зипом (во всяком случае, тотал их распаковывает) — это 7zip+Bzip2 — лучший вариант для упаковки данного типа данных под максимальную универсальность.
Следующим в списке идет PPMd но он был снят с тестирования досрочно — скорость упаковки слишком медленная даже на одном из самых быстрых десктопных процов. Назначение алгоритма — сжатие текстов, с этим он справляется лучше других, но, соответственно, для других форматов данных подходит мало.
И наконец, был выставлен алгоритм LZMA. Который сходу выдал размер архива в 211мб, сжатие в 5(пять) раз! Алгоритм — фирменная фишка архиватора 7zip и я вижу, почему. Минус — хоть полученный архив и имеет расширение zip, распаковать файлы обычный распаковщик в Тотале не может — смысла жать в «зип» нет, это лишь собъет с толку, надо использовать родной формат *.7z.
Словарь LZMA позволяет ставить здоровенные размеры словарей более «крупные» настройки параметров в моем случае дают некоторый прирост. Словарь 128mb, слово 256, качество «ультра» и «непрерывный» блок дает результат в 208мб, А «скромные» 16мб, 32, нормально и 2гб — 246mb. Настройки «256мб, 256, нормально, 2гб блок — те же 208mb.
Далее, был протестирован родной WinRar. Этот архиватор когда был сделан нашим соотечественником и завоевал популярность за счет хороших параметров сжатия и крутого по тем временам функционала (шифрование, многотомные архивы, самораспаковка).
«Дефолтная» упаковка в рар дала неплохой результат — 520мб, — примерно тоже самое, что и лучший результат «универсального Zip».
Однако в RAR испокон века есть возможность включить принудительный алгоритм сжатия «графических данных». Смешно, но такое включение выдает самый худший результат — 849mb. Очевидно, алгоритм расчитан на несжатые файлы типа BMP или похожих.
Общий реузультат совершенно однозначный — при технической возможности, паковать PSD файлы лучше всего в 7zip’ом с алгоритмом lzma или lzma2, — по возможности с большими словарями.
На всякий случай я проверил и влияние «одинаковости» изображений. Если папка честных «разных» джипегов обычно не жмется совсем (объем архива иногда может выйти больше чем суммарный вес файлов), то мой набор картинок сжался с 70 до 50мб, что говорит о влиянии «похожести».
Что бы исключить влияние и получить картину менее схожих файлов, я набрал PSDшек из разных проектов, соответственно, без повторяющихся между файлами элементов. Семь файлов общим объемом 576мб. Результаты тестового сжатия:
7zip, формат 7z, LZMA «хай» — 256мб-256-непрерывно — 169мб. Четырехкратное сжатие.
7zip, формат 7z, LZMA «лоу» — 16мб-32-2гб — 236мб. Более чем двухкратное.
7zip, формат zip, BZip2-305mb, менее чем двукратное
7zip, формат zip, Deflate — 348mb — еще менее.
Хотя лучший результат с пятикратного упал до четырехкратного, и такой — очень впечатляет. Большие объемы PSD однозначно надо сжимать 7зипом с алгоритмом LZMA выставляя большие объемы словарей на сколько это позволяет оперативка.
При этом чем больший объем архивируется, тем более вероятно получить большую степень сжатия, особенно, если пакуется какойто однотипный проект.
Пара слов о «тестовом стенде» и скорости. Паковал я на одном из самых быстрых на данный момент Core i7-4770k, в системе 16gb рам, исходники и конечный архив — на разных дисках. Из-за всего этого скорость упаковки и требования к оперативке волновали меня довольно мало — скорость даже в самых худших случаях была удовлетворительной (пара минут).
Однако, при больших объемах и не самом быстром процессоре скорость может стать существенным фактором. При этом давно известно (и я сам убедился в своих экспериментах) что такой параметр как «качество сжатия», определяемое в архиваторах словами из выпадающего списка «быстрое, нормальное, максимум, и т.д.» — при заметном снижении скорости как правило не очень сильно влияет на степень сжатия.
Например в моем случае, для простого зипа разница между «нормальным» и «ультра» сжатием была в очень заметном снижении скорости (раза в два) при этом разница в результате составила жалкие доли процента. Вообщем, если время дорого, иногда стоит чуть чуть пожертвовать объемом и сильно выиграть в скорости.
Вторым подводным камнем может выплыть требуемый объем памяти. Т.к. на моей системе 16гб, я с проблемами не сталкивался. Но самые крутые настройки LZMA подписывали, что объем для упаковки нужен солидный — 10гб, например. Это может стать серьезным ограничением объема словарей на слабых машинах. При нехватке памяти она будет заменяться виртуальной, или проще говоря, комп «начнет свопиться» и нереально тормозить. Но старые версии алгоритмов хоть и дают меньшее сжатие, позволяют обходится очень скромными объемами памяти.