Perché questi metodi di compressione (senza perdita di dati) di molte immagini png simili sono inefficaci?

Ho appena trovato la seguente cosa: ho messo più copie identiche di un'immagine png in una cartella e quindi ho provato a comprimere quella cartella con i seguenti metodi:

• tar czf folder.tar.gz folder/
• tar cf folder.tar folder/ && xz --stdout folder.tar > folder.tar.xz (questo funziona bene per immagini identiche, tuttavia per immagini simili il guadagno è zero)
• zip -r folder.zip folder/

Quando ho controllato le dimensioni del .tar.gz, .tar.xz, .zipmi sono reso conto che è quasi lo stesso di quello di folder/.
Capisco che un'immagine png stessa possa avere un alto livello di compressione e quindi non può essere ulteriormente compressa. Tuttavia, quando si uniscono molte immagini png simili (in questo caso anche identiche) a un archivio e quindi si comprime l'archivio, mi aspetto che le dimensioni richieste diminuiscano notevolmente. Nel caso di immagini identiche mi aspetterei una dimensione approssimativamente della dimensione di una singola immagine.

Dai un'occhiata a come funzionano gli algoritmi di compressione. Almeno quelli della famiglia Lempel-Ziv ( gzip usa LZ77 , zipapparentemente per lo più lo fa , e xz usa LZMA ) comprimono un po ' localmente : le somiglianze che si trovano lontane l'una dall'altra non possono essere identificate.

I dettagli differiscono tra i metodi, ma la linea di fondo è che quando l'algoritmo raggiunge la seconda immagine, ha già "dimenticato" l'inizio della prima. E così via.

Puoi provare e modificare manualmente i parametri del metodo di compressione; se la dimensione della finestra (LZ77) risp. le dimensioni di blocco / blocco (metodi successivi) sono almeno pari a due immagini, probabilmente vedrai un'ulteriore compressione.

Si noti che quanto sopra vale davvero solo se si hanno immagini identiche o immagini non compresse quasi identiche . Se ci sono differenze, le immagini compresse potrebbero non somigliare affatto alla memoria. Non so come funziona la compressione PNG; potresti voler controllare manualmente le rappresentazioni esadecimali delle immagini che hai per sottostringhe condivise.

Si noti inoltre che anche con parametri modificati e ridondanza da sfruttare, non si ridurrà alla dimensione di un'immagine. I dizionari più grandi significano dimensioni più grandi di parole in codice e anche se due immagini sono esattamente identiche, potresti dover codificare la seconda utilizzando più parole in codice (che indicano la prima).

Perché questo succede. In realtà ci sono due diversi effetti che si verificano qui:

• Ogni file è stato compresso in modo indipendente. Alcuni programmi di archiviazione, incluso zip, comprimono ogni file in modo indipendente, senza memoria da un file all'altro. In altre parole, ogni file viene compresso separatamente, quindi i file compressi vengono concatenati in un archivio.

• Memoria a breve termine. Alcuni programmi di archiviazione possono utilizzare le informazioni su un file per migliorare la compressione del file successivo. Concatenano efficacemente i file, quindi comprimono il risultato. Questo è un miglioramento.

  Vedi anche la risposta di Nayuki per ulteriori discussioni su questo.

  Tuttavia, c'è un secondo problema. Alcuni schemi di compressione - inclusi zip, gzip e bzip2 - hanno una memoria limitata. Comprimono i dati al volo e ricordano gli ultimi 32 KB di dati, ma non ricordano nulla dei dati verificatisi molto prima nel file. In altre parole, non sono in grado di trovare dati duplicati se i duplicati si trovano a una distanza superiore a 32 KB. Di conseguenza, se i file identici sono brevi (più brevi di circa 32 KB), l'algoritmo di compressione può rimuovere i dati duplicati, ma se i file identici sono lunghi, l'algoritmo di compressione viene cancellato e diventa inutile: non può rilevare nessuno dei il duplicato nei tuoi dati. (Bzip ricorda i 900 KB circa di dati, invece di 32 KB.)

  Tutti gli algoritmi di compressione standard hanno una dimensione massima della memoria, oltre la quale non riescono a rilevare i modelli ... ma per alcuni, questo numero è molto più grande di altri. Per Bzip, è qualcosa come 900KB. Per xz, è qualcosa come 8 MB (con impostazioni predefinite). Per 7z, è qualcosa come 2 GB. 2 GB è più che sufficientemente grande per riconoscere le copie duplicate dei file PNG (che in genere sono molto più piccole di 2 GB). Inoltre, 7z cerca anche di essere intelligente nel posizionare file che sono probabilmente simili tra loro l'uno vicino all'altro nell'archivio, per aiutare il compressore a funzionare meglio; tar non ne sa nulla.

  Vedi anche la risposta di Raffaello e la risposta di Nayuki per ulteriori spiegazioni di questo effetto.

