Чому ці методи стиснення (без втрат) багатьох подібних зображень PNG неефективні?

Щойно я натрапив на таке: я помістив декілька однакових копій PNG зображення у папку, а потім спробував стиснути цю папку такими методами:

• tar czf folder.tar.gz folder/
• tar cf folder.tar folder/ && xz --stdout folder.tar > folder.tar.xz (це добре працює для однакових зображень, однак для подібних зображень коефіцієнт посилення дорівнює нулю)
• zip -r folder.zip folder/

Коли я перевірив розмір самого .tar.gz, .tar.xz, .zipя зрозумів , що це майже так само , як один з folder/.
Я розумію, що зображення PNG може мати високий рівень стиснення, і тому його не можна стиснути далі. Однак, при злитті багатьох подібних (у цьому випадку навіть однакових) PNG зображень до архіву та потім стисненні архіву, я б очікував, що необхідний розмір помітно зменшиться. У випадку однакових зображень я б очікував розміру приблизно розміру одного зображення.

Погляньте, як працюють алгоритми стиснення. Принаймні ті, хто в родині Лемпель-Зів ( gzip використовує LZ77 , zipмабуть , також добре , і xz використовує LZMA ) стискаються дещо локально : подібності, які лежать далеко один від одного, неможливо визначити.

Деталі відрізняються між методами, але суть полягає в тому, що до того часу, коли алгоритм досягне другого зображення, він вже «забув» початок першого. І так далі.

Ви можете спробувати вручну змінити параметри методу стиснення; якщо розмір вікна (LZ77), відповідно розмір блоку / блоку (пізніші методи) принаймні такі ж великі, як два зображення, ймовірно, ви побачите подальше стиснення.

Зауважте, що вищезазначене дійсно застосовується лише в тому випадку, якщо у вас є однакові зображення або майже однакові нестиснені зображення. Якщо є відмінності, стислі зображення можуть не виглядати нічим подібними в пам'яті. Я не знаю, як працює стиснення PNG; ви можете перевірити шістнадцяткові зображення зображень, які ви маєте, для спільних підрядів вручну.

Також зауважте, що навіть із зміненими параметрами та надмірністю експлуатації, ви не зменшитеся до розміру одного зображення. Більш великі словники означають більший розмір кодового слова, і навіть якщо два зображення точно однакові, можливо, доведеться кодувати друге, використовуючи кілька кодових слів (які вказують на перше).

Чому це відбувається. Тут насправді відбувається два різні ефекти:

• Кожен файл стискається незалежно. Деякі програми архіву, включаючи zip, - стискають кожен файл самостійно, без пам’яті з одного файла в інший. Іншими словами, кожен файл окремо стискається, потім стислі файли об'єднуються в архів.

