Evita la doppia compressione delle risorse


13

Sto usando .pngs per le mie trame e sto usando un file system virtuale in un .zipfile per il mio progetto di gioco. Questo significa che le mie trame vengono compresse e decompresse due volte. Quali sono le soluzioni a questo doppio problema di compressione? Una soluzione di cui ho sentito parlare è usare .tgas per le trame, ma sembra secoli fa, da quando l'ho sentito. Un'altra soluzione è implementare la decompressione sul GPUe, dato che è veloce, dimenticare l'overhead.


2
Correlati: se hai usato jpeg, molti programmi zip con il loro formato sono in grado di comprimere anche quelli del 20%, quindi non è necessariamente così male. Qual è il punto della doppia compressione di cui ti preoccupi di più? Ci vuole troppo tempo? Molti formati persino memorizzano i dati già compressi alla lettera e non vi fanno alcuna decompressione.
PlasmaHH,

Risposte:


17

Il formato zip supporta diversi algoritmi di compressione. È possibile utilizzare un algoritmo diverso per ciascun file nell'archivio. Quando si desidera archiviare file già compressi che non beneficiano della compressione aggiuntiva (come PNG) in un archivio zip, è possibile codificare questi file con l'algoritmo "memorizzato" che non si comprime affatto. La finestra di dialogo "Aggiungi all'archivio" di 7-zip ti consente di scegliere questa opzione in "Forza di compressione".

Ma quando non hai solo immagini ma anche altre risorse più comprimibili nei tuoi archivi, potrebbe essere abbastanza noioso scegliere l'algoritmo per ogni singolo file. In tal caso, potresti preferire un formato immagine non compresso in un archivio di compressione.

Il formato TGA conosce molte modalità diverse, alcune delle quali sono compresse e altre no. Quando non si desidera utilizzare la compressione, assicurarsi di scegliere quello giusto nelle opzioni di esportazione dell'editor grafico che si sta utilizzando. Un altro formato di immagine non comprimente è BMP (Windows Bitmap).

Ecco un test che ho fatto. Ho aggiunto la stessa immagine (una risorsa del mio progetto attuale) in diversi formati più volte a un archivio zip, alcuni con algoritmo "deflate" su forza normale e uno con "store". Ci scusiamo per la GUI tedesca. La seconda colonna è una dimensione non compressa, la terza colonna è un algoritmo di compressione e la quarta colonna è una dimensione compressa.

inserisci qui la descrizione dell'immagine

Come puoi vedere, la codifica di deflazione del PNG ha consentito di risparmiare solo uno scarso 0,3%, mentre il BMP con codifica di deflazione è ridotto a un decimo del file originale, che è persino più piccolo della versione PNG. Questo mi ha sorpreso. Mi sarei aspettato che il PNG fosse più piccolo perché il metodo di compressione del PNG dovrebbe essere ottimizzato per i dati immagine mentre ZIP non lo è. Una probabile spiegazione è che il mio editor di immagini (GIMP) abbia aggiunto molte meta-informazioni ai file PNG, cosa che non fa per BMP.

TGA non compresso si è comportato in modo simile a BMP per quanto riguarda le dimensioni dei file prima e dopo lo zippaggio mentre la compressione del file TGA compresso è stata ulteriormente migliorata da ZIP, sebbene non tanto quanto le versioni non compresse.

Potrebbe valere la pena sperimentare altri algoritmi diversi da deflate e con altre impostazioni di resistenza alla compressione. Quale combinazione avrà i migliori risultati dipenderà probabilmente dallo stile delle tue trame. Ma potresti anche considerare di confrontare il carico di risorse del tuo gioco e di influenzare le prestazioni di decompressione nella tua decisione quale impostazione usi.

In conclusione: se si desidera evitare la doppia compressione pur avendo una dimensione file ridotta, utilizzare PNGcon l' Storealgoritmo zip o BMPcon un algoritmo zip di compressione.


5
L'ho fatto su alcune mie foto e PNG (livello di compressione 9) beat zip (livello di compressione ultra) di immagini BMP per tutto il tempo di circa il 20%. Quindi dovrebbe essere un effetto come la meta-informazione.
Trilarion,

3
png ha un'opzione di interlacciamento che riduce la compressibilità ma consente di estrarre un'immagine a bassa risoluzione solo dalla prima parte del file di immagine (come quando si scarica su una banda bassa con connessione), il tuo wall era attivo? inoltre png usa già deflate per la sua compressione.
maniaco del cricchetto,

Sembra che tu abbia usato un povero compressore png, dai un passaggio ai tuoi file attraverso PNGOUT e dovresti ottenere un risultato che non sarà battuto da un file bmp compresso.
aaaaaaaaaaaa,

I tuoi BMP o TGA sono a 24 o 32 bit? Con BMP in particolare è più probabile che siano a 24 bit e la dimensione TGA non compressa suggerisce che è anche a 24 bit. Probabilmente non stai confrontando like-with-like qui.
Maximus Minimus,

@JimmyShelter Sia il TGA che il BMP sono a 32 bit con canale alfa - ne sono sicuro.
Philipp,

7

Non ti preoccupare.

