Newsgroup: it.comp.os.linux.iniziare
Titolo: gzip e bzip2: grado di compressione

Io sapevo che bzip2 comprimeva di più di gzip, così ho provato a bzippare un 
file gzippato ma il file è cresciuto di dimensioni.
Ho anche degizippato e poi bzippato ma è comunque venuto più grande.
Per la cronaca erano i pacchetti tgz di slackware in ap (volevo trasformare 
i tarball di slackware in tbz2 e modificare installpkg in installpkg_tbz2 in 
modo da accettare quest'ultimi).
Ho rinunciato per i motivi sopradescritti.
Matteo 

 ...
Solito errore da novellini.
gzip - bz2 sono molto diversi da pkzip - winzip
I primi comprimono sempre i dati in ingresso come se
fosssero un unico file, mentre i programmi
pkzip , arj, pkzip sono archiviatori, cioè somo molto
simili a tar e cpio + compressione
Inoltre tieni presente una cosa molto importante:
Non è detto che un file compresso sia più piccolo del file
originale, qualsiasi algoritmo di compressione usi.
Questo accade se il file è molto piccolo o se i dati sono
in qualche modo random (es. file .wav)
La differenza è che pkzip e simili non comprimono i file
se questo avviene mentre bzip2 gzip comprimono sempre i
dati non lo fanno perché questo è quello che devono fare.
Inoltre è intile perderci molto tempo; un file occupa
sempre un numero intero di blocchi quindi lo spazio
effettivo sul disco è maggiore della dimensione del
file. Nella peggiore delle ipotesi un file compresso
occupa lo stesso spazio fisico sul disco di un file
non compresso.
Ma tutto questo è spiegato benissimo nei manuali
quindi:
man tar
man bzip2
man gzip
man compress
oppure (molto meglio)
info tar
info bzip2
info gzip
-- 
Sabatino
*** Sequenza di reboot:
        Carol - Alt - Del

 Ho anche degizippato e poi bzippato ma è comunque venuto più grande.
Caro Matteo, solo con un algoritmo di compressione con perdita di dati
potresti comprimere all'infinito un file. Con un algoritmo di compressione
senza perdita di dati, c'è un limite minimo, altrimenti sarebbe possibile
prendere un file, passarlo in gzip mille volte fino a farlo diventare
grande 1 solo byte, ma devi sapere che alcune delle leggi della fisica si
applicano anche all'informatica.
ciao
gl :)

 ...
Ma a che serve comprimere un file compresso?
Per questo motivo hai tale il comportamento strano.
Per fare la prova che volevi dovevi prima decomprimere
il file originale e copi comprimerlo con un'altro algoritmo.
Scusate se ho diviso la mia replica in due parti
è stato un errore.


 il file originale e copi comprimerlo con un'altro algoritmo.
Ed infatti č quello che ho anche fatto.
gzip -d file.tar.gz
bzip2 file.tar
risultato: il secondo č piů grande del primo.
Per la storia di pkzip vs gzip la conosco bene. Ma qui parlo di un solo file 
(in questo caso un .tar), non di una alberatura intera.
A meno che non intendevi qualcos'altro che non sono riuscito a capire dal 
tuo primo post.
Matteo

 [...]
Per il resto, se non capisci vedi il post di gl:)
ed i manuali dei vari programmi


 ed i manuali dei vari programmi
