Newsgroup: it.comp.aiuto
Titolo: compessione files.

Si possono comprimere, ovvero zippare, i files tipo jpg?
Insomma, posso prendere una foto e ridurla in un file zip?
E se si, quale è la procedura?
Ciao.

On Wed, 28 Jan 1998 20:09:37 GMT, 
rom...@krol.it
 (Fabrizio Romita)
wrote:

Volendo e' possibile, ma non ti servirebbe a miente perche' un file in
jpg e' gia' compresso al massimo e non e' possibile ridurne
ulteriormente le dimensioni.
Comunque se hai winzip 6.3 la procedura e' semplicissima:
basta cliccare col destro sul file, puoi scegliere tra due azioni:
-ADD TO ZIP per creare un nuovo archivio, o aggiungere il file ad un
archivio esistente
-ADD TO NOMEFILE.ZIP  crea un archivio e lo chiama con il nome del
file.
Oppure apri WinZip e usi la procedura classica cliccando su "NEW", o
trascinando il file nella finestra del programma.
Ciao
Renato

 Ciao.
Puoi praticamente zippare qualsiasi file (tranne quelli gia' compressi,
ovvio) con WinZip 6.3, lo trovi su
http://www.winzip.com/
Molto facile da usare, ha un pratico Wizard che ti aiuta nelle varie
fasi di compressione/decompressione dei file.
Byezz
--
Rimuovere *X* per eventuali repliche.
Jedi Knight: The Dark & Light Morbius site
http://www.geocities.com/TimesSquare/Dungeon/6512/jk_main.htm
The Morbius homepage
http://www.geocities.com/TimesSquare/Dungeon/6512/


http://www.winzip.com/
Avevate ragione, si comprime , ma la compressione di un file jpg č
inutile... č sempre lo stesso spazio.
Ciao.

E se si, quale è la procedura?
L'algoritmo di compressione dei .jpg e' meno efficace di quello usato
per i file .zip.
E un file .jpg non e' ulteriormente comprimibile.
Il mio consiglio e' quello di aprire il file .jpg con un programma di
grafica, e salvarlo come .gif.
Infatti per il file .gif si adotta lo stesso algoritmo adottato per i
.zip.
La convenienza di questo metodo dipende dal tipo di immagine nel .jpg
Andrea
------------------------------------------------
combatti anche tu il "nano scemo" :
http://www.geocities.com/Hollywood/Studio/6989
------------------------------------------------

La convenienza di questo metodo dipende dal tipo di immagine nel .jpg
Mi permetto di aggiungere che jpg e' un formato a perdita di
informazione, e che quindi riesce a comprimere "molto di piu'"
rispetto ad un gif, ma la qualita' finale e' meno alta.
	Comunque, come qualsiasi algoritmo di compressione,
l'efficacia varia a seconda del tipo di dato originale. E' opinione
diffusa che sia vantaggioso utilizzare ipg solo con immagini di tipo
fotografico (con molte sfumature e contorni non sempre netti), mentre
gif sia meglio per i disegni fatti al computer.
Ciao, Mac.
Antispam? Si grazie!
   Per rispondere in e-mail
   anteporre "Ultra" a "Mac" nell'indirizzo!

gif sia meglio per i disegni fatti al computer.
Comunque, per concludere il discorso ho provato a comprimere in
entrambi i modi:
Comprimendo il jpg non si ottiene niente, perchè il file ha la stessa
grandezza.
Comprimendo lo stesso file, riversato in gif, si ha una compressione,
ma è superiore o uguale o di poco inferiore( scusate se non sono
preciso, ma appena fatto e verificato ho buttato tutto e lasciato
perdere) a quella del jpg.
Insomma non è conveniente nessuno dei due casi.
Ciao.

inutile... č sempre lo stesso spazio.
Perche' il jpg e' gia' compresso !
Ma se lo salvi come .gif dovresti salvare qualche byte...


 .zip.