Quando l'algoritmo "deflate" utilizzato nei file .zip rileva un blocco di dati che è già ben compresso, come i dati pixel di un'immagine .png, scopre che non può comprimerlo in modo efficace e lo memorizzerà come letterale dati non compressi. Ciò richiede pochissime spese generali per la decompressione.

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


3
A volte è così semplice, un problema percepito non è necessariamente un problema reale. Anche se effettivamente ci fosse il sovraccarico di decomprimere due volte, la decompressione non comprimibile è un'operazione molto rapida, immagino che il sovraccarico sarebbe solo misurabile.
aaaaaaaaaaaa

La fine della compressione richiederebbe molto tempo per rendersi conto che il file non è comprimibile?
user253751,

Relativamente sì. Non so quale euristica i compressori .zip tipici usano per scegliere la codifica di un blocco, ma potrebbe essere semplice come provare tutte le codifiche e mantenere il risultato migliore. Durante lo sviluppo, se devi avere i tuoi dati in un .zip, probabilmente vorrai forzare tutto da usare storeinvece di deflaterisparmiare tempo, quindi deflatetutto per build di rilascio.
Russell Borogove,

2

Sembra che siano già state fornite delle risposte molto valide, ma ho pensato di dare un'altra:

What are the solutions to this double compression problem?

Soluzione: non fare nulla.

Motivazione: Non è stato indicato alcun problema: sì, si stanno comprimendo le informazioni due volte, ma perché sei preoccupato per questo? La dimensione dei dati è troppo grande? La decompressione è troppo lenta? È più o meno importante delle dozzine di funzionalità che potresti aggiungere, perfezionare, testare e / o eseguire il debug in questo momento?


Fare qualcosa due volte inutilmente è un problema in sé. Almeno l'ho percepito come tale. Ma, naturalmente, hai ragione anche con il tuo suggerimento. Sia la memoria che la velocità di decompressione possono essere un problema, anche se non in questo caso, poiché non sto scrivendo un gioco commerciale.
user1095108,

Sono uno sviluppatore di giochi professionale e posso assicurarti che, a meno che non ci fossero problemi di prestazioni reali e documentati, non ci sprecheremmo un secondo preoccupante di questo: ci vogliono un sacco di $ 0,99 di acquisti o impressioni dell'annuncio per pagare per dire, 8 ore per "correggere" correttamente questo problema. Fare due volte qualcosa non è un problema, anche se potrebbe essere inefficiente. Anche se in questo caso non stai facendo la stessa cosa due volte: hai dati di immagine che vengono archiviati come PNG per la compressione e un sacco di file che vengono archiviati insieme.
NPSF3000,

Vero, ma una volta fatto è fatto per più progetti. Se rifletti sull'algoritmo DEFLATE, è rimasto lo stesso dagli anni ottanta. Saresti un vecchio gramps, se programmassi allora, ma, se conoscessi l'algoritmo, potresti, per esempio, implementarlo sulla GPU e goderti velocità di decompressione superveloci su più progetti.
user1095108,

Quindi spendi, per 2 settimane, un mese implementando Deflate su GPU? E poi ti rendi conto che stai per implementare sulla piattaforma X rispetto a Y e rompe l'algoritmo via Z. Se vuoi creare giochi, FOCUS SU FARE GIOCHI, non preoccuparti di cose inutili come sgonfiare le prestazioni.
NPSF3000,

Una volta che conosci un algoritmo (ri) implementarlo dovrebbe essere facile. Uno scatto, non 2 settimane o un mese. Questo è quello che volevo dire. È in circolazione dagli anni ottanta, potrebbe valere la pena investire un po 'di tempo.
user1095108,

1

Se usi formati speciali come PNG e OGG non avrai bisogno della compressione di ZIP.

PNG, OGG e altri formati già compressi non saranno molto più piccoli comprimendoli nuovamente come ZIP. 100 MB di PNG compressi sono ancora ~ 100 MB.

Script, file di configurazione e altri formati basati su testo traggono grande vantaggio dalla compressione, tuttavia, in genere sono minuscoli in confronto, non memorizzano molti dati. Se il tuo gioco è di 100 MB, i file di testo potrebbero fare 1 MB dell'intero gioco, anche se riesci a renderli di 100 KB attraverso la compressione, hai vinto solo 900 KB, meno dell'1%, non ne vale la pena.

Potresti persino voler utilizzare il file system direttamente invece di utilizzare un file system virtuale basato su zip. Renderebbe molto semplice l'applicazione di patch: puoi semplicemente scambiare tutti i file che hai modificato.


2
A volte uno non ha scelta, per quanto riguarda se utilizzare .zipo meno un file. Ad esempio, sulla piattaforma Android, .apkè un .zipfile che può contenere risorse.
user1095108,

3
Inoltre, ci sono alcuni vantaggi nell'utilizzo di un archivio e i file ZIP forniscono sia la compressione che una struttura di archivio.
MrCranky,

Sì, lo so, sto solo dicendo che l'uso del file system nativo ha anche dei vantaggi. Sono un po 'un sostenitore di "Keep it simple".
API-Beast
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.