ok. provo a spiegarmi in modo diverso.
So che ci sono due tipi di compressione: a perdita di dati (jpeg/mpeg...) e 
non a perdita di errore (Z,gz,bz2,rar,zip,lha...). In aggiunta gli archivi 
non compressi (tar,cpio,dump...)
A me interessano i secondi, in particolare: compress, gzip e bzip2 (che 
comprimono i file singoli).
E' molto comune che, quando si scaricano programmi, sorgenti in particolare, 
vengono proposti i tar.gz e i tar.bz2
p.e.: 
ftp://ftp.kernel.org/pub/linux/kernel/v2.6/
linux-2.6.10.tar.bz2                      34 MB     Dec 24 22:38
linux-2.6.10.tar.gz                       43 MB     Dec 24 22:38
Come potete vedere la differenza è di BEN 9Mb.
Ora io (che uso slackware) ho pensato:
installpkg supporta i tgz (alias tar.gz)
e se trasformassi tutto in tbz2 (alias tar.bz2) e modifico installpkg (che è 
uno script shell)?
E così ho fatto.
E ho fatto l'esperimento con un pacchetto a caso (piccolo in quanto 
notoriamente bzip2 è più lento di gzip, propio per il suo grado di 
compressione più elevato):
workbone-2.40-i386-3.tgz    12241 byte
workbone-2.40-i386-3.tar    30720 byte
workbone-2.40-i386-3.tar.bz2    12649 byte
Ergo: non mi conviene fare quello che stavo per fare (e pensare che potrebbe 
essere stata una proposta per Patrick).
Ora la mia è solo una constatazione di fatto. Mi viene da pensare una cosa 
(ci ho pensato solo ora, ho fatto la prova e ha funzionato).
Stesso esperimento con
linux-howtos-20050124-noarch-1.tgz    9083261byte
linux-howtos-20050124-noarch-1.tar    32450560byte
linux-howtos-20050124-noarch-1.tar.bz2    7349392byte
risparmio di 1,7Mb
che sia che bzip2 sia ottimizzato per la compressione di testi piuttosto che 
quella dei binari?
ls     72608b
ls.gz    34651b
ls.bz2    34402b
Il risparmio c'è ma non è poi così alto, effettivamente.
Altra prova: slackware/ap/*tgz
du -sk = 46088
gzip -d *
du -sk = 135892
bzip2 *
du -sk = 39680
boh! (le prove le sto facendo man mano che scrivo)
L'ultima cosa che mi viene da pensare è che la compressione si fa vedere su 
file grossi (mysql.tgz=6.7Mb mysql.tar.gz=5.5Mb)
Mah!!
Che strano il mondo della compressione
Matteo

dimenticavo:
questo (non so perchè) mi sembra stia diventando un flame.
meglio chiuderlo qui.
saluti,
Matteo 

 originale, qualsiasi algoritmo di compressione usi.
Secondo la teoria: usando un qualsiasi sistema di copressione lossless 
(perfetto) su TUTTI i files di una data dimensione il fattore medio di 
compressione è 1.
Ad esempio, esistono 2^(8*1024) file diversi di un kByte, la loro 
dimensione totale è 1024*2^(8*1024) bytes.
Se li comprimo uno alla volta con un metodo lossless perfetto la somma 
delle dimensioni dei files compressi rimane uguale, cioè 1024*2^(8*1024).
Il motivo per cui a noi torna comodo comprimere è che utilizziamo solo 
il sottoinsieme "utile" di tutti i files possibili.
-- 
Lorenzo `paulatz' Paulatto
Trieste
``Se Gauss fosse vivo oggi, sarebbe un hacker.''
      --Peter Sarnack (Princeton University)

 che quella dei binari?
No l'algoritmo che usa bzip2 è il Block Sorting
Text Compression (detto anche di Weeler-Burrows).
Esso divide un file in blocchi (da 100k 200k ... 900k)
e li comprime separatamente. Lavora meglio con
blocchi di grandi dimensioni.
Infatti per i file piccoli (meno di 100k) hai notato
che gzip e bzip2 hanno la stessa compressione
hai notato differenze di 200 byte su file di
300.000 byte, meno del 0,1%)
Mentre per file abbastanza grossi la differenza si nota.
PS per carità nessun flame, almeno da parte mia,


 Mentre per file abbastanza grossi la differenza si nota.
Grazie, è la risposta che volevo.
Ho appena fatto un controllo (sempre sotto slackware), e risulta infatti che 
nel tree source/ alcuni sono compressi in gzip e altri in bzip2 (a una prima 
vista mi sembravano tutti in bzip2, l'ho notato per caso).
Matteo 


Non ci ho capito un granchè, ma credo che "1" perfetto non sia propio.
Se un algoritmo non riesce a comprimere un file, il risultato non sarà un 
nuovo file identico al precedente, ma più grande in quanto gli dovrà 
aggiungere informazioni aggiuntive (tipo di compressione usato, nome 
file...).
Matteo 

 Non ci ho capito un granchè, ma credo che "1" perfetto non sia propio.
In pratica dice che la teoria sostiene che la compressione è mediamente
inutile, dove la media è calcolata su un numero molto grande di esperimenti.
O sbaglio?
-- 
Non capisco tutta questa eccitazione per il multitasking: io sono anni
che leggo in bagno.
                -- Carlo Landini

 O sbaglio?
Ah!, ho capito.
Per fortuna la legge sui grandi numeri č solo teoria e in pratica la 
compressione esiste quasi sempre (dove piů dove meno).
Matteo