[Gfoss] Facilitare l'uscita da ECW

>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.

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

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.

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 <aperi2007@gmail.com> ha scritto:

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
Gfoss@lists.gfoss.it
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

(oltre a leggere ecw e mrsid con driver a sé stanti)

quali?

-- G --

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

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 <cavallini@faunalia.it> ha scritto:

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
Gfoss@lists.gfoss.it
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 :frowning:

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

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, <a.furieri@lqt.it> ha scritto:

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 :frowning:

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

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

Grazie Sandro :wink:

Il giorno 13 giugno 2011 12:40, <a.furieri@lqt.it> ha scritto:

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

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

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

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 <frankie@debian.org> ha scritto:

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
Gfoss@lists.gfoss.it
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

<frankie@debian.org> 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 :slight_smile:

ciao Sandro

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