Избегайте двойного сжатия ресурсов

13

Я использую .pngs для своих текстур и использую виртуальную файловую систему в .zipфайле для моего игрового проекта. Это означает, что мои текстуры сжимаются и распаковываются дважды. Каковы решения этой проблемы двойного сжатия? Одно из решений, о котором я слышал, - использовать .tgas для текстур, но, кажется, давным-давно, с тех пор как я это слышал. Другое решение заключается в реализации декомпрессии GPUи, поскольку это быстро, забудьте о накладных расходах.

user1095108
источник
2
Связано: если вы использовали jpegs, то многие zip-программы с собственным форматом способны сжимать даже эти файлы на 20%, так что это не обязательно так уж плохо. Какой смысл двойного сжатия, о котором вы больше всего беспокоитесь? Это займет слишком много времени? Многие форматы даже хранят уже сжатые данные просто дословно и не распаковывают их вообще.
PlasmaHH

Ответы:

17

Zip-формат поддерживает несколько различных алгоритмов сжатия. Вы можете использовать разные алгоритмы для каждого файла в архиве. Если вы хотите сохранить уже сжатые файлы, которые не получают дополнительного сжатия (например, PNG), в zip-архиве, вы можете закодировать эти файлы с помощью «хранимого» алгоритма, который вообще не сжимается. Диалоговое окно «Добавить в архив» для 7-zip позволяет вам выбрать это в разделе «Сила сжатия».

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

Формат TGA знает много разных режимов, некоторые из которых сжимаются, а некоторые нет. Если вы не хотите использовать сжатие, убедитесь, что вы выбрали правильный вариант в настройках экспорта графического редактора, который вы используете. Другой несжатый формат изображения - BMP (Windows Bitmap).

Вот тест, который я сделал. Я добавлял одно и то же изображение (актив из моего текущего проекта) в разных форматах несколько раз в zip-архив, некоторые с алгоритмом "deflate" в обычном режиме и одно с "store". Извините за немецкий графический интерфейс. 2-й столбец - несжатый размер, 3-й столбец - алгоритм сжатия, а 4-й столбец - сжатый размер.

введите описание изображения здесь

Как вы можете видеть, PNG-кодирование с дефляцией сохранило только скудные 0,3%, тогда как BMP с кодированным дефлатом уменьшилось до одной десятой исходного файла, что даже меньше, чем у PNG-версии. Это меня довольно удивило. Я ожидал бы, что PNG будет меньше, потому что метод сжатия PNG должен быть оптимизирован для данных изображения, а ZIP - нет. Вероятное объяснение состоит в том, что мой редактор изображений (GIMP) добавил довольно много метаинформации в файлы PNG, чего не делает для BMP.

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

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

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

Philipp
источник
5
Я делал это на некоторых моих снимках, и PNG (уровень сжатия 9) ударов zip (уровень сжатия ultra) BMP-изображений все время примерно на 20%. Так что это должен быть эффект, подобный метаинформации.
Триларион
3
У png есть опция чересстрочной развертки, которая уменьшает сжимаемость, но позволяет извлекать изображение с низким разрешением только из первой части файла изображения (например, при загрузке через соединение с низкой полосой пропускания), была ли эта стена активна? кроме того, png уже использует deflate для своего сжатия.
фрик с трещоткой
Похоже, вы использовали плохой png-компрессор, запустите ваши файлы через PNGOUT, и вы получите результат, который не будет побежден zmp-файлом bmp.
aaaaaaaaaaaa
Ваши BMP или TGA 24-битные или 32-битные? В частности, с BMP они более вероятно будут 24-битными, а несжатый размер TGA предполагает, что он также 24-битный. Вы, вероятно, не сравниваете подобное с как здесь.
Максимус Минимус
@JimmyShelter И TGA, и BMP 32-битные с альфа-каналом - я убедился.
Филипп
7

Не беспокойся об этом.

Когда алгоритм «deflate», используемый в файлах .zip, обнаруживает блок данных, который уже хорошо сжат, например, данные пикселей изображения .png, он обнаруживает, что не может эффективно сжать его, и сохраняет его как литерал несжатые данные. На распаковке это занимает очень мало времени на распаковке.

http://en.wikipedia.org/wiki/DEFLATE