Come questo si applica alle tue impostazioni. Per il tuo esempio specifico, stai lavorando con immagini PNG. Le immagini PNG sono esse stesse compresse, quindi puoi pensare a ciascun file PNG come sostanzialmente una sequenza di byte dall'aspetto casuale, senza schemi o duplicazioni all'interno del file. Non c'è niente da sfruttare per un compressore, se guarda una singola immagine PNG. Pertanto, se provi a comprimere un singolo file PNG (o crei un archivio zip / tar / ... contenente solo un singolo file PNG), non otterrai alcuna compressione.

Ora diamo un'occhiata a cosa succede se provi a memorizzare più copie dello stesso file PNG:

• Piccoli file. Se il file PNG è molto piccolo, tutto tranne tranne zip funzionerà alla grande. Zip fallirà in modo spettacolare: comprime ogni file in modo indipendente, quindi non ha alcuna possibilità di rilevare la ridondanza / duplicazione tra i file. Inoltre, nel tentativo di comprimere ogni file PNG, non ottiene alcuna compressione; la dimensione di un archivio zip sarà enorme. Al contrario, le dimensioni di un archivio tar (compresso con gzip, bzip2 o xz) e un archivio 7z saranno piccole, in quanto memorizza sostanzialmente una copia del file e poi nota che gli altri sono tutti identici - ne traggono vantaggio dal conservare la memoria da un file all'altro.

• File di grandi dimensioni. Se il file PNG è grande, solo 7z funziona bene. In particolare, zip continua a fallire in modo spettacolare. Inoltre, tar.zip e tar.bzip2 falliscono male, poiché la dimensione del file è maggiore della finestra di memoria del compressore: poiché il compressore vede la prima copia del file, non può ridurlo (poiché è già stato compresso ); quando inizia a vedere l'inizio della seconda copia del file, ha già dimenticato le sequenze di byte visualizzate all'inizio del primo file e non è in grado di stabilire che questi dati siano effettivamente duplicati.

  Al contrario, tar.xz e 7z continuano a funzionare alla grande con più copie di un file PNG di grandi dimensioni. Non hanno il limite di "dimensioni di memoria ridotte" e sono in grado di notare che la seconda copia del file è identica alla prima, quindi non è necessario memorizzarla una seconda volta.

Cosa puoi fare al riguardo. Usa 7z. Ha un sacco di euristiche che aiuteranno a rilevare file identici o simili e comprimere molto bene in quel caso. Puoi anche guardare lrzip con la compressione lzop.

Come lo so? Sono stato in grado di verificarlo provando alcuni esperimenti con 100 copie di un file contenente byte casuali. Ho provato 100 copie di un file 4KB, 100 copie di un file da 1 MB e 100 copie di un file da 16 MB. Ecco cosa ho trovato:

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

Come puoi vedere, zip è orribile, non importa quanto sia piccolo il tuo file. 7z e xz sono entrambi buoni se le tue immagini non sono troppo grandi (ma xz sarà fragile e dipenderà dall'ordine in cui le immagini vengono posizionate nell'archivio, se hai alcuni duplicati e alcuni non duplicati mescolati insieme). 7z è dannatamente buono, anche per file di grandi dimensioni.

Riferimenti. Questo è anche spiegato bene in molti post di Super User. Guarda:

• Perché la compressione Gzip non elimina blocchi di dati duplicati?
• Perché Zip è in grado di comprimere un singolo file più piccolo di più file con lo stesso contenuto?
• Comprimere molti file di grandi dimensioni simili
• Comprimi file simili in modo efficiente
• Esiste un programma di compressione o archiviazione per Windows che esegue anche la deduplicazione?
• Programma di compressione file più efficiente per molti file identici?

Innanzitutto, si noti che il formato immagine PNG è fondamentalmente pixel RGB grezzi (con alcuni filtri per la luce) inseriti nel formato di compressione DEFLATE. In generale, i file compressi (PNG, JPEG, MP3, ecc.) Non vedranno alcun vantaggio dal fatto di essere nuovamente compressi. Quindi, per scopi pratici, possiamo trattare il tuo file PNG come dati casuali incomprimibili per il resto dell'esperimento.

