Facilitare l'uscita da ECW

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Facilitare l'uscita da ECW

Andrea Peri
 >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
Reply | Threaded
Open this post in threaded view
|

Re: Facilitare l'uscita da ECW

Paolo Corti
>
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Facilitare l'uscita da ECW

Andrea Peri
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
Reply | Threaded
Open this post in threaded view
|

Re: Facilitare l'uscita da ECW

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


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


_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: Facilitare l'uscita da ECW

Giovanni Manghi
>  (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
Reply | Threaded
Open this post in threaded view
|

Re: Facilitare l'uscita da ECW

pcav
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
Reply | Threaded
Open this post in threaded view
|

Re: Facilitare l'uscita da ECW

giohappy
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:
>>  (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


_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: Facilitare l'uscita da ECW

a.furieri
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
Reply | Threaded
Open this post in threaded view
|

Re: Facilitare l'uscita da ECW

giohappy
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.
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
Reply | Threaded
Open this post in threaded view
|

Re: Facilitare l'uscita da ECW

a.furieri
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
Reply | Threaded
Open this post in threaded view
|

Re: Facilitare l'uscita da ECW

giohappy
Grazie Sandro ;)

Il giorno 13 giugno 2011 12:40, <[hidden email]> 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


_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: Facilitare l'uscita da ECW

Stefano Salvador
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
Reply | Threaded
Open this post in threaded view
|

Re: Facilitare l'uscita da ECW

Francesco P. Lovergine
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
Reply | Threaded
Open this post in threaded view
|

Re: Facilitare l'uscita da ECW

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


_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: Facilitare l'uscita da ECW

a.furieri
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
Reply | Threaded
Open this post in threaded view
|

Re: Facilitare l'uscita da ECW

Stefano Salvador
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