• Короткочасна пам'ять. Деякі програми архіву можуть використовувати інформацію про один файл для кращого стиснення наступного файлу. Вони ефективно з'єднують файли, після чого стискають результат. Це вдосконалення.

  Дивіться також відповідь Наюкі для більшого обговорення цього питання.

  Однак є друга проблема. Деякі схеми стиснення - включаючи zip, gzip та bzip2 - мають обмежену пам’ять. Вони стискають дані на ходу і запам'ятовують минулі 32 КБ даних, але нічого не пам'ятають про дані, що мали місце набагато раніше у файлі. Іншими словами, вони не можуть знайти дублюваних даних, якщо дублікати трапляються більше, ніж на 32 КБ. Як результат, якщо однакові файли короткі (коротші, ніж приблизно 32 КБ), алгоритм стиснення може видалити повторювані дані, але якщо однакові файли довгі, алгоритм стиснення стає шлангом і стає нікчемним: він не може виявити жодного з дублікат у ваших даних. (Bzip запам'ятовує останні 900 Кб або близько даних, а не 32 КБ.)

  Усі стандартні алгоритми стиснення мають деякий максимальний об'єм пам'яті, поза яким вони не в змозі виявити шаблони ... але для деяких це число набагато більше, ніж для інших. Для Bzip це щось на зразок 900 КБ. Для xz це щось на зразок 8 Мб (із налаштуваннями за замовчуванням). Для 7z це щось на зразок 2 Гб. 2 Гб є більш ніж достатньо великим, щоб розпізнати дублювані копії файлів PNG (як правило, набагато менше 2 ГБ). Крім того, 7z також намагається бути розумним щодо розміщення файлів, які, ймовірно, схожі один на одного в архіві, щоб допомогти компресору працювати краще; смола нічого про це не знає.

  Дивіться також відповідь Рафаеля і відповідь Nayuki в для більш докладного пояснення цього ефекту.

Як це стосується вашої настройки. Для вашого конкретного прикладу ви працюєте із зображеннями PNG. Зображення PNG самі стискаються, тому кожен файл PNG можна розглядати як послідовність випадкових байтів без шаблонів чи дублювання у файлі. Якщо компресор не може використовувати, якщо він дивиться на одне зображення PNG. Таким чином, якщо ви спробуєте стиснути один файл PNG (або створити zip / tar / ... архів, що містить лише один файл PNG), ви не отримаєте жодного стиснення.

Тепер давайте розберемося, що станеться, якщо ви спробуєте зберегти кілька копій одного й того самого файлу PNG:

• Невеликі файли. Якщо файл PNG дуже маленький, то все, крім zip, буде чудово працювати. Zip вийде з ладу ефектно: він стискає кожен файл самостійно, тому у нього немає шансів виявити надмірність / дублювання файлів. Більше того, намагаючись стиснути кожен файл PNG, він не досягає стиснення; розмір zip-архіву буде величезним. На відміну від цього, розмір архіву дьогтю (будь то стиснений з gzip, bzip2 або xz) та 7z архіву буде невеликим, оскільки він в основному зберігає одну копію файлу, а потім помічає, що інші всі однакові - вони приносять користь від збереження пам'яті з одного файла в інший.

• Великі файли. Якщо файл PNG великий, то добре працює лише 7z. Зокрема, блискавка продовжує вражати. Крім того, tar.zip та tar.bzip2 погано виходять з ладу, оскільки розмір файлу більший за вікно пам'яті компресора: коли компресор бачить першу копію файлу, він не може його зменшити (оскільки він вже був стиснутий) ); до того моменту, коли він починає бачити початок другої копії файлу, він вже забув послідовності байтів, які бачили на початку першого файлу, і не може зробити з'єднання, що ці дані насправді є дублікатами.

  Навпаки, tar.xz і 7z продовжують чудово працювати з кількома копіями великого файлу PNG. Вони не мають обмеження на "малий об'єм пам'яті" і можуть помітити, що друга копія файлу ідентична першій копії, тому зберігати її не потрібно вдруге.

Що ви можете зробити з цього приводу. Використовуйте 7z. Він має купу евристики, яка допоможе виявити однакові або подібні файли і дуже добре стиснути в цьому випадку. Ви також можете подивитися на lrzip зі стисненням lzop.

Звідки я знаю? Я зміг це перевірити, спробувавши кілька експериментів зі 100 копіями файлу, що містить випадкові байти. Я спробував 100 копій файлу розміром 4 КБ, 100 копій файлу 1 МБ та 100 копій файлу розміром 16 Мб. Ось що я знайшов:

Size of file      Size of compressed archive (with 100 copies)
                  zip  tar.gz  tar.bz2  tar.xz    7z
         4KB    414KB     8KB     10KB     5KB    5KB
         1MB    101MB   101MB    101MB     1MB    2MB
        16MB    1.6G    1.6GB    1.6GB   1.6GB  401MB

Як бачите, поштовий індекс - це жахливо, незалежно від того, наскільки маленький ваш файл. 7z і xz - це добре, якщо ваші зображення не надто великі (але xz буде крихким і залежатиме від порядку, в який зображення розміщуються в архіві, якщо у вас є кілька дублікатів і кілька недублів, змішаних разом). 7z досить проклятий, навіть для великих файлів.

Список літератури. Це також добре пояснено в купі публікацій у Super User. Поглянь:

• Чому стиснення Gzip не усуває повторюваних фрагментів даних?
• Чому Zip здатний стискати один файл менше, ніж кілька файлів з одним вмістом?
• Стиснення багатьох подібних великих файлів
• Ефективно стискайте подібні файли
• Чи існує програма стиснення або архівації для Windows, яка також робить дедуплікацію?
• Більш ефективна програма стиснення файлів для багатьох однакових файлів?

По-перше, зауважте, що формат зображення PNG - це в основному сирі RGB-пікселі (з деякою легкою фільтрацією), що передаються через формат стиснення DEFLATE. Взагалі кажучи, стислі файли (PNG, JPEG, MP3 тощо) не побачать користі від повторного стиснення. Тож для практичних намірів ми можемо розглядати ваш файл PNG як нестислимі випадкові дані для решти експерименту.

По-друге, зауважте, що формати ZIP та gzip також використовують кодек DEFLATE. (Це пояснило б, чому блискавка проти gzipping одного файлу по суті дає однаковий розмір виводу.)

Тепер дозвольте мені коментувати кожен тестовий випадок окремо:

• tar czf folder.tar.gz folder/

  Це створює (нестиснений) файл TAR, який об'єднує всі ваші однакові файли PNG (із доданою невеликою кількістю метаданих та прокладки). Потім цей єдиний файл відправляється через компресор gzip для створення одного стисненого вихідного файла.

  На жаль, формат DEFLATE підтримує лише вікно словника LZ77 з 32768 байтами. Тож навіть незважаючи на те, що TAR містить дані, що повторюються, якщо ваш PNG-файл перевищує 32 Кб, то напевно компресор DEFLATE не може запам'ятати дані досить далеко назад, щоб скористатися тим, що ідентичні дані повторюються.

  З іншого боку, якщо ви спробуєте цей досвід із, скажімо, файлом PNG розміром 20 Кб, дубльованим 10 разів, то дуже ймовірно, що ви отримаєте файл gzip лише трохи більше 20 КБ.

• tar cf folder.tar folder/ && xz --stdout folder.tar > folder.tar.xz

  Це створює файл TAR, як і раніше, а потім використовує формат xz та компресор LZMA / LZMA2. Я не міг знайти інформацію про LZMA в цій ситуації, але з 7-Zip для Windows я знаю, що вона може підтримувати великі розміри вікон словника (наприклад, 64 МБ). Тож можливо, що ви використовували неоптимальні налаштування, і що кодек LZMA міг би зменшити файл TAR до розміру одного файлу PNG.

• zip -r folder.zip folder/

  Формат ZIP не підтримує "суцільні" архіви; тобто кожен файл стискається незалежно. Ми припускали, що кожен файл нестислимий. Звідси той факт, що кожен файл однаковий, не може бути використаний, а ZIP-файл буде таким же великим, як і пряме з'єднання всіх файлів.

Проблема полягає в тому, що (більшості) схем стиснення не вистачає знань щодо даних, які ви маєте. Навіть якщо ви декомпресуєте свої PNG на растрові карти і стискаєте їх у тарболі, ви не отримаєте (значно) менших результатів.

У випадку багатьох подібних зображень відповідною схемою стиснення був би відеокодек.

Використовуючи кодування без втрат, ви повинні досягти майже ідеального результату стиснення, якого ви очікуєте.

Якщо ви хочете перевірити це, використовуйте щось подібне:

ffmpeg -i img%03d.png -c:v libx264 -c:v libx264 -profile:v high444 -crf 0 out.mp4

https://trac.ffmpeg.org/wiki/Create%20a%20video%20slideshow%20from%20images

PNG - це комбінація фільтрів + LZ77 + Хаффмана (комбінація LZ77 + Хаффмана називається «Дефляція») у такому порядку:

крок 1) якщо фільтр відрізняється від None, значення пікселів замінюється різницею від сусідніх пікселів (детальніше див. http://www.libpng.org/pub/png/book/chapter09.html ) . Це збільшує стиснення зображень градієнтами (так ... 4 5 6 7 стає ... 1 1 1 1), і це може допомогти в областях одного кольору (... 3 3 3 5 5 5 5 5 стає 0 0 0 2 0 0 0 0 0). За замовчуванням фільтри увімкнено в 24-бітових зображеннях та відключені у 8-бітових зображеннях з палітрою.

крок 2) дані стискаються з LZ77, який замінює повторні (збіги) рядки байтів з кортежем, що містить відстань до збігу та довжину збігу.