In secondo luogo, notare che i formati ZIP e gzip usano anche il codec DEFLATE. (Questo spiegherebbe perché zippare contro gzipare un singolo file produrrà essenzialmente le stesse dimensioni di output.)

Ora permettimi di commentare ogni singolo test singolarmente:

• tar czf folder.tar.gz folder/

  Questo crea un file TAR (non compresso) che concatena tutti i tuoi identici file PNG (con una piccola quantità di metadati e padding aggiunti). Quindi questo singolo file viene inviato tramite il compressore gzip per creare un file di output compresso.

  Sfortunatamente, il formato DEFLATE supporta solo una finestra del dizionario LZ77 di 32768 byte. Quindi, anche se il TAR contiene dati ripetitivi, se il tuo file PNG è maggiore di 32 KiB, sicuramente il compressore DEFLATE non può ricordare i dati abbastanza indietro per trarre vantaggio dal fatto che i dati identici sono ricorrenti.

  D'altra parte, se riprovi questa esperienza con, diciamo, un file PNG da 20 KB duplicato 10 volte, è molto probabile che otterrai un file gzip solo leggermente più grande di 20 KB.

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

  Questo crea un file TAR proprio come prima, quindi utilizza il formato xz e il compressore LZMA / LZMA2. Non sono riuscito a trovare informazioni su LZMA in questa situazione, ma da 7-Zip per Windows so che può supportare finestre di grandi dimensioni (ad es. 64 MiB). Quindi è possibile che tu stia utilizzando impostazioni non ottimali e che il codec LZMA potrebbe essere stato in grado di ridurre il file TAR alla dimensione di un solo file PNG.

• zip -r folder.zip folder/

  Il formato ZIP non supporta archivi "solidi"; vale a dire, ogni file viene compresso in modo indipendente. Abbiamo assunto che ogni file sia incomprimibile. Quindi il fatto che ogni file sia identico non può essere sfruttato e il file ZIP sarà grande quanto la concatenazione diretta di tutti i file.

Il problema è che (la maggior parte) degli schemi di compressione manca della conoscenza dei dati che hai. Anche se decomprimi i tuoi PNG in bitmap e li comprimi nel tarball, non otterrai risultati (significativamente) più piccoli.

Nel caso di molte immagini simili, uno schema di compressione appropriato sarebbe un codec video.

Usando la codifica lossless dovresti ottenere quasi il risultato di compressione perfetto che ti aspetti.

Se vuoi provarlo, usa qualcosa del genere:

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 è la combinazione di Filtri + LZ77 + Huffman (la combinazione di LZ77 + Huffman si chiama Deflate) in questo ordine:

passaggio 1) se il filtro è diverso da Nessuno, il valore dei pixel viene sostituito dalla differenza dai pixel adiacenti (per maggiori dettagli consultare http://www.libpng.org/pub/png/book/chapter09.html ) . Ciò aumenta la compressione delle immagini con gradienti (quindi ... 4 5 6 7 diventa ... 1 1 1 1) e può aiutare in aree dello stesso colore (... 3 3 3 5 5 5 5 5 diventa 0 0 0 2 0 0 0 0 0). Per impostazione predefinita, i filtri sono abilitati nelle immagini a 24 bit e disabilitati nelle immagini a 8 bit con una tavolozza.

passaggio 2) i dati vengono compressi con LZ77 che sostituisce le stringhe ripetute (corrispondenze) di byte con una tupla contenente la distanza dalla corrispondenza e la lunghezza della corrispondenza.

passaggio 3) il risultato del passaggio 2 è codificato con il codice Huffman che sostituisce i simboli a lunghezza fissa con codici a lunghezza variabile, più frequente è il simbolo, più breve è il codice.

Esistono diversi problemi:

Una piccola modifica che influisce su pochi pixel comporterà modifiche nei risultati dai 3 passaggi della compressione png:

1) Il valore filtrato dei pixel adiacenti cambierà (a seconda del filtro utilizzato). Ciò amplificherà gli effetti di piccoli cambiamenti.

2) La modifica significherà che le corrispondenze a quell'area saranno diverse. Ad esempio, cambiando da 333333 a 333533, un'altra occorrenza di 333333 non corrisponderà più, quindi selezionerà un'altra corrispondenza su 333333 con una distanza diversa o selezionerà la stessa corrispondenza ma con una lunghezza più breve e quindi un'altra corrispondenza per gli ultimi 3 byte. Di per sé ciò cambierà molto i risultati.