Mi sento di **SCONSIGLIARE** vivamente questo metodo.
1)  Per esperienza personale, una  immagine .gif convertita in jpg con
una qualita' del 75%  (indistinguibile ad occhio nudo) e' NOTEVOLMENTE
piu' piccola dell'originale.
2)  Una immagine  JPEG  ha una   cromatica a  24   bit (i colori  sono
16777216), mentre le  immagini GIF ha  una cromatica a 256 colori  (e'
nata pensando alle schede vga). Quindi passando da JPEG a GIF c'e' una
notevole perdita potenziale, in quanto il  colore di ogni punto verra'
sostituito con quello che meglio lo approssima  tra i 256 disponibili.
Il risultato puo' essere   la  famosa comparsa di  fastidiose  placche
nell'immagine. L'errore introdotto  invece prendendo una immagine a 24
bit e comprimendola con JPEG (che e' un  formato lossy, con perdita di
qualita') e invece  di gran  lunga inferiore,  e in pratica  non viene
percepito dall'occhio.
Oserei dire che il consiglio dato e' quindi completamente errato. Sorry.
Attenzione, i dati nello header sono alterati per proteggermi dagli spammer.
L'indirizzo corretto e' nella firma.
o   oooooo	Gian Uberto Lauri        "So, are you working on finding
      o    o	
sa...@dei.unipd.it
        that bug *now* or leaving it until
     o o				  later?" - "Yes!" 

 diffusa che sia vantaggioso utilizzare ipg solo con immagini di tipo
Parlando di dimensioni:
Conviene JPEG  quando si  ha una cromatica   elevata. Ho compresso con
JPEG (qualita' 75%) una marea di scan di immagini tratte da riviste di
animazione   giapponese  (formato GIF) e  il    risultato era piu' che
accettabile per l'occhio,  insuperabile  per   il disco (da    qualche
centinaio di K a meno di 100 K).
Quando si ha un numero  di colori nell'ordine dei  16 o meno, conviene
GIF,  perche' il rumore   introdotto da JPEG  puo'  cominciare a farsi
sentire.
Parlando di qualita':
Quando l'immagine NASCE con meno di 257 colori, con GIF non hai alcuna
perdita. Quando l'immagine nasce con una cromatica maggiore puo' darsi
che qualche immagine dia  un errore minore  con la codifica GIF, ma va
visto caso per caso. In generale in questo  caso conviene JPEG per uso
hobbistico, e TIFF o altro formato (magari  compresso a valle con ZIP)
per un uso piu' professionale.


 perdere) a quella del jpg.
E questo fa fare una figura non proprio splendida ha  chi ha detto che
l'algoritmo di   compressione di  JPEG  e'   meno  forte  rispetto  al
Lempvel-Ziv. Il fatto che  il GIF sia comprimibile  indica che non  e'
stata tolta tutta  la ridondanza (ovvero non e'  stato  tolto tutto il
toglibile).


 Ma se lo salvi come .gif dovresti salvare qualche byte...
Poco probabile salvare qualche byte, sicuro perdere qualche milione di
colori (16776960 colori per la precisione).


del 99.8%.
Premetto che non ho intenzione di aprire una polemica (anche perche'
le tue basi teoriche sull'argomento mi sembrano piu' ferrate delle
mie), il calcolo che tu hai fatto pero', a me suona come un "falso".
	Infatti il ragionamento che applichi sarebbe estendibile anche
al seguente paradosso:
	"Avendo una immagine con infiniti colori, qualsiasi immagine
con un numero finito di colori sarebbe INFINITAMENTE piu' brutta,
perche' la perdita cromatica tende al 100%"
	Invece la differenza fra un'immagine a 65K di colori e una a
24 bit e' - all'atto pratico - praticamente nulla, specialmente
considerando l'utilizzo di palette "ad hoc".
	Infatti sfido l'occhio di chiunque a campionare 24bit di
colori, ma anche solo 65.000!
	Dal punto divista numerico, poi, sono ben poche le immagini
scannerizzate che contengano realmente oltre 65'000 colori.



Io non so se all'atto pratico le immaggini scannerizzate a 65000
colori siano molte o poche, pero' se ti faccio vedere la stessa foto
in formato jpg oppure in formato gif 256 colori, ti assicuro che la
differenza si vede... non so se solo su quella foto che trattavo io,
ma si vede.
Ciao.
-------------------------------
-------------------------------
Rimuovere NOSPAM dall'address.
Fabrizio Romita

toglibile).
Non sono confrontabili i due algoritmi dato che il primo e' a perdita
di informazione mentre il secondo no.
Il fatto che il GIF sia comprimibile (si salva giusto qualche byte) e'
dato dal fatto che sono presenti nel file informazioni, a loro volta
non compresse.


Ma hai una vaga idea di come funziona ?
Certo, dato che ho scritto io stesso un programma che comprime i dati
con entrambi gli algoritmi.
L'hai detto tu stesso che la compressione dei .JPG si basa
sull'algoritmo di Huffman.
Informati, vedrai che e' meno efficace.


 scannerizzate che contengano realmente oltre 65'000 colori.
Basta una pagina A4 a 600 DPI ad  avere un numero di punti sufficienti
ad ospitare tutti i colori di un colorcube a 24 bit. Teoricamente.
Poi in pratica la   cosa e' diversa,  non  per niente per fare  i demo
delle possibilita' di un  prodotto  grafico usano foto particolari  di
ambienti dalla cromatica molto ricca.


 non compresse.
In jpg no :)


 Informati, vedrai che e' meno efficace.
Probabile  che da solo  sia meno efficace,  ma se quelli dello JPEG lo
hanno scelto c'e' un motivo MOOOLTO valido.


 Informati, vedrai che e' meno efficace.
Probabile  che da solo  sia meno efficace,  ma se quelli dello JPEG lo
hanno scelto c'e' un motivo MOOOLTO valido.
(Ah, Huffman si  avvicina molto al limite  teorico di Shannon, mi dice
qui una telecomunicazionista...)


In jpg no :)
Questo e' vero, ma purtroppo per il gif sono necessarie !