крок 3) результат кроку 2 кодується кодом Хаффмана, який замінює символи фіксованої довжини кодами змінної довжини, чим частіше символ тим коротший код.

Існує кілька питань:

Невелика зміна, яка впливає на кілька пікселів, призведе до зміни результатів за допомогою 3 кроків стиснення png:

1) Відфільтроване значення сусідніх пікселів буде змінюватися (залежно від використовуваного фільтра). Це посилить наслідки невеликих змін.

2) Зміна означатиме, що відповідність цій галузі буде різною. Наприклад, зміна 333333 на 333533 призводить до того, що інше явище 333333 більше не збігатиметься, тому воно вибере інший збіг до 333333 з іншою відстані або вибере той самий збіг, але з меншою довжиною, а потім інший збіг за останні 3 байти. Саме по собі це сильно змінить результати.

3) Найбільша проблема полягає в кроці 3. Код Хаффмана використовує змінну кількість бітів, тому навіть невелика зміна призведе до того, що все, що випливає, більше не вирівнюється. AFAIK Більшість алгоритмів стиснення не можуть виявити збіги, які не вирівняні в байтах, що запобіжить (або принаймні зменшить багато) стиснення вже стислих даних, що слідують за зміною, якщо компресор не може виявити збіги, які не вирівняні в байтах.