3) Il problema più grande è nel passaggio 3. Il codice huffman utilizza un numero variabile di bit, quindi anche una piccola modifica comporterà che tutto ciò che segue non sarà più allineato. AFAIK La maggior parte degli algoritmi di compressione non è in grado di rilevare corrispondenze che non sono allineate a byte, quindi ciò impedirà (o almeno ridurrà molto) la compressione sui dati già compressi che seguono la modifica, a meno che il compressore non sia in grado di rilevare corrispondenze che non sono allineate a byte.

Le altre questioni sono già coperte da altre risposte:

4) Gzip utilizza lo stesso algoritmo Deflate con un dizionario da 32 KB, quindi se i file png sono più grandi di 32 KB le corrispondenze non verranno rilevate anche se sono identiche. Bzip2 è migliore in questo aspetto in quanto utilizza un blocco da 900 KB. XZ utilizza LZMA, che IIRC ha un dizionario da 4 MB nel livello di compressione predefinito. 5) Il formato zip non utilizza una compressione solida, quindi non comprime meglio file simili o identici.

Forse i compressori della famiglia PAQ o PPMD ​​comprimeranno meglio, ma se è necessario comprimere molti file di immagini simili, è possibile prendere in considerazione 3 approcci:

1) Memorizza le immagini non compresse (con PNG -0 o in un formato senza compressione) e comprime con un compressore con un dizionario di grandi dimensioni o dimensioni del blocco. (LZMA funzionerà bene)

2) Un'altra opzione sarebbe mantenere i filtri ma rimuovere la compressione Deflate dai PNG. Questo può essere fatto ad esempio con l' utilità ( AdvDef ). Quindi comprimi i PNG non compressi risultanti. Dopo la decompressione puoi conservare il PNG non compresso o comprimerlo di nuovo con AdvDef (ma ci vorrà del tempo).

È necessario testare entrambi gli approcci per vedere quale comprime di più.

3) L'ultima opzione sarebbe quella di convertire le immagini png in un video, comprimerlo con un compressore video lossless come x264 lossless (prestando particolare attenzione all'uso del giusto formato colore) e quindi estrarre i frame in singole immagini png. Questo può essere fatto con ffmpeg. Dovresti anche mantenere la mappatura tra il numero di frame e il nome originale.

Questo sarebbe l'approccio più complesso ma se i png fanno tutti parte di un'animazione potrebbe essere il più efficace. Tuttavia avrai bisogno di un formato video che supporti la trasparenza se ne hai bisogno.

Modifica: esiste anche il formato MNG che non viene usato spesso.

Quando si dispone di set di dati speciali, si utilizzano algoritmi speciali, non strumenti multiuso.

La risposta è che le compressioni senza perdita scelte non sono fatte per quello che fai. Nessuno si aspetta che comprimi due volte la stessa immagine e anche se lo fai (per caso) il controllo su tutti gli input precedenti renderebbe il tuo algoritmo O (n ^ 2) (forse un po 'meglio, ma l'approccio naiv sarebbe almeno n ^ 2).

La maggior parte dei programmi di compressione testati durante l'esecuzione in O (n) aumenta la velocità rispetto al rapporto di compressione ottimale. Nessuno vuole far funzionare il suo computer per 5 ore solo per risparmiare qualche mb, soprattutto in questi giorni. Per input più grandi qualsiasi cosa sopra O (n) diventa un problema di runtime.

Un altro problema è la ram. Non puoi accedere ad ogni parte del tuo input in qualsiasi momento, quando l'input diventa abbastanza grande. Anche trascurando questo, la maggior parte delle persone non vuole rinunciare alla propria RAM o CPU solo per comprimere qualcosa.

Se hai dei pattern nei tuoi file che vuoi comprimere, dovrai fare delle operazioni manuel su di essi, scrivere la tua compressione o potenzialmente usare una compressione di tipo "archivio" (nano). Una compressione per l'archiviazione a lungo termine, che è troppo lenta per l'uso quotidiano.

Un'altra opzione potrebbe essere una compressione video senza perdita di dati.

Il formato file PNG utilizza già internamente l'algoritmo di compressione DEFLATE. Questo è lo stesso algoritmo usato da xz, gzip e zip - solo in alcune varianti. tar.gze tar.xzsfruttare la somiglianza tra i file, che zipnon lo fa.

Quindi, in effetti, esegui la compressione DEFLATE su file compressi DEFLATE - ecco perché i file mantengono quasi le dimensioni originali.

Il bzip2programma (anche un algoritmo correlato) è migliore quando si tratta di file (quasi) identici.

# 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