[Compressione] Statistiche tempi e spazio

[franksisca]

Avete qualche info e statistiche sulla compressione?

vorrei poter rispondere a queste domande:

comprimere un jpg di dimensione x ti costa y tempo e guadagni z% spazio

[71106]

Originariamente inviato da franksisca

Avete qualche info e statistiche sulla compressione?

vorrei poter rispondere a queste domande:

comprimere un jpg di dimensione x ti costa y tempo e guadagni z% spazio

Problema interessantissimo che purtroppo non sono in grado di risolvere perche' non so bene come funziona l'algoritmo di compressione JPEG.

Ipotizzo che funzioni nel seguente modo "banale": partendo dalla bitmap originale l'algoritmo crea un istogramma, fissa un obiettivo sul massimo numero di colori (p.es. 128), applica la perdita aggregando assieme colori simili fino a ottenerne al massimo 128, e poi emette in output la palette e i pixel sotto forma di indici nella palette.

I pixel RGB della bitmap originale occupano 24 bit ciascuno, mentre gli indici emessi in output occupano log2(128) = 7 bit ciascuno, un risparmio del ~70% se escludiamo le dimensioni della palette.

Per quanto riguarda il tempo necessario alla compressione, si tratta di calcolare la complessita' asintotica dell'algoritmo. Per calcolare l'istogramma si puo' usare un albero di ricerca autobilanciato, quindi complessita' O(N*log(N)). Per aggregare i colori simili... boh.
Ed infine per emettere i pixel di output bisogna enumerare quelli di input e fare un altro lookup per ciascuno, quindi credo un altro O(N*log(N)).

Scusa l'incompletezza ma sono pigro.

L'argomento comunque mi interessa molto.

Originariamente inviato da Antonio23

non credo di aver capito la domanda oppure mi sembra troppo banale...

se comprimi del 50% andrai il 50% piu' veloce nel trasferire i tuoi file (tempo) e occuperai il 50% dello spazio nell'immagazzinarli (spazio)...

Non mi pare siano queste le variabili che franksisca ha chiesto...

[71106]

Ovviamente alla fine ho googlato e scoperto che la ruota che ho appena reinventato non c'entra una beneamata con JPEG ma e' piuttosto simile a GIF.

[zeMMeMMez]

Originariamente inviato da franksisca

Avete qualche info e statistiche sulla compressione?

vorrei poter rispondere a queste domande:

comprimere un jpg di dimensione x ti costa y tempo e guadagni z% spazio

La domanda è malposta, perchè "jpg" non significa nulla, o comunque pochissimo. Se vuoi ti segnalo l'apposito forum russo (ma bene o male si scrive in inglese) dove troverai veri esperti, da tutto il mondo, su questo argomento.

Per cortesia astenersi da commenti su cosa "significa" JPG, non ho una gran voglia di spiegare la rava e la fava.

[franksisca]

Originariamente inviato da Antonio23

non credo di aver capito la domanda oppure mi sembra troppo banale...

se comprimi del 50% andrai il 50% piu' veloce nel trasferire i tuoi file (tempo) e occuperai il 50% dello spazio nell'immagazzinarli (spazio)...

non sarebbe la prima volta per me che espongo male una domanda

Originariamente inviato da 71106

Problema interessantissimo che purtroppo non sono in grado di risolvere perche' non so bene come funziona l'algoritmo di compressione JPEG.

Ipotizzo che funzioni nel seguente modo "banale": partendo dalla bitmap originale l'algoritmo crea un istogramma, fissa un obiettivo sul massimo numero di colori (p.es. 128), applica la perdita aggregando assieme colori simili fino a ottenerne al massimo 128, e poi emette in output la palette e i pixel sotto forma di indici nella palette.

I pixel RGB della bitmap originale occupano 24 bit ciascuno, mentre gli indici emessi in output occupano log2(128) = 7 bit ciascuno, un risparmio del ~70% se escludiamo le dimensioni della palette.

Per quanto riguarda il tempo necessario alla compressione, si tratta di calcolare la complessita' asintotica dell'algoritmo. Per calcolare l'istogramma si puo' usare un albero di ricerca autobilanciato, quindi complessita' O(N*log(N)). Per aggregare i colori simili... boh.
Ed infine per emettere i pixel di output bisogna enumerare quelli di input e fare un altro lookup per ciascuno, quindi credo un altro O(N*log(N)).

Scusa l'incompletezza ma sono pigro.

L'argomento comunque mi interessa molto.



Non mi pare siano queste le variabili che franksisca ha chiesto...

ragionamento ok

Originariamente inviato da 71106

Ovviamente alla fine ho googlato e scoperto che la ruota che ho appena reinventato non c'entra una beneamata con JPEG ma e' piuttosto simile a GIF.

Originariamente inviato da Antonio23

minchia, ho realizzato solamente ora che x y e z erano delle incognite

Originariamente inviato da zeMMeMMez

La domanda è malposta, perchè "jpg" non significa nulla, o comunque pochissimo. Se vuoi ti segnalo l'apposito forum russo (ma bene o male si scrive in inglese) dove troverai veri esperti, da tutto il mondo, su questo argomento.