hanno scelto c'e' un motivo MOOOLTO valido.
Evidentemente si adatta bene al caso dei dati che hanno subito le
trasformazioni prima dell'applicazione di huffman.
Evidentemente il LZ a quel punto si comporta meno bene.
In realta' io credo che uno dei motivi per cui non si usi il LZ sia
anche quello della dovuta registrazione con conseguente pagamento dei
diritti d'autore alla Compuserve.


 Questo e' vero, ma purtroppo per il gif sono necessarie !
Ovvio, ogni .gif si deve portare dietro 3xcolori byte di palette...


 diritti d'autore alla Compuserve.
I diritti non sono per l'uso globale di Gif di compuserve ? (non solo
per lo LZ).

per lo LZ).
Per l'uno e per l'altro.


ambienti dalla cromatica molto ricca.
Cioe' per una volta non si rendono le cose piu' semplici? Si vede che
lavori sotto un sistema diverso da Win! Da questa parte dell'universo
e' gia' ritenuto sufficiente che l'applicazione non generi un "errore
di protezione generale", per essere acquistata!  :-((((
Comunque grazie per la tua reply, completa e istruttiva!


A livello implementativo poi, LZ e' preferibile di gran lunga.
Ehi! Questa non e' una gara privata a vedere chi e' il piu' bravo! E'
un NG!!! Che ne dici di renderci partecipe e fare un bel...
..."pkunzip" delle tre righe quotate?!
Con simpatia, Mac.


 Per l'uno e per l'altro.
Hmmm... Non e' che il Lempel-Ziv ha vari flavour ? Di sicuro Compuserve
non ha nessuna mano sul LZ77 (che mi pare buono assai).


 piu' capitato (anche se assieme avevo anche cambiato scheda grafica).
Mi e' capitato  con NT 4.0.  invece  di usare  un colore pieno,  usava
pattern di colori diversi. Non ti dico poi come  apparivano le icone a
256 colori.
 
Saluti :)


rispetto ad una bitmap a 8 bit per pixel.
Io mi riferisco al tipo di algoritmo implementato che non e'
"data-lossy"  mentre nel .jpg si.


Ehi! Questa non e' una gara privata a vedere chi e' il piu' bravo!
Infatti non lo e' !
Che io sappia i ng sono dei luoghi di discussione e noi stiamo
discutendo da buoni amici. :-)


non ha nessuna mano sul LZ77 (che mi pare buono assai).
Io so che l'algoritmo LZ e' registrato.


qui una telecomunicazionista...)
Infatti si tratta di alberi, nient'altro che alberi ;-))
In ogni caso, tornando al lempel-ziv, ho conservato quella parte di
documento che si rifaceva alla licenza d'uso per quando scrissi il mio
compressore/decompressore in C, che usava i tre algoritmi RLE, Huffman
e LZW.
Questo era quanto lessi :
"If you are developing an application for your own personal use, for
evaluation, or for limited distribution then the cost of an LZW
license should be minimal. 
A license to distribute commercial applications that load and save
LZW-compressed images generally requires modest royalty payments to
Unisys. "
Ciao ;-)
--------------------------------------------------------
Andrea      
mica uno qualunque...
--------------------------------------------------------

rispetto ad una bitmap a 8 bit per pixel.
Ma perche' il formato GIF e' stato studiato per quello !
Per quanto invece riguarda l'algoritmo, che non e' "lossless" osserva
la seguente tabella relativa alla compressione di un'immagine 314x217
pixels, a 24 bit nel formato TIFF :
Compression : none
Image bits/pixel : 24
File Format : TIFF
Size (kb) : 223,646
(% of original) 100
Compression : LZW
Image bits/pixel : 24
File Format : TIFF
Size (kb) : 243,829
(% of original) 109
Come vedi, utilizzando l'algoritmo LZW,  non c'e' perdita di dati,
c'e' solo un aumento delle proporzioni del file che rende l'algoritmo
inutilizzabile.


 
Voi mica dire   che con  256  simboli  sei  in grado  di  ricostruirne
esattamente 16777216 ???
Questo vorrebbe dire che c'e' un programma  che nel suo output ha piu'
informazione di quella  che riceve, ovvero viola  una delle leggi base
dell'informatica ? 
Sai vero cosa vorrebbe dire avere un programma di tale fatta ?
Che  potrei   codificare qualsiasi  cosa  con 0  bit (se  scoprissi un
algoritmo  simile verrei ucciso  da  sicari pagati da Western  Digita,
Seagate, IBM...)


dell'informatica ? 
E' evidente che hai capito male.
Io ti ho appena confermato che il formato GIF e' stato studiato per
gli 8 bit per pixel e non per i 24.
D'altronde e' una questione solo legata al formato del file, a
prescindere dall'algoritmo usato che e' una versione leggermente
modificata del LZW, lo stesso dei .TIFF.
Il LZW, come l'huffman, come l'rle, come lo shannon-fano, ecc..ecc..
e' "loss-less" e quindi non produce perdita di informazione.
Con la frase "nella codifica GIF non c'e' "perdita" di dati ..." mi
riferivo al fatto che comprimendo immagini a 8 bit per pixel non c'e'
perdita di dettaglio, mentre nel .JPG si'.
E' per questo che quest'ultimo si usa per immagini di tipo
fotografico.