Рассел Борогове
источник
3
Иногда это так просто, воспринимаемая проблема не обязательно является реальной проблемой. Даже если бы на самом деле были издержки распаковки дважды, распаковка дефлята - это действительно быстрая операция, я думаю, что издержки были бы только измеримы.
aaaaaaaaaaaa
Будет ли конец сжатия занимать много времени, чтобы понять, что файл не сжимается?
user253751
Относительно да. Я не знаю, какую эвристику используют типичные компрессоры .zip для выбора кодировки блока, но это может быть так же просто, как пробовать все кодировки и сохранять наилучший результат. Во время разработки, если ваши данные должны быть в формате .zip, вы, вероятно, захотите заставить все использовать storeвместо того, deflateчтобы экономить время, а затем deflateвсе для релизных сборок.
Рассел Борогове
2

Похоже, некоторые очень хорошие ответы уже были даны, но я решил дать еще один:

What are the solutions to this double compression problem?

Решение: ничего не делать

Обоснование: не было заявлено никаких проблем - да, вы сжимаете информацию дважды, но почему вы беспокоитесь об этом? Размер данных слишком велик? Слишком медленная декомпрессия? Это более или менее важно, чем десятки функций, которые вы могли бы добавлять, дорабатывать, тестировать и / или отлаживать в данный момент времени?

NPSF3000
источник
Делать что-то дважды без необходимости - проблема сама по себе. По крайней мере, я воспринимал это так. Но, конечно, вы правы и со своим предложением. И память, и скорость распаковки могут быть проблемой, хотя и не в этом случае, поскольку я не пишу коммерческую игру.
user1095108
Я - профессиональный разработчик игр, и я могу заверить вас, если бы не было реальных, задокументированных проблем с производительностью, о которых мы бы не потратили ни секунды, беспокоясь об этом - для покупки, скажем, потребуется много покупок в размере 0,99 долл. США или рекламных показов, 8 часов, чтобы правильно «исправить» эту проблему. Делать что-то дважды - не проблема, хотя это может быть неэффективно. Хотя в этом случае вы не делаете одно и то же дважды - у вас есть данные изображения, которые хранятся в формате PNG для сжатия, и целая куча файлов, которые архивируются вместе.
NPSF3000
Правда, но как только это будет сделано, это будет сделано для нескольких проектов. Если подумать об алгоритме DEFLATE - он остался прежним с восьмидесятых годов. Если бы вы запрограммировали тогда, вы были бы старыми дедушками, но, если бы вы знали алгоритм, вы могли бы, скажем, реализовать его на GPU и наслаждаться сверхбыстрой скоростью декомпрессии в нескольких проектах.
user1095108
Так что вы тратите, что 2 недели, месяц на внедрение Deflate на GPU? И тогда вы понимаете, что вы собираетесь развернуть на платформе X, а не Y и нарушить свой алгоритм через Z. Если вы хотите создавать игры, сфокусируйтесь на создании игр, не беспокойтесь о ненужных вещах, таких как снижение производительности.
NPSF3000
Как только вы знаете алгоритм (пере), его реализация должна быть легкой. Снимок, а не 2 недели или месяц. Это то, что я хотел сказать. Это было с восьмидесятых годов, поэтому стоит потратить на это время.
user1095108
1

Если вы используете специализированные форматы, такие как PNG и OGG, вам не понадобится сжатие ZIP.

PNG, OGG и другие уже сжатые форматы не станут намного меньше, если снова сжать их в ZIP. 100 МБ сжатых файлов PNG по-прежнему составляют ~ 100 МБ.

Сценарии, файлы конфигурации и другие текстовые форматы значительно выигрывают от сжатия, однако, как правило, они крошечные по сравнению, они не хранят столько данных. Если ваша игра занимает 100 МБ, то текстовые файлы могут составлять 1 МБ всей игры, даже если вы можете сделать их 100 КБ путем сжатия, тогда вы выиграли только 900 КБ, менее 1%, вряд ли стоит усилий.

Возможно, вы даже захотите использовать файловую систему напрямую, а не виртуальную файловую систему на основе zip. Это сделает исправление очень простым: вы можете просто поменять любые файлы, которые вы изменили.

API-Beast
источник
2
Иногда у человека нет выбора, использовать ли .zipфайл или нет. Например, на платформе Android, .apkэто .zipфайл, который может содержать ресурсы.
user1095108
3
Кроме того, использование архива имеет определенные преимущества , а файлы ZIP обеспечивают сжатие и структуру архива.
MrCranky
Да, я знаю, я просто говорю, что использование родной файловой системы также имеет свои преимущества. Я в некотором роде сторонник "будь проще".
API-Beast