Per cortesia astenersi da commenti su cosa "significa" JPG, non ho una gran voglia di spiegare la rava e la fava.

JPg era indicativo.

Se mi indichi il forum magari riesco a tirarci fuori qualcosa... comunque diciamo che ragionando la domanda può essere posta in questo modo:

Riesco, a partire dalla tipologia del file, a capire se mi conviene o no comprimere prima di spostare il file?

Il contesto (non è importante ma magari può aiutare a capire il mio obiettivo) è lo storage su cloud. In pratica voglio sapere se mi conviene comprimere i file prima di mandarli in cloud, e se questa assunzione posso farla in base alla tipologia di file.
per dire... mp3 e jpg non li comprimo, docx e txt si!


ovviamente tutte le estensioni usate sono indicative

[tomminno]

Originariamente inviato da franksisca

Il contesto (non è importante ma magari può aiutare a capire il mio obiettivo) è lo storage su cloud. In pratica voglio sapere se mi conviene comprimere i file prima di mandarli in cloud, e se questa assunzione posso farla in base alla tipologia di file.
per dire... mp3 e jpg non li comprimo, docx e txt si!


ovviamente tutte le estensioni usate sono indicative

jpeg e mp3 puoi sempre ricomprimerli ulteriormente perdendo in qualità. Docx al loro interno sono già compressi, si possono comprimere ulteriormente con algortimi più efficienti lato compressione.
Ma senza i dati a contorno la domanda non ha senso.
Probabilmente se hai una banda lenta la compressione prima della trasmissione potrebbe essere sempre utile, sicuramente ci metterà meno il pc a comprimere un doc di 5Mb in 4,5MB che un'adsl scrausa a trasmettere quei 500Kb risparmiati. Ma se hai una fibra trasmettere 4,5 o 5 MB ti cambia veramente niente.

[franksisca]

Originariamente inviato da tomminno

jpeg e mp3 puoi sempre ricomprimerli ulteriormente perdendo in qualità. Docx al loro interno sono già compressi, si possono comprimere ulteriormente con algortimi più efficienti lato compressione.
Ma senza i dati a contorno la domanda non ha senso.
Probabilmente se hai una banda lenta la compressione prima della trasmissione potrebbe essere sempre utile, sicuramente ci metterà meno il pc a comprimere un doc di 5Mb in 4,5MB che un'adsl scrausa a trasmettere quei 500Kb risparmiati. Ma se hai una fibra trasmettere 4,5 o 5 MB ti cambia veramente niente.

ok, l'approccio che mi interessa è proprio questo.

ok jpg e mp3 posso ulteriormente comprimerli, ma mentre comprimere un mp3 in 480 porta ad una perdita di dati "irrilevante", ridurre un 180kb è impensabile. (tralasciamo la filosofia in merito)

Quindi posso dire che, statisticamente, mp3 in 360 non conviene ridurli, perchè il tempo per comprimerli non mi fa guadagnare tanto in fase di trasmissione dati.

magari un documento di 180 mega, compresso diventa 30 mega, allora in quel caso mi conviene.

vorrei sapere se ci sono dei dati che mi possano meglio illuminare. Capisco che è un discorso molto borderline e molto "dipendente" da tante variabili, e quindi forse sto chiedendo qualcosa di impossibile.

[zeMMeMMez]

Originariamente inviato da Antonio23

tranquillo che nessuna persona sana di mente su questo forum si sogna di venire a chiedere a te di spiegargli qualcosa.

In effetti hai ragione tipicamente sono gli ordinari a farlo

[zeMMeMMez]

Sulla domanda.
La risposta é: dipende ovviamente dai dati più precisamente dalla loro entropia e da quale punto di Pareto vuoi partire.
Dipende inoltre è fortemente dalla quantità di memoria e dalla CPU che vuoi usare,oltre cheda banda e latenza e dimensione dei dati
Supponendo che la domanda sia di genere hobbystico e non accademico la risposta è, grosso modo, che conviene comprimere dati che si sa già essere fortemente e facilmente riducibili
Come ad esempio i backup dei database soprattutto in formato testo (es mysql)
Altrimenti no, in generale non conviene.
Con maggiori informazioni si possono dare valutazioni quantitative

Per inciso se la domanda sottende 'come faccio a spedire grandi quantità di dati su cloud' la risposta è : parliamo di backup aggiornati più o meno spesso oppure un caricamento una tantum?

[franksisca]

Originariamente inviato da zeMMeMMez

Sulla domanda.
La risposta é: dipende ovviamente dai dati più precisamente dalla loro entropia e da quale punto di Pareto vuoi partire.
Dipende inoltre è fortemente dalla quantità di memoria e dalla CPU che vuoi usare,oltre cheda banda e latenza e dimensione dei dati
Supponendo che la domanda sia di genere hobbystico e non accademico la risposta è, grosso modo, che conviene comprimere dati che si sa già essere fortemente e facilmente riducibili
Come ad esempio i backup dei database soprattutto in formato testo (es mysql)
Altrimenti no, in generale non conviene.
Con maggiori informazioni si possono dare valutazioni quantitative

