Una nota da pignolo, forse inutile ma gradirei conferma/smentita da qualcuno più esperto: Se il tiff usa il metodo di comrpessione JPEG attenzione che questo viene rieseguito ad ogni salvataggio, con possibile introduzione di artefatti.---------------------------------------------------
41.95581N 12.52854E http://www.linkedin.com/in/stefanoiacovella http://twitter.com/#!/Iacovellas Il giorno 21 ottobre 2013 07:26, Novarese <[hidden email]> ha scritto: Andrea Peri wrote/ _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 666 iscritti al 22.7.2013 |
On Mon, 21 Oct 2013 09:53:11 +0200, Stefano Iacovella wrote:
> Una nota da pignolo, forse inutile ma gradirei conferma/smentita da > qualcuno più esperto: > Se il tiff usa il metodo di comrpessione JPEG attenzione che questo > viene rieseguito ad ogni salvataggio, con possibile introduzione di > artefatti. > a rigor di termini gli artefatti vengono sempre introdotti quando si usa una qualsiasi compressione distruttiva (=lossy) come JPEG oppure ECW, MrSID, JPEG 2000 etc e' un fatto assolutamente inevitabile che deriva direttamente dalla matematica degli algoritmi usati per la compressione: l'immagine decompressa e' sempre inevitabilmente diversa dall'immagine di partenza. quello che cambia e che si puo' tenere efficacemente sotto controllo e' il numero e la densita' relativa degli artefatti che si ritiene saggio ed opportuno accettare; il parametro QUALITY supportato da tutte quante le compressioni di tipo Lossy serve proprio a questo. in soldoni: - file grande, poco compresso = pochi piccoli artefatti che l'imperfettissimo occhio umano ben difficilmente riuscira' a percepire - oppure file piccolo, molto compresso = persino una talpa notera' alla prima occhiata distratta che fa decisamente schifo. comunque quel che dice Stefano e' sostanzialmente corretto; comprimere a cascata piu' e piu' volte la medesima immagine tramite un qualsiasi algoritmo Lossy porta all'accumulo di artefatti che possono abbassare notevolmente la qualita' finale del risultato. esattamente come accade quando si fotocopia la copia della copia della copia dell'originale ... si finisce semplicemente con l'accumulare un sacco di ENTROPIA abbassando catastroficamente la qualita' visuale. > gdal_translate -of GTiff -co PROFILE=BASELINE -co COMPRESS=LZW -co > TFW=YES input.tiff output.tiff > considero assolutamente saggio il consiglio di usare sempre una compressione non distruttiva (=lossless) per i data grids. tra l'altro Jpeg e' fatto apposta per le foto vere e proprie (soggetti naturali), e si adatta decisamente male ad "immagini artificiali" come sono i data grids. personalmente, trovo invece del tutto errato insistere ad usare ancora oggi nel 2013 l'orrendo algoritmo LZW; questo algoritmo di compressione e' incredibilmente vecchio ed abbastanza rozzo, e risale addirittura ai primissimi anni '80. tra l'altro e' notoriamente affetto da un difettuccio abbastanza imbarazzante: in alcuni casi il file compresso potrebbe addirittura occupare molto piu' spazio del file originale (e capita assai spesso proprio con i data grids, provare per credere) :-) Esiste certamente un'alternativa assai migliore: Tiff supporta da tantissimi anni la compressione DEFLATE, che e' esattamente lo stesso algoritmo usato da ZIP. questo algoritmo e' decisamente piu' giovane (1990 circa), ed e' stato appositamente concepito fin dalla nascita come un'evoluzione migliorativa e decisamente ottimizzata di LZW IMHO e' sempre largamente preferibile usare DEFLATE piuttosto che LZW ma le piu' recenti versioni di libtiff supportano anche la compressione LZMA (esattamente quella di 7Zip); qua finalmente arriviamo a tecnologie up-to-date (anni 2000), con efficienza decisamente molto piu' elevata. forse pero' e' anche bene valutare accuratamente che ad oggi un Tiff compresso LZMA potrebbe causare qualche problema di compatibilita', visto che tutte le versioni obsolete della libreria non sarebbero in grado di aprirlo. stranamente, il mondo del GIS pare sempre molto affezionato e ben restio ad abbandonare tutte le tecnologie informatiche che puzzano di muffa ... sinceramente, non sono mai riuscito a capire perche' :-D ciao Sandro _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 666 iscritti al 22.7.2013 |
Il giorno 21 ottobre 2013 10:41, <[hidden email]> ha scritto:
Ciao Sandro, grazie per le conferme ed i chiarimenti. Effettivamente LZMA sembra non essere supportato da GDAL, o almeno non è citato nella documentazione, mentre DEFLATE indubbiamente lo è. http://www.gdal.org/frmt_gtiff.html " COMPRESS=[JPEG/LZW/PACKBITS/DEFLATE/CCITTRLE/CCITTFAX3/CCITTFAX4/NONE]: "
Stefano ---------------------------------------------------
41.95581N 12.52854E http://www.linkedin.com/in/stefanoiacovella http://twitter.com/#!/Iacovellas _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 666 iscritti al 22.7.2013 |
In reply to this post by a.furieri
Sara', ma per le immagini a 8 bit (ad es. grayscale) e' ancora il mio preferito, sia per la dimensione finale del TIFF, che per la sua portabilita' in altri software. Non conosco la compressione Deflate, ma a quanto ne dite... promette bene. La testo e riferisco su eventuali sue incompatibilita' con Gis opensource diversi da Qgis. |
Free forum by Nabble | Edit this page |