Уникайте подвійного стиснення ресурсів


13

Я використовую .pngs для моїх текстур і використовую віртуальну файлову систему у .zipфайлі для мого ігрового проекту. Це означає, що мої текстури стискаються та стискаються двічі. Які рішення цієї проблеми подвійного стиснення? Одне рішення, про яке я чув, - це використовувати .tgas для текстур, але це здається століттями назад, оскільки я це чув. Іншим рішенням є здійснення декомпресії на, GPUі, оскільки це швидко, забудьте про накладні витрати.


2
Пов’язано: якщо ви використовували jpegs, багато програм zip з власним форматом здатні стискати навіть ті на 20%, тож це не обов'язково так погано. Який сенс у подвійному стисненні, який вас найбільше хвилює? Це займе занадто довго? Дуже багато форматів зберігають уже стислі дані просто дослівно і взагалі не роблять декомпресії.
ПлазмаHH

Відповіді:


17

Zip-формат підтримує кілька різних алгоритмів стиснення. Для кожного файлу в архіві можна використовувати інший алгоритм. Коли ви хочете зберігати вже стиснуті файли, які не користуються додатковою компресією (наприклад, PNG), в zip-архіві, ви можете кодувати ці файли за допомогою "збереженого" алгоритму, який зовсім не стискається. Діалогове вікно "Додати в архів" 7-zip дозволяє вибрати це в розділі "Сила стиснення".

Але коли у ваших архівах є не лише зображення, але й інші, більш стисливі ресурси, вибирати алгоритм для кожного окремого файлу може бути досить нудно. У такому випадку ви можете скоріше вибрати формат зображення, що не стискається, в архіві стискання.

Формат TGA знає багато різних режимів, з яких деякі стискаються, а деякі - ні. Якщо ви не хочете використовувати стиснення, переконайтеся, що ви обрали потрібний варіант у параметрах експорту графічного редактора, який ви використовуєте. Інший формат зображення, що не стискає, - BMP (Windows Bitmap).

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

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

Як бачимо, кодування PNG-накопичувача врятувало лише низькі 0,3%, тоді як BMP з кодуванням, що кодується, зменшується до однієї десятої частини вихідного файлу, що навіть менше, ніж версія PNG. Це мене зовсім здивувало. Я б очікував, що PNG буде меншим, оскільки метод стиснення PNG повинен бути оптимізований для зображень-даних, тоді як ZIP - ні. Ймовірно, пояснення полягає в тому, що мій редактор зображень (GIMP) додав досить багато метаінформації до файлів PNG, що не робиться для BMP.

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

Можливо, варто експериментувати з іншими алгоритмами, ніж дефляція та з іншими параметрами міцності на стиснення. Яке поєднання матиме найкращі результати, ймовірно, залежатиме від стилю ваших фактур. Але ви також можете розглянути можливість завантаження активів для вашої гри і впливати на ефективність декомпресії на ваше рішення, який параметр ви використовуєте.

Суть справи: Якщо ви хочете , щоб уникнути подвійного стиснення і при цьому мати низький розмір файлу, або використовувати PNGз Storeалгоритмом поштовий або BMPз стискає алгоритму ZIP.


5
Я робив це на деяких моїх фотографіях і PNG (рівень стиснення 9), побив zip (рівень стиснення ультра) BMP-зображень весь час приблизно на 20%. Отже, це має бути такий ефект, як метаінформація.
Триларіон

