Facilitare l'uscita da ECW
Locked
 
|
>Provare a contattare gli sviluppatori dei sistemi operativi liberi (es.
>Ubuntu o Debian) se fossero interessati a realizzare nuovi formati del >tutto >open o potenziare veramente quelli già esistenti per i raster?? In >questo >modo sarebbe possibile avere un nuovo formato del tutto open da >contrapporre >all'ECW , al passo con i tempi!!! Magari coinvolgendo anche delle >Pubbliche >amministrazioni che abbiano volontà di migrare dal software >proprietario al >libero (con ovvia pubblicità positiva per tutti e risparmio di risorse? >Potrebbe essere fattibile secondo voi? >Saluti a tutti e grazie per le numerose idee... > >P.S. mi scuso con tutti se a volte sono utopico ma ancora sono >nell'età in >cui credo di poter cambiare le cose nel mondo!!! > >-- >*maurizio marchi* Mi pare una strada perdente. Intanto gli sviluppatori di software Libero non capiscono una acca di GIS. Non si tratta solo di sviluppare un nuovo formato , perche' come gia' viene detto qui, dei formait liberi esistono gia' e si chiamano TIFF e JPEG. Questo ti direbbero. Peor' loro non sapendoniente di GIS e di problematiche di accesso in rete, e di problematiche di cambio di sistemi di riferimento, e di problematiche d stampe in grandi formati , etc.... Non riuscirebbero a cogliere i dettagli di tutta la questione. Insomma sarebbe come ripartire da zero, ovvero da 20 anni fa' .... E quindi tra 20 anni ci sarebbe un formato libero adeguato alle necessita' dei GIS. Peor' per restare nel positivismo, un possibile candidato a far dimenticare il formato ECW. In realta' esiste. Si chiama RasterLite2. Sulla carta è connotato da tutti gli elementi tecnici che hanno concorso a rendere il formato ECW concorrenziale rispetto al TIFF e quindi e' un suo, teoricamente, possibile avversario. Dico teoricamente perche' e' ancora agli albori e la strada e' lunga... E anche qui la storia dell' ECW insegna. Quando ErMapper tirò fuori dal cilindro l'ecw, da solo le caratteristiche tecniche dell' ECW per quanto buone potevano essere non potevano bastare. E allora ecco la seconda gamba della strategia di ErMapper: essa mise gratuitamente a disposizione di chiunque i drivers per QUALSIASI SOFTWARE DI GRAFICA conosciuto. Ovvero fin da subito te potevi scaricarti il driver per caricare gli ECW dentro Office-Word, dentro Autocad, Dentro ArcView, dentro Intergraph, dentro Photoshop, dentro CorelDraw, etc.... Ecco da dove e' realmente arrivaot il successo di ermapper. Dal fatto che fin da subito ti garantiva che esso poteva essere compatibile con qualsiasi software che si interessava di grafica e di GIS a giro... Il formato RasterLite2, se anche da domani fosse reso funzionante e completato, sconterebbe una scarsa diffusione. E prima che esso possa raggiungere una diffusione su tanti softwares da renderlo un formato ammissibile, ce ne vorrà di tempo. Su questo discorso, naturalmente vi e' la variabile GDAL. Infatti diversi software fanno uso di gdal . Penso a QGIS e a MapServer e, sebbene con una atavica lentezza, anche GeoServer. Forse anche MapWindows fa uso di gdal (non lo so'). Per cui se si implementasse un buon driver per gdal di tipo read/write forse sarebbe ipotizzabile che esso potesse istantaneamente avere una platea di utilizzatori abbastanza vasta. Tra l'altro gdal e' usato anche da alcuni famisi software commerciali come fme , per cui la platea si allargherebbe. Pero' resterebbero fuori da questa filiera tutti i colleghi che usano gvSig, uDig, etc... per cui comunque non e' la soluzione perfetta... In effetti il formato RasterLite2 ha anche qualche altro problemino, ma poiche' non riguarda le prestazioni tecniche, esula dal discorso di questo thread. Andrea. _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 518 iscritti al 3.6.2011 |
|
|
>
> Per cui se si implementasse un buon driver per gdal di tipo read/write forse > sarebbe ipotizzabile che esso potesse istantaneamente avere una platea di > utilizzatori abbastanza vasta. > Ciao Andrea non ho mai usato Rasterlite, ma pensavo (probabilmente erroneamente) che GDAL già permettesse la lettura/scrittura con l'apposito driver [0]. Forse si tratta della vecchia versione di Rasterlite? O e' semplicemente un driver che consente la scrittura di raster su un db SQLite e non un formato raster vero e proprio? Magari Sandro può darci lumi al riguardo ciao P [0] http://www.gdal.org/frmt_rasterlite.html -- Paolo Corti Geospatial software developer web: http://www.paolocorti.net twitter: @capooti _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 518 iscritti al 3.6.2011 |
|
|
Il 12/06/2011 22:28, Paolo Corti ha scritto:
>> >> Per cui se si implementasse un buon driver per gdal di tipo read/write forse >> sarebbe ipotizzabile che esso potesse istantaneamente avere una platea di >> utilizzatori abbastanza vasta. >> > > Ciao Andrea > > non ho mai usato Rasterlite, ma pensavo (probabilmente erroneamente) > che GDAL già permettesse la lettura/scrittura con l'apposito driver > [0]. > Forse si tratta della vecchia versione di Rasterlite? O e' > semplicemente un driver che consente la scrittura di raster su un db > SQLite e non un formato raster vero e proprio? > Magari Sandro può darci lumi al riguardo > > ciao > P > > [0] http://www.gdal.org/frmt_rasterlite.html > Credo si tratti proprio del vecchio formato rasterlite. _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 518 iscritti al 3.6.2011 |
|
|
Giusto una piccola correzione: gvSIG usa le GDAL (oltre a leggere ecw e mrsid con driver a sé stanti)
giovanni Il giorno 12 giugno 2011 22:31, aperi2007 <[hidden email]> ha scritto: Il 12/06/2011 22:28, Paolo Corti ha scritto: _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 518 iscritti al 3.6.2011 |
Re: Facilitare l'uscita da ECW
|
|
> (oltre a leggere ecw e mrsid con driver a sé stanti)
quali? -- G -- _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 518 iscritti al 3.6.2011 |
|
|
Il 12/06/2011 23:14, Giovanni Manghi ha scritto:
>> (oltre a leggere ecw e mrsid con driver a sé stanti) > > quali? a me pare che li legga con i plugin di gdal; l'unica differenza e' che incorpora sw proprietario nel pacchetto (che a quel punto ha probabilmente una licenza molto incerta). Saluti. -- Paolo Cavallini: http://www.faunalia.it/pc _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 518 iscritti al 3.6.2011 |
|
|
Per ecw e marsid usa i binding per Java originali, rispettivamente da ERmapper [1] e da Lizardtech [2].
giovanni [1] http://forge.osor.eu/plugins/scmsvn/viewcvs.php/trunk/libraries/libjni-ecw/?root=gvsig-desktop [2] http://forge.osor.eu/plugins/scmsvn/viewcvs.php/trunk/libraries/libjni-mrsid/?root=gvsig-desktop Il giorno 13 giugno 2011 09:12, Paolo Cavallini <[hidden email]> ha scritto: Il 12/06/2011 23:14, Giovanni Manghi ha scritto: _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 518 iscritti al 3.6.2011 |
|
|
thread molto interessante.
quasi tutto quello che c'era da dire è già stato detto, per cui mi limito semplicemente a focalizzare un paio di punti a mio avviso meritevoli: a) resto personalmente assai dubbioso sulla legittimità del supporto diretto offerto da svSIG e/o IrfanView. a quanto mi risulta, l'unico modo per leggere/scrivere ECW (ma vale anche per mrSID) è quello di usare le librerie proprietarie di supporto (SDK). ed entrambi i produttori *vietano* esplicitamente la redistribuzione a terzi delle librerie/SDK sotto qualsiasi forma. quindi sicuramente qualcosa non torna. non solo: il formato stesso e l'algoritmo di compressione sono coperti da svariati brevetti. quindi, anche se qualche ipotetico genio-hacker si mettesse in testa di sviluppare da zero un codec alternativo, comunque commetterebbe un illecito, visto che violerebbe i brevetti. b) qua in italia sembra che esista solo ECW: ma posso assicurarvi che se andate a cercare sui siti di download dei vari stati e contee USA troverete MrSID in gran copia, ma neppure un singolo ECW. evidentemente, è ben difficile parlare di "oggettiva superiorità tecnologica" in casi come questi. a mio avviso, è la migliore dimostrazione di come in effetti siano le strategie di marketing quelle che determinano la diffusione di un determinato prodotto. BTW è interessante notare come nel caso specifico ECW/MrSID la situazione locale di "quasi-monopolio" si instaura solo nel momento in cui la Pubblica Amministrazione adotta un determinato formato proprietario, costringendo poi di fatto gli utenti ad allinearsi passivamente. e questo, decisamente, non è tollerabile :-( c) mi ha comunque stupito il fatto che (pur tra le molte mail) nessuno abbia messo in evidenza come in effetti stiamo parlando di tecnologie ormai largamente obsolete ed in via di superamento persino da parte degli stessi produttori. mi spiego meglio: sia ECW che MrSID sono tecnicamente due implementazioni basate su codec Wavelet: ma ormai anche per le Wavelet esiste uno standard internazionale di riferimento, e precisamente JPEG2000. Basta dare un'occhiata veloce al sito ERDAS per capire al volo che loro per primi stanno puntando tutte le proprie carte su JPEG2K per il futuro, e che sostanzialmente considerano ECW una semplice eredità del passato ormai superata e senza ulteriori prospettive di sviluppo. incidentalmente, anche JPEG2000 è afflitto da un oceano di brevetti e di implementazioni proprietarie (p.es. Kakadu). il fatto stesso che dopo 10 anni ancora non riesca a trovare un proprio preciso spazio la dice lunga. ma almeno in teoria J2K fa riferimento ad uno standard internazionale; rimaniamo pur sempre in ambito proprietario, ma quanto meno si può scegliere tra fornitori differenti. ed esiste pure qualche implementazione open/free, per quanto orribilmente lenta ed inefficiente. tutto questo mette automaticamente fuori gioco tutte le vecchie implementazioni "chiuse", ed evidentemte ERDAS ha focalizzato assai bene il nuovo scenario, quando ha deciso di riscrivere totalmente ex-novo il proprio SDK in modo tale da supportare non solo ECW ma anche J2K ciao Sandro _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 518 iscritti al 3.6.2011 |
|
|
Anch'io non credo che la distribuzione delle librerie ECW da parte di gvSIG sia lecita. Con molta leggerezza hanno semplicemente piazzato l'SDK nel folder binaries [1], sia per Linux che per Windows. Per Mac c'è solo MrSid.
J2K non l'ho mai testato, proprio per il fatto che non esiste un'implementazione free/os realmente usabile in ambito di produzione (almeno se vuoi prestazioni decenti!). Nel frattempo? Sostieni anche tu, Sandro, che Tiff tilizzato con overview può portare a risultati, in termini di performance, comparabili ad ecw? Sto parlando sia in locale che in ambito server. Giovanni [1] http://forge.osor.eu/plugins/scmsvn/viewcvs.php/trunk/binaries/?root=gvsig-desktop
Il giorno 13 giugno 2011 10:43, <[hidden email]> ha scritto: thread molto interessante. _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 518 iscritti al 3.6.2011 |
|
|
On Mon, 13 Jun 2011 11:23:55 +0200, G. Allegri wrote
> Nel frattempo? Sostieni anche tu, Sandro, che Tiff tilizzato con overview può > portare a risultati, in termini di performance, comparabili ad ecw? > Sto parlando sia in locale che in ambito server. > mi sono ben guardato dal fare qualsiasi benchmark comparativo su ECW e/o MrSID (anche perchè le rispettive licenze d'uso lo proibiscono tassativamente !!!) comunque, ragionando a spanne, tutti gli algoritmi basati sulle Wavelet sono estramamente pesanti (e quindi assai lenti). il buon vecchio onesto JPEG (specie in alcune implementazioni come libjpeg-turbo) ha dei margini competitivi in termini prestazionali assolutamente irraggiungibili. quindi (sempre a spanne) un buon GeoTIFF debitamente strutturato per TILES e supportato da piramidi non lascia probabilmente nulla da rimpiangere in termini prestazionali. e se si ha l'accortezza di comprimere le TILES come JPEG anche la differenza in termini di allocazione disco diventa meno catastrofica. come giustamente sostiene Andrea Peri, il vero limite d'uso dei GeoTIFF è quando risiedono su un server centrale e molte workstation cercano di leggerli direttamente tramite LAN. in quel caso l'approccio "stream-oriented" di ECW è sicuramente imbattibile. ma molto probabilmente (come sostiene Giovanni Manghi) mettere nel mezzo un server WMS che provveda a "spezzettare" le singole tiles, magari con l'accortezza di veicolarle in rete in forma compressa (p.es. jpeg) riesce a ripristinare la parità. (almeno ... in teoria ... in pratica non ho mai provato ...) ciao Sandro _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 518 iscritti al 3.6.2011 |
|
|
Grazie Sandro ;)
Il giorno 13 giugno 2011 12:40, <[hidden email]> ha scritto:
_______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 518 iscritti al 3.6.2011 |
Re: Facilitare l'uscita da ECW
|
|
In reply to this post by a.furieri
> comunque, ragionando a spanne, tutti gli algoritmi basati sulle Wavelet
> sono estramamente pesanti (e quindi assai lenti). > il buon vecchio onesto JPEG (specie in alcune implementazioni come > libjpeg-turbo) ha dei margini competitivi in termini prestazionali > assolutamente irraggiungibili. Non ho fatto neach'io benchmark seri, riporto comunque la mia esperienza "a spanne". Partendo da un file ECW di 25982 KB con i comandi: gdal_translate -co "TILED=YES" -co "INTERLEAVE=PIXEL" -co "COMPRESS=JPEG" -co "PHOTOMETRIC=YCBCR" -co "JPEG_QUALITY=70" -a_srs "EPSG:3004" $ecw $tif gdaladdo -r cubic --config COMPRESS_OVERVIEW JPEG --config PHOTOMETRIC_OVERVIEW YCBCR --config INTERLEAVE_OVERVIEW PIXEL -r cubic $tif 2 4 8 16 ottengo un file GeoTIFF di 33323 KB, praticamente indistinguibile dall'originale ECW (e credo avrei ottenuto risultati ancora migliori se avessi avuto a disposizione gli originali non compressi), che vuol dire un incremento in termini di spazio di circa il 28%. Nell'uso in ambito desktop non noto diffenze, non ho fatto misure ma sia sul portatile che sul fisso entrambe le versioni si aprono "istantaneamente" e zoom e pan funzionano in modo del tutto simile. In ambito server non ho posso confrontare in quanto ho usato solo i GeoTIFF, ma non ho mai notato né rallentamenti né sovraccarichi sul server. Nella mia piccola esperienza ritengo che il formato ECW abbia l'unico vantaggio di occupare meno spazio a parità di qualità dell'immagine. Ciao, Stefano _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 518 iscritti al 3.6.2011 |
Re: Facilitare l'uscita da ECW
|
|
On Mon, Jun 13, 2011 at 02:22:12PM +0200, Stefano Salvador wrote:
> > Partendo da un file ECW di 25982 KB con i comandi: > Stai barando, sei partito da una versione già intrinsecamete compressa dell'immagine originale. È come se avessi già applicato un filtro passa basso all'immagine originale e per conseguenza ridotto la dinamica. E' normale che decomprimendo il segnale ormai 'appiattito' possa essere gestito molto piu' comodamente con compressione DCT. -- Francesco P. Lovergine _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 518 iscritti al 3.6.2011 |
|
|
Mi domandavo appunto quanta differenza ci possa essere tra lavorare sull'immagine originale o sull'ecw decompresso.
Ho un vecchio compressore ECW... se trovo un pochino di tempo provo a fare un paio di prove. giovanni Il giorno 13 giugno 2011 20:05, Francesco Paolo Lovergine <[hidden email]> ha scritto:
_______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 518 iscritti al 3.6.2011 |
|
|
On Tue, 14 Jun 2011 10:07:57 +0200, G. Allegri wrote
> Mi domandavo appunto quanta differenza ci possa essere tra lavorare sull'immagine originale o sull'ecw decompresso. > Ho un vecchio compressore ECW... se trovo un pochino di tempo provo a fare un paio di prove. > >> Il giorno 13 giugno 2011 20:05, Francesco Paolo Lovergine <[hidden email]> ha scritto: >> >> Stai barando, sei partito da una versione già intrinsecamete compressa >> dell'immagine originale. È come se avessi già applicato un filtro >> passa basso all'immagine originale e per conseguenza ridotto la dinamica. >> E' normale che decomprimendo il segnale ormai 'appiattito' possa essere >> gestito molto piu' comodamente con compressione DCT. >> se vi calcolate l'istogramma di distribuzione dei singoli valori RGB per una qualsiasi immagine digitale "naturale", scoprirete che ci sono svariati milioni di colori distinti. se ripetete su un'immagine sottoposta a compressione lossy e successiva decompressione, i colori distinti saranno ridotti a poche centinaia di migliaia (o anche molti meno, dipende da quanto è stata aggressiva la compressione lossy). l'occhio umano è "credulone", ed in pratica non si accorge della differenza (o quasi): resta il fatto che nel corso del processo è andata irrimediabilmente distrutta un sacco di informazione. appunto, come dice correttamente frankie, ora l'immagine è irrimediabilmente "appiattita", e non è corretto considerarla equivalente a quella ben più "ricca" di partenza. la vera differenza tra JPEG e Wavelet (EWC/MrSID/J2k) è semplicemente nel "come" viene distrutta l'informazione: a fattori di compressione "normali" l'uno vale sostanzialmente l'altro, sia come qualità che come risparmio di spazio. JPEG ad alti fattori di compressione tende a produrre dei brutti "quadrettoni" assai visibili e che disturbano molto l'occhio. Wavelet invece produce una "sfocatura" morbida (tipo effetto acquerello) che inganna più facilmente l'occhio: ecco perchè generalmente si dice che "Wavelet comprime più di JPEG". Ma sia in un caso come nell'altro alla fine si ottiene pur sempre un'immagine severamente degradata: la differenza è esclusivamente estetica / illusionistica. non fidatevi dei vostri occhi imperfetti: calcolatevi piuttosto un istogramma di distribuzione dei colori prima di giudicare :-) ciao Sandro _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 518 iscritti al 3.6.2011 |
Re: Facilitare l'uscita da ECW
|
|
In reply to this post by Francesco P. Lovergine
> Stai barando, sei partito da una versione già intrinsecamete compressa
> dell'immagine originale. È come se avessi già applicato un filtro > passa basso all'immagine originale e per conseguenza ridotto la dinamica. > E' normale che decomprimendo il segnale ormai 'appiattito' possa essere > gestito molto piu' comodamente con compressione DCT. Hai ragione. Comunque sono riuscito a procurarmi l'immagine non compressa e a ripetere la conversione. I risultati sono analoghi in termini di dimensione del file e la qualità sembra migliore. Ovviamente il mio è solo un ragionamento a spanne e i test andrebbero fatti in maniera più controllata. Ma a quanto pare la licenza ECW proibisce di fare benchmark accurati (ma possono farlo davvero ? ). Ciao, Stefano _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 518 iscritti al 3.6.2011 |
«
Return to Gfoss -- Geographic Free and Open Source Software - Italian mailing list
|
1 view|%1 views
| Free forum by Nabble | Edit this page |