È di genere obbistico, e quindi la tua supposizione fa scopa con la mia. MP3 e JPG in generale non si comprimono, documenti e testi si.

Originariamente inviato da zeMMeMMez

Per inciso se la domanda sottende 'come faccio a spedire grandi quantità di dati su cloud' la risposta è : parliamo di backup aggiornati più o meno spesso oppure un caricamento una tantum?

utilizzo quotidiano.

Però a questo punto ti aggancio un'altra domanda.

Supponi di avere un file video da 700 mega. e devi upparlo su un cloud che limita il singolo file a 25 mega.

cosa faresti, prima compressione e poi split, o viceversa?
io fare prima compressione e poi split.

[71106]

Originariamente inviato da Antonio23

intendi quelli del reparto?

[zeMMeMMez]

Originariamente inviato da franksisca

Supponi di avere un file video da 700 mega. e devi upparlo su un cloud che limita il singolo file a 25 mega.

cosa faresti, prima compressione e poi split, o viceversa?
io fare prima compressione e poi split.

I file video nella stragrande maggioranza dei casi non si compriamo. O comunque pochissimo.
Quindi splitterei senza comprimere affatto.
Tieni presente, come certamente saprai, che anche i docx non si comprimono più di tanto, perché sono degli zip rinominati

Quindi anche li il guadagno tende a zero

Comprrimendo il contenuto tipico di un hard disk casalingo difficilmente il guadagno è maggiore di 5 o 10% (considerato video, foto e così via)
Per rispondere alla tua domanda non ti resta che fare la cosa più logica.
Prova

Cioè comprimi il tuo set di file e vedi se il gioco vale la candela

[!fazz]

più che comprimere un file alla volta valuterei comprimere aggregazioni di file, non tanto per il risparmio in termini di spazio e banda ma bensì per ridurre gli overhead di trasmissione che spesso, dipendentemente dal protocollo usato per il trasferimento hanno un impatto devastante (classico esempio su trasferire via ftp 10'000 file da 5KB vs trasferire un unico file da 50MB)
te lo dico perchè muovere parecchi file su cloud può essere problematico, io a gennaio ho spostato da un cloud ad un altro (quindi download + backup + upload) poco meno di 1 TB di file ed è stato un parto riuscire a fare tutto in meno di 2 settimane

[franksisca]

Originariamente inviato da !fazz

più che comprimere un file alla volta valuterei comprimere aggregazioni di file, non tanto per il risparmio in termini di spazio e banda ma bensì per ridurre gli overhead di trasmissione che spesso, dipendentemente dal protocollo usato per il trasferimento hanno un impatto devastante (classico esempio su trasferire via ftp 10'000 file da 5KB vs trasferire un unico file da 50MB)
te lo dico perchè muovere parecchi file su cloud può essere problematico, io a gennaio ho spostato da un cloud ad un altro (quindi download + backup + upload) poco meno di 1 TB di file ed è stato un parto riuscire a fare tutto in meno di 2 settimane

quindi meglio aggregare file che splittare?

però pensavo di splittare il file e lanciare x thread paralleli per l'upload... certo sorgono problemi di congestione della rete o sovraccaricamento del pc... però effetivamente forse è meglio decidere una minimun size di aggregazione e fare upload di file di almeno 10 mega (per esempio) e file da 1giga magari lo splitto in 3 da 350 circa...

[cdimauro]

Aggregare tanti file, specialmente se piccoli, è sicuramente un'ottima soluzione.

Se lo fai per tipologia di file, puoi anche comprimerli (SE sono comprimibili), in modo da guadagnare anche da questo punto di vista. In particolare comprimere per tipologia di file te lo consiglio usando un algoritmo di tipo "solid compression", come quello messo a disposizione da 7Zip.

Puoi anche pensare di ricomprimere tutti i file che sono già compressi. Ad esempio zip e tgz li puoi ricomprimere usando 7zip, che riesce a fare di meglio. Con la stessa logica, potrei ricomprimere in generale qualunque file che usi uno di questi formati come contenitore, e dunque anche i file XML di Office di Microsoft, o gli OpenDocument.

[franksisca]

Originariamente inviato da cdimauro

Aggregare tanti file, specialmente se piccoli, è sicuramente un'ottima soluzione.

Se lo fai per tipologia di file, puoi anche comprimerli (SE sono comprimibili), in modo da guadagnare anche da questo punto di vista. In particolare comprimere per tipologia di file te lo consiglio usando un algoritmo di tipo "solid compression", come quello messo a disposizione da 7Zip.

Puoi anche pensare di ricomprimere tutti i file che sono già compressi. Ad esempio zip e tgz li puoi ricomprimere usando 7zip, che riesce a fare di meglio. Con la stessa logica, potrei ricomprimere in generale qualunque file che usi uno di questi formati come contenitore, e dunque anche i file XML di Office di Microsoft, o gli OpenDocument.

thanks