3
png має варіант переплетення зі зменшенням стисливості, але дозволяє витягти зображення з низькою роздільною здатністю лише з першої частини файлу зображення (як, наприклад, під час завантаження через низьке пропускне з'єднання), чи мала ваша стіна активна? крім того, що png використовує дефлат для його стиснення.
храповик виродка

Схоже, що ви використовували поганий компресор PNG, дайте файлам пробігнути через PNGOUT, і ви отримаєте результат, який не буде побитий блискавичним файлом bmp.
aaaaaaaaaaaa

Ваші BMP або TGA 24-розрядні або 32-бітні? Зокрема, з BMP, швидше за все, вони будуть 24-бітовими, а розмір нестисненого TGA дозволяє припустити, що це також 24-бітний. Ви, мабуть, не порівнюєте тут подібне.
Максим Мінімус

@JimmyShelter І TGA і BMP мають 32-бітний з альфа-каналом - я переконався.
Філіп

7

Не хвилюйся з цього приводу.

Коли алгоритм "спуску", який використовується у файлах .zip, наштовхується на блок даних, які вже добре стиснуті, як-от піксельні дані .png зображення, він виявляє, що не може його ефективно стискати, і зберігатиме його як буквальний нестиснуті дані. Для копіювання це вимагає дуже невеликих витрат на кінець декомпресії.

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


3
Іноді така проста, сприйнята проблема не обов'язково є реальною проблемою. Навіть якби насправді двічі було декомпресія, декомпресія дефляції - це дійсно швидка операція, я думаю, накладні витрати були б просто вимірними.
aaaaaaaaaaaa

Чи буде закінчення стиснення зайняти багато часу, щоб зрозуміти, що файл не є стисливим?
користувач253751

Відносно, так. Я не знаю, яку евристику типові .zip-компресори використовують для вибору кодування блоку, але це може бути настільки ж просто, як спроба всіх кодувань і збереження найкращого результату. Під час розробки, якщо ви повинні мати свої дані в .zip, ви, ймовірно, захочете змусити все використовувати, storeа deflateне економити час, тоді deflateвсе для випуску створюється.
Рассел Борогов

2

Схоже, вже було дано кілька дуже хороших відповідей, але я подумав, що ще один:

What are the solutions to this double compression problem?

Рішення: Не робіть нічого.

Обгрунтування: жодної проблеми не було зазначено - так, ви стискаєте інформацію двічі, але чому ви переживаєте з цього приводу? Чи занадто великий розмір даних? Декомпресія занадто повільна? Це більш-менш важливо, ніж десятки функцій, які ви могли б зараз додавати, уточнювати, тестувати та / або налагоджувати?


Робити щось удвічі без потреби - сама по собі проблема. Принаймні, я сприйняв це як таке. Але, звичайно, ви маєте рацію і з вашою пропозицією. І швидкість пам'яті, і швидкість декомпресії можуть бути проблемою, хоча і не в цьому випадку, оскільки я не пишу комерційної гри.
користувач1095108

Я професійний розробник ігор, і я можу запевнити вас, якщо б не було справжніх, задокументованих проблем із роботою, ми б не витрачали ні на що хвилюватися з цього приводу - для оплати слова потрібно багато покупок за 0,99 доларів США або показів оголошень, 8 годин, щоб правильно «виправити» це питання. Робити щось двічі - це не проблема, хоча це може бути неефективно. Хоча в цьому випадку ви не робите одне і те ж саме двічі - у вас є дані зображення, які зберігаються як PNG для стиснення, і ціла купа файлів, які архівуються разом.
NPSF3000

Щоправда, але як тільки це буде зроблено, це робиться для декількох проектів. Якщо ви подумаєте про алгоритм DEFLATE - він залишився таким же з восьмидесятих років. Ви б були старими грампами, якби тоді програмували, але, якби ви знали алгоритм, ви могли б, скажімо, реалізувати його на графічному процесорі та насолоджуватися надзвичайно швидкими швидкостями декомпресії у кількох проектах.
користувач1095108

Отже, ви витрачаєте, які 2 тижні, місяць впроваджуючи Deflate на GPU? І тоді ви розумієте, що ви збираєтесь просто розгорнути на платформі X, ніж Y, і порушує ваш алгоритм через Z. Якщо ви хочете робити ігри, FOCUS ON MAKING GAMES, не хвилюйтесь про непотрібні речі, такі як зниження продуктивності.
NPSF3000

Коли ви знаєте алгоритм (повторне) впровадження, це повинно бути простим. Знімок, не 2 тижні чи місяць. Це я хотів сказати. Це вже з вісімдесятих років, вкладати в це якийсь час, можливо, варто.
користувач1095108

1

Якщо ви використовуєте спеціалізовані формати, такі як PNG і OGG, вам не знадобиться стиснення ZIP.

PNG, OGG та інші вже стислі формати не стануть набагато меншими, стиснувши їх знову як ZIP. 100MB стиснених PNG все ще ~ 100MB.

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

Можливо, ви навіть хочете використовувати файлову систему безпосередньо, а не використовувати віртуальну файлову систему на основі ZIP. Це зробить виправлення дуже просто: ви можете просто поміняти файли, які ви змінили.


2
Іноді у кожного немає вибору щодо того, використовувати .zipфайл чи ні. Наприклад, на платформі Android .apkє .zipфайл, який може містити ресурси.
користувач1095108

3
Крім того, є певні переваги використання архіву , а ZIP-файли забезпечують як стиснення, так і структуру архіву.
MrCranky

Так, я знаю, я просто кажу, що використання рідної файлової системи теж має переваги. Я трохи захисник "Тримай просто".
API-Beast
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.