Інші питання вже охоплені іншими відповідями:

4) Gzip використовує той самий алгоритм Дефляції зі словником 32 КБ, тому, якщо файлів png більше 32 КБ, збіги не будуть виявлені, навіть якщо вони однакові. У цьому аспекті Bzip2 кращий, оскільки він використовує блок 900 КБ. XZ використовує LZMA, IIRC має словник 4 Мб у рівні стиснення за замовчуванням. 5) Формат Zip не використовує суцільне стиснення, тому він не буде краще стискати подібні або однакові файли.

Можливо, компресори з сімейства PAQ або PPMD ​​будуть стискатись краще, але якщо вам потрібно стиснути безліч подібних файлів зображень, тоді ви можете розглянути 3 підходи:

1) Зберігайте зображення нестисненими (з PNG -0 або у форматі без стиснення) і стискайте компресором з великим розміром словника або блоку. (LZMA буде добре працювати)

2) Ще одним варіантом буде збереження фільтрів, але видалення стиснення Спуску з PNG. Це можна зробити, наприклад, за допомогою утиліти ( AdvDef ). Потім ви стискаєте отримані нестиснені PNG. Після декомпресії ви можете зберігати нестиснений PNG або стискати їх знову за допомогою AdvDef (але це займе час).

Вам потрібно перевірити обидва підходи, щоб побачити, що стискає найбільше.

3) Останнім варіантом буде перетворення png-зображень у відео, стиснення його за допомогою відеокомпресора без втрат на зразок x264 без втрат (особливо уважно використовуючи правильний кольоровий формат), а потім після вилучення витягніть кадри на окремі зображення PNG. Це можна зробити за допомогою ffmpeg. Вам також потрібно зберегти відображення між номером кадру та оригінальною назвою.

Це був би найскладніший підхід, але якщо PNG є частиною анімації, це може бути найефективнішим. Однак вам знадобиться формат відео, який підтримує прозорість, якщо він вам потрібен.

Редагувати: Існує також формат СПГ, якщо він використовується не часто.

Коли у вас є спеціальні набори даних, ви використовуєте спеціальні алгоритми, а не багатоцільові інструменти.

Відповідь полягає в тому, що вибрані вами компресії без втрат не робляться для того, що ви робите. Ніхто не очікує, що ти двічі стиснеш одне і те ж зображення, і навіть якщо ти це зробиш (випадково) перевірка проти всіх попередніх даних зробить ваш алгоритм O (n ^ 2) (можливо, трохи кращим, але наївний підхід принаймні буде n ^ 2).

Більшість ваших програм стиснення, які ви перевірили на запуску в O (n), вони підкреслюють швидкість над оптимальним коефіцієнтом стиснення. Ніхто не хоче запускати свій комп’ютер протягом 5 годин просто для того, щоб заощадити кілька кілометрів, особливо в наші дні. Для більших входів все, що вище O (n), стає проблемою виконання.

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

Якщо у ваших файлах є шаблони, які ви хочете стиснути, вам доведеться виконати операції manel над ними, написати власне стиснення або потенційно використати "архівний" тип-стиснення (nano). Компресія для довготривалого зберігання, яка занадто повільна для щоденного використання.

Іншим варіантом потенційно може бути стиснення відео без втрат.

Формат файлу PNG вже використовує внутрішньо алгоритм стиснення DEFLATE. Це той самий алгоритм, який використовують xz, gzip та zip - лише в деяких варіаціях. tar.gzі tar.xzскористайтеся подібністю між файлами, чого zipнемає.

Отже, ви фактично виконуєте стиснення DEFLATE над стислими файлами DEFLATE - ось чому файли зберігають майже початковий розмір.

bzip2Програма (також споріднений алгоритм) краще , коли справа доходить до (майже) ідентичних файлів.

# for i in $(seq 4); do cp test.png test$i.png; done
# tar -cjf archive.tar.bz2 *.png
# ls -l
-rw-r--r-- 1 abcde users  43813 15. Jul 08:45 test.png
-rw-r--r-- 1 abcde users  43813 15. Jul 08:45 test1.png
-rw-r--r-- 1 abcde users  43813 15. Jul 08:46 test2.png
-rw-r--r-- 1 abcde users  43813 15. Jul 08:46 test3.png
-rw-r--r-- 1 abcde users  43813 15. Jul 08:46 test4.png
-rw-r--r-- 1 abcde users  68115 15. Jul 08:47 archive.tar.bz2