Discussion:
ecw con geoserver/gdal: Erdas ha rimosso ecw3.3 runtime lib
(too old to reply)
unknown
2010-07-19 10:04:31 UTC
Permalink
Ciao a tutti, per usare file in formato ecw con geoserver devo installare
GDAL Image Format plugin.
Per compilarlo, leggo da qui http://trac.osgeo.org/osgeo4w/wiki/pkg-gdal-ecw,
che servono ECW 3.3 Runtime libraries which the end user is required to
download and install directly from the Erdas Web Site directly.

Attualmente la Erdas ha rimosso le 3.3 perche' entro luglio 2010 rilascera'
la 4.1.

Sapete dirmi dove posso trovare le 3.3?
Per caso qualcuno le ha e puo' passarmele?

grazie in anticipo

alberto
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.faunalia.it/pipermail/gfoss/attachments/20100719/94c21106/attachment.htm>
unknown
2010-07-19 10:08:08 UTC
Permalink
Post by unknown
Attualmente la Erdas ha rimosso le 3.3 perche' entro luglio 2010
rilascera' la 4.1.
Forse. E comunque bisogna vedere con quale licenza le rilascera'.
Post by unknown
Sapete dirmi dove posso trovare le 3.3?
Per caso qualcuno le ha e puo' passarmele?
Tecnicamente puo', legalmente no: viola infatti i termini della licenza.
So che siamo nojosi, ma ecw NON e' libero, e non si puo' fare quel che si vuole.
Saluti.
--
Paolo Cavallini: http://www.faunalia.it/pc
unknown
2010-07-19 12:27:48 UTC
Permalink
grazie mille per la risposta.
capisco che ecw esuli dal panorama del software libero, purtroppo mi trovo a
dover lavorare con 11Gb di ecw.. non per scelta mia..
vorrei cercare di utilizzare prodotti open per evitare di spendere altri
soldi in licenze (esri e co)
in realta' non devo creare un server in produzione, l'utilizzo che devo
farne e' solo personale e l'idea di usare geoserver e openlayers e' solo per
facilitare la gestione di questa moltitudine di file e megabyte.

altrimenti c'e' qualche altro formato aperto di pari prestazioni in cui
posso convertirle?

ho provato a convertirle in geotiff ma un file da 8mb diventa circa 300mb..
non ho ancora fatto la proporzione sul totale ma sicuramente non ce la
faccio ad alloggiarli..
e poi non riesco a caricarle in geoserver dopo la conversione con Erdas ER
Viewer; l'errore e':

*Could not list layers for this store, an error occurred retrieving them:
Unable to acquire a reader for this coverage with format: GeoTIFF*

grazie e scusate se vado un po' OT con le ecw

alberto



2010/7/19 Paolo Cavallini <cavallini a faunalia.it>
Post by unknown
Post by unknown
Attualmente la Erdas ha rimosso le 3.3 perche' entro luglio 2010
rilascera' la 4.1.
Forse. E comunque bisogna vedere con quale licenza le rilascera'.
Post by unknown
Sapete dirmi dove posso trovare le 3.3?
Per caso qualcuno le ha e puo' passarmele?
Tecnicamente puo', legalmente no: viola infatti i termini della licenza.
So che siamo nojosi, ma ecw NON e' libero, e non si puo' fare quel che si vuole.
Saluti.
--
Paolo Cavallini: http://www.faunalia.it/pc
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss a faunalia.it
http://lists.faunalia.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
460 iscritti al 15.7.2010
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.faunalia.it/pipermail/gfoss/attachments/20100719/b6ef4d03/attachment.htm>
unknown
2010-07-19 13:14:45 UTC
Permalink
Post by unknown
grazie mille per la risposta.
capisco che ecw esuli dal panorama del software libero, purtroppo mi
trovo a dover lavorare con 11Gb di ecw.. non per scelta mia..
A proposito, le recenti note di Frank Warmerdam[0] sono preoccupanti per chi usa ECW:
===
In my personal opinion Erdas now desires a level of control over how the
ECW libraries are used that is largely incompatible with the distribution
of free software. In the past we forced the user to get the DLLs directly
from Erdas so they could accept the Erdas licensing terms themselves. But
now some sort of interactive vetting process is required for each individual
wanting the DLLs that is really aimed at commercial software developers.
===
quindi e' possibile che in futuro gli ECW non siano semplicemente usabili a meno di
comprare una licenza.
Saluti.
--
Paolo Cavallini: http://www.faunalia.it/pc

[0] http://lists.osgeo.org/pipermail/osgeo4w-dev/2010-July/000994.html
unknown
2010-07-19 13:59:25 UTC
Permalink
Salve Alberto,
attualmente le librerie per l'ECW 3.3 non sono più disponibili in pubblico.
Non credo esistano altri formati che diano prestazioni simili o comunque
senza dover spendere altri soldi in licenze.
Per quanto riguarda l'errore di conversione in TIFF, probabilmente ERViewer
non ha salvato opportunamente il CRS e quindi GeoServer non è in grado di
parsarlo correttamente (prova a fare un gdalinfo sulla tiff convertita).
Potresti guadagnare qualcosa in spazio, attivando la compressione e, per
ottenere maggiori prestazioni, costruire piramidi o creare le overviews. Se
ha bisogno di chiarimenti sull'argomento, chieda pure.

Saluti,
Daniele

2010/7/19 Alberto Valente <alb.valente a gmail.com>
Post by unknown
grazie mille per la risposta.
capisco che ecw esuli dal panorama del software libero, purtroppo mi trovo
a dover lavorare con 11Gb di ecw.. non per scelta mia..
vorrei cercare di utilizzare prodotti open per evitare di spendere altri
soldi in licenze (esri e co)
in realta' non devo creare un server in produzione, l'utilizzo che devo
farne e' solo personale e l'idea di usare geoserver e openlayers e' solo per
facilitare la gestione di questa moltitudine di file e megabyte.
altrimenti c'e' qualche altro formato aperto di pari prestazioni in cui
posso convertirle?
ho provato a convertirle in geotiff ma un file da 8mb diventa circa 300mb..
non ho ancora fatto la proporzione sul totale ma sicuramente non ce la
faccio ad alloggiarli..
e poi non riesco a caricarle in geoserver dopo la conversione con Erdas ER
Unable to acquire a reader for this coverage with format: GeoTIFF*
grazie e scusate se vado un po' OT con le ecw
alberto
2010/7/19 Paolo Cavallini <cavallini a faunalia.it>
Post by unknown
Post by unknown
Attualmente la Erdas ha rimosso le 3.3 perche' entro luglio 2010
rilascera' la 4.1.
Forse. E comunque bisogna vedere con quale licenza le rilascera'.
Post by unknown
Sapete dirmi dove posso trovare le 3.3?
Per caso qualcuno le ha e puo' passarmele?
Tecnicamente puo', legalmente no: viola infatti i termini della licenza.
So che siamo nojosi, ma ecw NON e' libero, e non si puo' fare quel che si vuole.
Saluti.
--
Paolo Cavallini: http://www.faunalia.it/pc
_______________________________________________
http://www.gfoss.it/drupal/iscrizione
Gfoss a faunalia.it
http://lists.faunalia.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
460 iscritti al 15.7.2010
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss a faunalia.it
http://lists.faunalia.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
460 iscritti al 15.7.2010
--
-------------------------------------------------------
Eng. Daniele Romagnoli
Software Engineer

GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584983027
fax: +39 0584983027
mob: +39 328 0559267


http://www.geo-solutions.it

-------------------------------------------------------
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.faunalia.it/pipermail/gfoss/attachments/20100719/fc440f72/attachment.htm>
unknown
2010-07-20 07:43:08 UTC
Permalink
Post by unknown
altrimenti c'e' qualche altro formato aperto di pari prestazioni in cui
posso convertirle?
Noi abbiamo immagini in formato ecw,
e posso dirti che per internet non e' un gran che'.
Noi infatti non lo usiamo per internet.
Tralascio i problemi tecnici che ha perche' il discorso porterebbe lontano...

Aggiungo che il formato tiff+jpeg e' una coppia sciagurata per internet.
Infatti la decompressione jpeg porta via risorse e avere i tiff
compressi in jpeg abbassa tantissimo le prestazioni
della macchina.
Non parlo tanto quando hai n utente solo (te stesso) ma piuttosto
quando comincia ad avere piu' utenti in contemporanea.

Dal punto di vista prestazionale al formato tiff+jpeg e' preferibile
il tiff uncompressed, sebbene capisco che eroda
notevolmente lo spazio disco.
D'altra parte la coperta e' quella, se tiri da una parte ...

Poi se si cambia formato, e si esclude i canonici ecw e jpeg2000
(ognuno con i propri problemi)
io ti potrei suggerire di dare una occhiata al formato RasterLite.

A onor del vero non lo ho ancora provato e quindi non posso darti
delle certezze.
Ma lo ritengo interessante.

O meglio:
se il tuo obiettivo e' supportare la consultazione via web tramite un
formato agile e veloce.
Ritengo che Rasterlite potrebbe avere una chance.
Se invece l'obiettivo e' condividere in rete locale,
occorrerebbe metterlo alla prova.

Ovviamente ti consiglio di provare il formato rasterlite,
perche' immagino che geoserver come accedere agli ecw tramite gdal/ogr
puo' accedere al formato rasterlite sempre tramite gdal/ogr.
Se questo non e' vero, allora come non detto . :)
--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.faunalia.it/pipermail/gfoss/attachments/20100720/8fa41f77/attachment.htm>
unknown
2010-07-20 08:23:02 UTC
Permalink
Post by unknown
Post by unknown
altrimenti c'e' qualche altro formato aperto di pari prestazioni in cui
posso convertirle?
Noi abbiamo immagini in formato ecw,
e posso dirti che per internet non e' un gran che'.
Sicuramente non è un formato libero, e purtroppo ERDAS non ha ancora
rilasciato la nuova versione, ma che su Internet non sia un granchè
avrei i miei forti dubbi.

Qui <http://blog.webmapper.com.au/image-server-benchmark/>c'è un bel
benchmark che incrocia tecnologie server e formati.
Chiaramente ogni formato avrà i propri pregi e i propri difetti e tutto
è sempre opinabile.

Personalmente, l'ultima cosa che farei (solo se i clienti mi
obbligassero insomma) è memorizzare informazioni ad accesso
tendenzialmente sequenziale come i raster (anche un tile 256x256 = 64 K,
cioè un bel output per una query) in un RDBMS, nonostante una piccola
casa che produce Database (mi sa che si chiami Oracle) continui a
spingere su questa cosa.

Ciao
Cristoforo
Post by unknown
Noi infatti non lo usiamo per internet.
Tralascio i problemi tecnici che ha perche' il discorso porterebbe lontano...
Aggiungo che il formato tiff+jpeg e' una coppia sciagurata per internet.
Infatti la decompressione jpeg porta via risorse e avere i tiff compressi in jpeg abbassa tantissimo le prestazioni
della macchina.
Non parlo tanto quando hai n utente solo (te stesso) ma piuttosto quando comincia ad avere piu' utenti in contemporanea.
Dal punto di vista prestazionale al formato tiff+jpeg e' preferibile il tiff uncompressed, sebbene capisco che eroda
notevolmente lo spazio disco.
D'altra parte la coperta e' quella, se tiri da una parte ...
Poi se si cambia formato, e si esclude i canonici ecw e jpeg2000 (ognuno con i propri problemi)
io ti potrei suggerire di dare una occhiata al formato RasterLite.
A onor del vero non lo ho ancora provato e quindi non posso darti delle certezze.
Ma lo ritengo interessante.
se il tuo obiettivo e' supportare la consultazione via web tramite un formato agile e veloce.
Ritengo che Rasterlite potrebbe avere una chance.
Se invece l'obiettivo e' condividere in rete locale,
occorrerebbe metterlo alla prova.
Ovviamente ti consiglio di provare il formato rasterlite,
perche' immagino che geoserver come accedere agli ecw tramite gdal/ogr puo' accedere al formato rasterlite sempre tramite gdal/ogr.
Se questo non e' vero, allora come non detto . :)
--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss a faunalia.it
http://lists.faunalia.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
460 iscritti al 15.7.2010
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.faunalia.it/pipermail/gfoss/attachments/20100720/ab620fe2/attachment.htm>
unknown
2010-07-20 09:03:46 UTC
Permalink
Post by unknown
Qui <http://blog.webmapper.com.au/image-server-benchmark/>c'è un bel
benchmark che incrocia tecnologie server e formati.
Chiaramente ogni formato avrà i propri pregi e i propri difetti e tutto
è sempre opinabile.
Interessante, grazie per il link. Certo, strano che con questi risultati abbastanza
eclatanti ERDAS non abbia partecipato alla competizione FOSS4G
http://wiki.osgeo.org/wiki/Benchmarking_2009
Post by unknown
Personalmente, l'ultima cosa che farei (solo se i clienti mi
obbligassero insomma) è memorizzare informazioni ad accesso
tendenzialmente sequenziale come i raster (anche un tile 256x256 = 64 K,
cioè un bel output per una query) in un RDBMS, nonostante una piccola
casa che produce Database (mi sa che si chiami Oracle) continui a
spingere su questa cosa.
E su questo siamo piu' che d'accordo.
Salutoni.
--
Paolo Cavallini: http://www.faunalia.it/pc
unknown
2010-07-20 09:33:22 UTC
Permalink
Post by unknown
Qui<http://blog.webmapper.com.au/image-server-benchmark/>c'è un bel
benchmark che incrocia tecnologie server e formati.
Chiaramente ogni formato avrà i propri pregi e i propri difetti e tutto
è sempre opinabile.
Interessante, grazie per il link. Certo, strano che con questi risultati abbastanza
eclatanti ERDAS non abbia partecipato alla competizione FOSS4G
http://wiki.osgeo.org/wiki/Benchmarking_2009
paura? O:-)
Io avrei partecipato. Mi sembrava veramente una sana competizione, uno
stimolo al migliorarsi di anno in anno.
Poi, ripeto, tutto è opinabile, nel senso che la Total Cost of Ownership
e la Total System Performance per know how, software, memoria, rete,
hard disk, CPU, ecc. sono sempre molto interconnesse e, come diceva
Andrea, tiri da una parte e si scopre l'altra.

Ciao
Cristoforo

PS_OT: Non mi sbranate, ma vi inviterei a leggere questo post sul nostro
BLOG: I dati geospaziali creano dipendenza!
<http://blog.planetek.it/2010/07/15/dati-geospaziali-e-dipendenza/>
E' una cosa curiosa che è accaduta e un commento dei validi GFOSSARI
sarebbe sicuramente spunto per ulteriori considerazioni.
Post by unknown
Personalmente, l'ultima cosa che farei (solo se i clienti mi
obbligassero insomma) è memorizzare informazioni ad accesso
tendenzialmente sequenziale come i raster (anche un tile 256x256 = 64 K,
cioè un bel output per una query) in un RDBMS, nonostante una piccola
casa che produce Database (mi sa che si chiami Oracle) continui a
spingere su questa cosa.
E su questo siamo piu' che d'accordo.
Salutoni.
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.faunalia.it/pipermail/gfoss/attachments/20100720/347f7f7e/attachment.htm>
unknown
2010-07-20 09:02:41 UTC
Permalink
Ciao,

riguardo rasterlite, non ho provato con mapserver (o altre applicazioni di web mapping),
ma in applicazioni di tipo desktop (grass, qgis, ossim) mi ha dato ottimi risultati.

Le dimensioni di Una TrueMarbley (risoluzione 250), che in GTiff arriva a 8 GB, in Rasterlite si riducono a 2.5 GB.
Operazioni semplici tipo pan/zoom in Qgis sono risultate rapide garantendo una gradevole esplorazione del file
(cosa pressochè impossibile in Qgis, usando i file originali in formato GTiff).

Rasterlite è risultata per me una scelta più che valida nel momento in cui si ha la necessità di visualizzare file raster di grosse dimensioni.


Massimo.
Post by unknown
Post by unknown
altrimenti c'e' qualche altro formato aperto di pari prestazioni in cui
posso convertirle?
Noi abbiamo immagini in formato ecw,
e posso dirti che per internet non e' un gran che'.
Noi infatti non lo usiamo per internet.
Tralascio i problemi tecnici che ha perche' il discorso porterebbe lontano...
Aggiungo che il formato tiff+jpeg e' una coppia sciagurata per internet.
Infatti la decompressione jpeg porta via risorse e avere i tiff compressi in jpeg abbassa tantissimo le prestazioni
della macchina.
Non parlo tanto quando hai n utente solo (te stesso) ma piuttosto quando comincia ad avere piu' utenti in contemporanea.
Dal punto di vista prestazionale al formato tiff+jpeg e' preferibile il tiff uncompressed, sebbene capisco che eroda
notevolmente lo spazio disco.
D'altra parte la coperta e' quella, se tiri da una parte ...
Poi se si cambia formato, e si esclude i canonici ecw e jpeg2000 (ognuno con i propri problemi)
io ti potrei suggerire di dare una occhiata al formato RasterLite.
A onor del vero non lo ho ancora provato e quindi non posso darti delle certezze.
Ma lo ritengo interessante.
se il tuo obiettivo e' supportare la consultazione via web tramite un formato agile e veloce.
Ritengo che Rasterlite potrebbe avere una chance.
Se invece l'obiettivo e' condividere in rete locale,
occorrerebbe metterlo alla prova.
Ovviamente ti consiglio di provare il formato rasterlite,
perche' immagino che geoserver come accedere agli ecw tramite gdal/ogr puo' accedere al formato rasterlite sempre tramite gdal/ogr.
Se questo non e' vero, allora come non detto . :)
--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss a faunalia.it
http://lists.faunalia.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
460 iscritti al 15.7.2010
unknown
2010-07-20 09:38:03 UTC
Permalink
Aggiungo che il formato tiff+jpeg e' una coppia sciagurata per internet.> Infatti la decompressione jpeg porta via risorse e avere i tiff compressi in jpeg abbassa > tantissimo le prestazioni della macchina.> Non parlo tanto quando hai n utente solo (te stesso) ma piuttosto quando comincia ad avere piu' > utenti in contemporanea.> Dal punto di vista prestazionale al formato tiff+jpeg e' preferibile il tiff uncompressed, > sebbene capisco che eroda notevolmente lo spazio disco.> D'altra parte la coperta e' quella, se tiri da una parte ...>Punto di discussione molto interessante (e suggestivo).Sicuramente l'algoritmo di decodifica JPEG ha un costo computazionale: quindirichiamarlo in continuazione assorbe risorse, specie in termini di CPU.La cosa che però trovo abbastanza curiosa è che l'algoritmo di decompressione Wavelet (quello utilizzato dai vari MrSID, ECW, JPEG2000 etc) si basa sicuramentesu una matematica più complessa, e molto più pesante in termini computazionali.Qui
ndi come è possibile che p.es. ECW "gira svelto", mentre JPEG "gira lento" ?questa cosa mi convince assai poco, e mi puzza più di mitologia che di realtàoggettiva.A mio modesto parere (ed esperienza), il nocciolo del problema è che TIFFnon è un vero e proprio formato, ma piuttosto una variegata famiglia diformati, con caratteristiche anche molto differenti tra di loro.Ma anche JPEG è un algoritmo altamente flessibile e parametrizzabile,in grado di "strizzare" tanto o poco, con qualità ottima oppure indecente ...insomma, parlare di "TIFF/JPEG" senza qualificare meglio rischia diessere talmente generico da perdere qualsivoglia significato tecnico.a) sicuramente un TIFF "non compresso" offre i migliori tempi di risposta,   visto che i tempi di accesso comprendono esclusivamente l'I/Ob) ma anche in questo caso occorre distinguere, perchè:b1) un TIFF con struttura "strip" fatica sicuramente in lettura, specie    quando occorre prelevare semplicemente una piccola porzione dell'imm
agineb2) invece un TIFF con struttura "tile" gonfia leggermente come spazio, però    offre tempi di accesso di gran lunga migliori.     Identificare la dimensione ottimale della tile non è banale, e sicuramente    causa sensibili differenze di velocità: tipicamente i risultati migliori    si ottengono usando tiles 'piccole', p.es. 256x256 oppure 512x512c) se poi si applica la compressione JPEG, la questione si complica ancor di   più ... perchè oltre all'I/O occorre considerare il tempo di decodificac1) una struttura "strip" non è sicuramente in grado di offrire buona velocità,    perchè con elevata probabilità costringe a decomprimere anche porzioni di    immagine assolutamente inutili (= che non verranno utilizzate)c2) viceversa la struttura "tile" (almeno nella mia personale esperienza) può    offrire tempi di risposta molto fluidi, sempre che si abbia l'accortezza    di usare tiles ragionevolmente 'piccole'    Poi (ovviamente) occorre considerare la questione delle 'pira
midi', cioèdi come supportare efficacemente una struttura multi-risoluzione.E penso proprio che è qui che gli algoritmi Wavelet hanno un vantaggioconcreto, visto che questo algoritmo ha la capacità intrinseca dieffettuare la decompressione a varie risoluzioni, caratteristica cheinvece manca (parzialmente) all'algoritmo JPEG.Quindi usando TIFF (oppure TIFF/JPEG) occorre sicuramente generare una struttura "a piramide" per potere ottenere buoni tempi di accesso,ma questo implica consumare un buon 40% di spazio disco aggiuntivo ...conclusione: non sempre è facile confrontare "le mele con le mele,e le pere con le pere" ... specie quando, come in questo caso,i parametri da tenere sotto controllo sono svariati, e tuttipossono essere fortemente influenti. > Poi se si cambia formato, e si esclude i canonici ecw e jpeg2000 (ognuno con i propri problemi)> io ti potrei suggerire di dare una occhiata al formato RasterLite.>btw, anche RasterLite usa JPEG: quindi il problema dovrebbe ripro
posi esattamente invariato, no ?non ho mai fatto verifiche in condizioni di concorrenza/parallelismo spinto, maa lume di naso non sembrerebbe.Comunque un bel benchmark serio ed oggettivo potrebbe fare luce sulla questione:peccato solo che p.es. il MrSID SDK esclude esplicitamente nelle condizioni dilicenza la possibilità di fare benchmarking comparativo rendendo pubblici i dati :-(Infine, in quanto "babbo" di RasterLite consentitemi di spezzare unalancia a favore dei "raster dentro ai DBMS".Si, sicuramente l'I/O è più farragginoso: ma considerate anche che(almeno RasterLite) si trae tutto il vantaggio di avere uno SpatialIndex associato alle immagini.Cosa che invece manca completamente usando TIFF: può anche sembrarebanale, ma vi siete mai chiesti quanti cicli di CPU ci vogliono (per non parlare degli accessi a disco) solo per scandire la lista delle tilese potere quindi identificare quelle (poche) di effettivo interesse ?specie se nel frattempo occorre anche aprire e chiude
re un qualche centinaiodi files, ripetendo ogni volta il parsing della directory dei tags TIFF ?ciao Sandro

-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.faunalia.it/pipermail/gfoss/attachments/20100720/bc67139f/attachment-0001.htm>
unknown
2010-07-20 10:56:33 UTC
Permalink
Non e' solo un problema di tecnica di compressione, ma anche di formato.

Sebbene computazionalmente la wavelet richieda uno sforzo superiore per la
decodifica,
nel formato ecw il contenuto e' posto in maniera che non serve scaricare
tutto il file per poter effettuare la decompressione, e questo permette una
azione in contemporanea sul flusso che si sta scaricando.
Inoltre, ancora piu' importante, la tecnica implementatavi consente di
aumentare il dettaglio prelevando solamente l'informazione mancante.
Questo comporta che se per decodificare a un certo livello hai speso 10,
quando aumenti il dettaglio, l'azione combinata dell'area ridottasi e del
fatto che gia' avevi un certo livello informativo ti consente di completare
tale decodifica (al nuovo livello di dettaglio) con una spesa decisamente
inferiore, ad esempio 3.
Se sommi questo al fatto che non devi neanche attendere che sia stata letta
tutta l'immagin ecco che i tempi si assottigliano notevolmente.

Invece il jpeg non puo' essere decodificato finche' non e' stato interamente
scaricato, e
comunque la decodifica e' integrale, ovvero non puoi scegliere di estrarre
una quantita' inferiore di informazione perche' la scala a cui sei e' bassa.

Devi sempre estrarre tutto e poi generalizzi , semplichi , renderizzi come
credi meglio.

Infine sui dbms:

vorrei far presente che un file TIFF tiled e' una struttura di dati
organizzata, esattamente come lo e' un database. Solo non e' relazionale e
non dispone di indici.
Ad esempio se vuoi guardare una piccola porzione, e' vero che ti devi
esplodere solo quella o poche altre, ma le devi trovare e nel tiff-tile non
vi e' un indice spaziale.

L'unico vantaggio rispetto a una struttura dbms lo si puo' avere se si
considera che il database non ha dei tipi di dato ottimizzati per le
immagini, ovvero se dentro un binary ci mette il file immagine, non utilizza
una struttura dati ottimizzata per certi tipi di dati.
Ma nel caso del rasterlite, come in oracle, e in altri container, immagino
che la struttura dati sia stata studiata per ospitare in maniera ottimizzata
immagini a colori di tipo georeferenziato, e quindi non rimarrei troppo
stupito se alla fine dei salmi le prestazioni se non paragonabili risultino
addirittura migliori.
Nei formati a file, ogni tentativo di ottimizzazione finisce all'interno del
file.
Ma quando si deve mettere insieme piu' files per la mosaicatura, il problema
e' che la sovrastruttura e' indipendente e agisce autonomamente.
Invece nel db non esiste sovrastruttura, tutte le immagii o se si vuole
tutti i tiles sono nel medeismo db.
Per qui l'efficienza e' massimizzata.

Su oracle aggiungo un particolare,
nella versione 10 (l'ultima che conosco),
addirittura quando vi si carica una immagine raster esos non la lascia
intonsa, ma se la sbriciolava in tile fisici.
Ovvero una immagine TIFF come si conosce noi, diventava qualche migliaio di
records in una tabella (di tipo particolare, in cui i records non erano
accedibili dall'esterno singolarmente, ma sempre una tabella)
Questo per dire come i dati vengono archiviati in un db per massimizzare le
performances.
btw, anche RasterLite usa JPEG: quindi il problema dovrebbe riproposi
esattamente invariato, no ?
non ho mai fatto verifiche in condizioni di concorrenza/parallelismo
spinto, ma
a lume di naso non sembrerebbe.
Come dicevo non conosco in dettaglio rasterlite e quindi se usi la jpeg
certamente hai i limiti di tale compressione.
Riduci il problema se sbricioli l'immagine in tanti tiles distinti , come
fossero tante immaginine piccole, ognuna di tipo jpeg. A quel punto riduci
l'onere computazionale alla porzione che ti serve effettivamente, e sfrutti
gli indici del db sqlite per raggiungere rapidamente le porzioni che ti
servono.

Il problema nel tuo caso del rasterlite, e' caso mai che il rasterlite non
si presta a un utilizzo tramite un flusso, ovvero essendo in un db quando
accedi al db via rete devi scaricare sempre tuttoo il db prima di potervi
accedere e decodificare quello che cerchi.

Invece un formato come l'ecw e' nato per essere usato via flusso, e quindi
va bene anche in rete.
Post by unknown
Aggiungo che il formato tiff+jpeg e' una coppia sciagurata per
internet.
Post by unknown
Infatti la decompressione jpeg porta via risorse e avere i tiff compressi
in jpeg abbassa
Post by unknown
tantissimo le prestazioni della macchina.
Non parlo tanto quando hai n utente solo (te stesso) ma piuttosto quando
comincia ad avere piu'
Post by unknown
utenti in contemporanea.
Dal punto di vista prestazionale al formato tiff+jpeg e' preferibile il
tiff uncompressed,
Post by unknown
sebbene capisco che eroda notevolmente lo spazio disco.
D'altra parte la coperta e' quella, se tiri da una parte ...
Punto di discussione molto interessante (e suggestivo).
quindi
richiamarlo in continuazione assorbe risorse, specie in termini di CPU.
La cosa che però trovo abbastanza curiosa è che l'algoritmo di
decompressione
Wavelet (quello utilizzato dai vari MrSID, ECW, JPEG2000 etc) si basa
sicuramente
su una matematica più complessa, e molto più pesante in termini
computazionali.
Quindi come è possibile che p.es. ECW "gira svelto", mentre JPEG "gira
lento" ?
questa cosa mi convince assai poco, e mi puzza più di mitologia che di
realtà
oggettiva.
A mio modesto parere (ed esperienza), il nocciolo del problema è che TIFF
non è un vero e proprio formato, ma piuttosto una variegata famiglia di
formati, con caratteristiche anche molto differenti tra di loro.
Ma anche JPEG è un algoritmo altamente flessibile e parametrizzabile,
in grado di "strizzare" tanto o poco, con qualità ottima oppure indecente
...
insomma, parlare di "TIFF/JPEG" senza qualificare meglio rischia di
essere talmente generico da perdere qualsivoglia significato tecnico.
a) sicuramente un TIFF "non compresso" offre i migliori tempi di risposta,
visto che i tempi di accesso comprendono esclusivamente l'I/O
b1) un TIFF con struttura "strip" fatica sicuramente in lettura, specie
quando occorre prelevare semplicemente una piccola porzione
dell'immagine
b2) invece un TIFF con struttura "tile" gonfia leggermente come spazio,
però
offre tempi di accesso di gran lunga migliori.
Identificare la dimensione ottimale della tile non è banale, e
sicuramente
causa sensibili differenze di velocità: tipicamente i risultati
migliori
si ottengono usando tiles 'piccole', p.es. 256x256 oppure 512x512
c) se poi si applica la compressione JPEG, la questione si complica ancor
di
più ... perchè oltre all'I/O occorre considerare il tempo di decodifica
c1) una struttura "strip" non è sicuramente in grado di offrire buona
velocità,
perchè con elevata probabilità costringe a decomprimere anche porzioni
di
immagine assolutamente inutili (= che non verranno utilizzate)
c2) viceversa la struttura "tile" (almeno nella mia personale esperienza)
può
offrire tempi di risposta molto fluidi, sempre che si abbia
l'accortezza
di usare tiles ragionevolmente 'piccole'
Poi (ovviamente) occorre considerare la questione delle 'piramidi', cioè
di come supportare efficacemente una struttura multi-risoluzione.
E penso proprio che è qui che gli algoritmi Wavelet hanno un vantaggio
concreto, visto che questo algoritmo ha la capacità intrinseca di
effettuare la decompressione a varie risoluzioni, caratteristica che
invece manca (parzialmente) all'algoritmo JPEG.
Quindi usando TIFF (oppure TIFF/JPEG) occorre sicuramente generare una
struttura "a piramide" per potere ottenere buoni tempi di accesso,
ma questo implica consumare un buon 40% di spazio disco aggiuntivo ...
conclusione: non sempre è facile confrontare "le mele con le mele,
e le pere con le pere" ... specie quando, come in questo caso,
i parametri da tenere sotto controllo sono svariati, e tutti
possono essere fortemente influenti.
Post by unknown
Poi se si cambia formato, e si esclude i canonici ecw e jpeg2000 (ognuno
con i propri problemi)
Post by unknown
io ti potrei suggerire di dare una occhiata al formato RasterLite.
btw, anche RasterLite usa JPEG: quindi il problema dovrebbe riproposi
esattamente invariato, no ?
non ho mai fatto verifiche in condizioni di concorrenza/parallelismo
spinto, ma
a lume di naso non sembrerebbe.
Comunque un bel benchmark serio ed oggettivo potrebbe fare luce sulla
peccato solo che p.es. il MrSID SDK esclude esplicitamente nelle
condizioni di
licenza la possibilità di fare benchmarking comparativo rendendo pubblici i
dati :-(
Infine, in quanto "babbo" di RasterLite consentitemi di spezzare una
lancia a favore dei "raster dentro ai DBMS".
Si, sicuramente l'I/O è più farragginoso: ma considerate anche che
(almeno RasterLite) si trae tutto il vantaggio di avere uno Spatial
Index associato alle immagini.
Cosa che invece manca completamente usando TIFF: può anche sembrare
banale, ma vi siete mai chiesti quanti cicli di CPU ci vogliono (per
non parlare degli accessi a disco) solo per scandire la lista delle tiles
e potere quindi identificare quelle (poche) di effettivo interesse ?
specie se nel frattempo occorre anche aprire e chiudere un qualche
centinaio
di files, ripetendo ogni volta il parsing della directory dei tags TIFF ?
ciao Sandro
--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.faunalia.it/pipermail/gfoss/attachments/20100720/d92f0378/attachment-0001.htm>
unknown
2010-07-20 11:24:16 UTC
Permalink
Invece nel db non esiste sovrastruttura, tutte le immagii o se si vuole tutti i tiles sono nel medeismo db.
Per qui l'efficienza e' massimizzata.
Su oracle aggiungo un particolare,
nella versione 10 (l'ultima che conosco),
addirittura quando vi si carica una immagine raster esos non la lascia intonsa, ma se la sbriciolava in tile fisici.
Ovvero una immagine TIFF come si conosce noi, diventava qualche migliaio di records in una tabella (di tipo particolare, in cui i records non erano accedibili dall'esterno singolarmente, ma sempre una tabella)
Questo per dire come i dati vengono archiviati in un db per massimizzare le performances.
Esattamente come fa anche rasterlite: alla fine hai un visibilio di tiles individuali (anche svariati milioni,
se la coverage è bella grossa), ma tutte di piccole dimensioni (e quindi facilmente elaborabili), e tutte
spatially index (e quindi celermente selezionabili).
E poi, naturalmente, rasterlite si auto-genera anche una struttura piramidale interna di supporto.
Come dicevo non conosco in dettaglio rasterlite e quindi se usi la jpeg certamente hai i limiti di tale compressione.
Riduci il problema se sbricioli l'immagine in tanti tiles distinti , come fossero tante immaginine piccole, ognuna di tipo jpeg. A quel punto riduci l'onere computazionale alla porzione che ti serve effettivamente, e sfrutti gli indici del db sqlite per raggiungere rapidamente le porzioni che ti servono.
infatti, è esattamente così: posso solo aggiungere che rasterlite non ti costringe affatto ad usare
per forza la compressione JPEG: puoi anche scegliere di usare "non compresso", oppure la buona
vecchia DEFLATE (quella di PNG, per capirsi), ma anche una Wavelet open source (epsilon).
EPSILON può anche essere "loseless", ma in questo caso ti devi accontentare di un
rapporto di compressione 50% [assai modesto, ma sicuramente migliore di DEFLATE]:
se invece decidi di utilizzare EPSILON in modalità "lossy", allora puoi anche raggiungere
rapporti di compressione inferiori al 10%, pur mantenendo una qualità decente.
Il problema nel tuo caso del rasterlite, e' caso mai che il rasterlite non si presta a un utilizzo tramite un flusso, ovvero essendo in un db quando accedi al db via rete devi scaricare sempre tuttoo il db prima di potervi accedere e decodificare quello che cerchi.
OK: e questo è il "punto doloroso" di rasterlite, che non adottando nessuna architettura
client server ti costringe a tenere il file-DB in locale, sulla medesima piattaforma usata
per l'elaborazione. altrimenti i tempi di accesso p.es. via network filesystem diventano
sicuramente proibitivi.

Ma se p.es. rasterlite viene usato per alimentare un servizio WMS il problema
ovviamente non si pone: BTW, mica qualcuno ha fatto qualche test ???????

ciao Sandro

-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.faunalia.it/pipermail/gfoss/attachments/20100720/2748538f/attachment.htm>
unknown
2010-07-20 12:30:42 UTC
Permalink
In rasterlite, in sede di popolamento,
e' possibile dirgli di trattare come trasparente un certo livello di colore
?

Altrimenti , come dicevo e' pressoche' obbligatorio l'impiego della epsilon
quando non si ha delle OFC.
**infatti, è esattamente così: posso solo aggiungere che rasterlite non ti
costringe affatto ad usare
per forza la compressione JPEG: puoi anche scegliere di usare "non
compresso", oppure la buona
vecchia DEFLATE (quella di PNG, per capirsi), ma anche una Wavelet open source (epsilon).
EPSILON può anche essere "loseless", ma in questo caso ti devi accontentare di un
se invece decidi di utilizzare EPSILON in modalità "lossy", allora puoi anche raggiungere
rapporti di compressione inferiori al 10%, pur mantenendo una qualità decente.
--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.faunalia.it/pipermail/gfoss/attachments/20100720/39cdb33a/attachment-0001.htm>
unknown
2010-07-20 13:28:03 UTC
Permalink
Almeno per come li conosco io i raster, gli indici spaziali su essi non
servono a nulla. A prescindere dal formato di archiviazione.

Un indice serve a mettere ordine ad un'informazione distribuita in
maniera più o meno casuale.

In un raster non vedo alcun disordine.
Dal TopLeft al BottomRight ci sono tutti i pixel (diciamo al 99%).

Cosa diversa dal vettoriale dove le feature ci possono essere o meno.

Quindi perchè scandire uin indice spaziale (I/O quindi) se posso con due
conticini (200 cicli di clock?) sapere dove si trova l'informazione che
mi serve?

O mi sbaglio?

Cristoforo
*On Tue, 20 Jul 2010 12:56:33 +0200, Andrea Peri wrote*
Post by unknown
Invece nel db non esiste sovrastruttura, tutte le immagii o se si
vuole tutti i tiles sono nel medeismo db.
Post by unknown
Per qui l'efficienza e' massimizzata.
Su oracle aggiungo un particolare,
nella versione 10 (l'ultima che conosco),
addirittura quando vi si carica una immagine raster esos non la
lascia intonsa, ma se la sbriciolava in tile fisici.
Post by unknown
Ovvero una immagine TIFF come si conosce noi, diventava qualche
migliaio di records in una tabella (di tipo particolare, in cui i
records non erano accedibili dall'esterno singolarmente, ma sempre una
tabella)
Post by unknown
Questo per dire come i dati vengono archiviati in un db per
massimizzare le performances.
Esattamente come fa anche rasterlite: alla fine hai un visibilio di
tiles individuali (anche svariati milioni,
se la coverage è bella grossa), ma tutte di piccole dimensioni (e
quindi facilmente elaborabili), e tutte
spatially index (e quindi celermente selezionabili).
E poi, naturalmente, rasterlite si auto-genera anche una struttura
piramidale interna di supporto.
Post by unknown
Come dicevo non conosco in dettaglio rasterlite e quindi se usi la
jpeg certamente hai i limiti di tale compressione.
Post by unknown
Riduci il problema se sbricioli l'immagine in tanti tiles distinti ,
come fossero tante immaginine piccole, ognuna di tipo jpeg. A quel
punto riduci l'onere computazionale alla porzione che ti serve
effettivamente, e sfrutti gli indici del db sqlite per raggiungere
rapidamente le porzioni che ti servono.
infatti, è esattamente così: posso solo aggiungere che rasterlite non
ti costringe affatto ad usare
per forza la compressione JPEG: puoi anche scegliere di usare "non
compresso", oppure la buona
vecchia DEFLATE (quella di PNG, per capirsi), ma anche una Wavelet open source (epsilon).
EPSILON può anche essere "loseless", ma in questo caso ti devi accontentare di un
se invece decidi di utilizzare EPSILON in modalità "lossy", allora puoi anche raggiungere
rapporti di compressione inferiori al 10%, pur mantenendo una qualità decente.
Post by unknown
Il problema nel tuo caso del rasterlite, e' caso mai che il
rasterlite non si presta a un utilizzo tramite un flusso, ovvero
essendo in un db quando accedi al db via rete devi scaricare sempre
tuttoo il db prima di potervi accedere e decodificare quello che cerchi.
OK: e questo è il "punto doloroso" di rasterlite, che non adottando nessuna architettura
client server ti costringe a tenere il file-DB in locale, sulla medesima piattaforma usata
per l'elaborazione. altrimenti i tempi di accesso p.es. via network filesystem diventano
sicuramente proibitivi.
Ma se p.es. rasterlite viene usato per alimentare un servizio WMS il problema
ovviamente non si pone: BTW, mica qualcuno ha fatto qualche test ???????
ciao Sandro
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss a faunalia.it
http://lists.faunalia.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
460 iscritti al 15.7.2010
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.faunalia.it/pipermail/gfoss/attachments/20100720/9d9448df/attachment-0001.htm>
unknown
2010-07-20 13:48:49 UTC
Permalink
Almeno per come li conosco io i raster, gli indici spaziali su essi nonservono a nulla. A prescindere dal formato di archiviazione.
Un indice serve a mettere ordine ad un'informazione distribuita inmaniera più o meno casuale.
In un raster non vedo alcun disordine.
Dal TopLeft al BottomRight ci sono tutti i pixel (diciamo al 99%).
Cosa diversa dal vettoriale dove le feature ci possono essere o meno.
Quindi perchè scandire uin indice spaziale (I/O quindi) se posso condue conticini (200 cicli di clock?) sapere dove si trova l'informazioneche mi serve?
O mi sbaglio?
mica detto :-)
se usi un singolo file raster (p.es. un GeoTiff) hai ragione tu:
usare uno spatial index è sicuramente un overkill

ma immagina invece (caso assai più realistico) di dovere
gestire un mosaico composto da qualche centinaio di GeoTiff;
che magari non formano neppure un bel rettangolo preciso,
ma una figura assai più frastagliata ... caso tipico, pensa alla
coverage di una provincia / regione / nazione
e magari sbattici sopra una decina di livelli "piramidali" ...

... ecco che lo Spatial Index serve, eccome se serve :-)

ciao Sandro

-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.faunalia.it/pipermail/gfoss/attachments/20100720/3728f66c/attachment.htm>
unknown
2010-07-20 14:57:22 UTC
Permalink
Giuro solennemente che poi la smetto di tediarvi:
ma personalmente trovo questo thread assolutamente
stimolante, anche per sviluppi futuribili ma non troppo :-)

insomma, riesaminando a ritroso tutta la storia della
gestione delle immagini raster per il GIS alla fine saltano
fuori un paio di spunti *molto* stuzzicanti:

a) il mercato è dominato da formati chiusi e proprietari,
    sicuramente interessanti per molte caratteristiche
    tecniche che offrono, ma altrettanto sicuramente
    altamente indesiderabili (proprio in quanto formati chiusi)

b) d'altra parte, è anche vero che il supporto FLOSS è
    in qualche modo "fossilizzato" su tecnologie sicuramente
    stabili e consolidate, ma altrettanto sicuramente abbastanza
    vecchiotte (= obsolete ???? may well be ...)

Insomma, abbiamo il GeoTIFF (e ce lo teniamo bello stretto,
ovviamente), però è anche vero che:

1) JPEG è un algoritmo altamente flessibile e configurabile:
    è veramente un peccato che invece libtiff lo "fossilizza"
    utilizzando un'unica modalità di compressione predefinita.
    non è possibile parametrizzare nulla di nulla.

2) libjpeg (da lungo tempo) offre una caratteristica molto
   appetibile: consente di decomprimere "al volo" un'immagine
   ridotta in scala 1:2, 1:4 ed 1:8
   ovviamente, tanto minore è la dimensione richiesta, tanto
   maggiore è la velocità di elaborazione. e per altro, con una
   qualità visuale "eccezzziunale veramente": l'ho appena testato :-)
   ma libtiff "nasconde" questa caratteristica, che diviene
   completamente inaccessibile.

3) infine qualche mitologia da sfatare.
    JPEG è solo lossy, vero ??? lo sanno tutti ...
    ... per avere una compressione lossless efficiente occorre
    usare JPEG2000 ... che è disponibile solo in implementazioni
    proprietarie (esiste anche open-source, ma gira con una
    lentezza esasperante ...)
   
peccato che tutto questo è semplicemente FALSO. vedi:
http://en.wikipedia.org/wiki/Lossless_JPEG

esiste una specifica ufficiale JPEG-LS (lossless): ed esiste
anche una libreria FLOSS (BSD-like) che lo gestisce:
http://charls.codeplex.com/documentation
   
da quanto affermano, si ottiene una compressione di
circa il 25% (niente male), e dovrebbe essere anche
"bella veloce".
appena ho il tempo di fare qualche test preliminare
vi faccio sapere se è vero :-)

ciao Sandro

    ancora

-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.faunalia.it/pipermail/gfoss/attachments/20100720/1d265805/attachment.htm>
unknown
2010-07-20 20:23:56 UTC
Permalink
mi fa piacere aver scatenato questa discussione interessantissima!
Sarebbe bellissimo che tutte i concetti emersi confluissero in una paginetta
wiki/blog/howto/somethingelse in modo da non andare persi e da costituire un
riferimento per chi si avvicina alla scelta (e magari ha veramente la
liberta' di scegliere un formato piuttosto che un'altro)

grazie comunque per tutte le spiegazioni

alberto

2010/7/20 <a.furieri a lqt.it>
Post by unknown
ma personalmente trovo questo thread assolutamente
stimolante, anche per sviluppi futuribili ma non troppo :-)
insomma, riesaminando a ritroso tutta la storia della
gestione delle immagini raster per il GIS alla fine saltano
a) il mercato è dominato da formati chiusi e proprietari,
sicuramente interessanti per molte caratteristiche
tecniche che offrono, ma altrettanto sicuramente
altamente indesiderabili (proprio in quanto formati chiusi)
b) d'altra parte, è anche vero che il supporto FLOSS è
in qualche modo "fossilizzato" su tecnologie sicuramente
stabili e consolidate, ma altrettanto sicuramente abbastanza
vecchiotte (= obsolete ???? may well be ...)
Insomma, abbiamo il GeoTIFF (e ce lo teniamo bello stretto,
è veramente un peccato che invece libtiff lo "fossilizza"
utilizzando un'unica modalità di compressione predefinita.
non è possibile parametrizzare nulla di nulla.
2) libjpeg (da lungo tempo) offre una caratteristica molto
appetibile: consente di decomprimere "al volo" un'immagine
ridotta in scala 1:2, 1:4 ed 1:8
ovviamente, tanto minore è la dimensione richiesta, tanto
maggiore è la velocità di elaborazione. e per altro, con una
qualità visuale "eccezzziunale veramente": l'ho appena testato :-)
ma libtiff "nasconde" questa caratteristica, che diviene
completamente inaccessibile.
3) infine qualche mitologia da sfatare.
JPEG è solo lossy, vero ??? lo sanno tutti ...
... per avere una compressione lossless efficiente occorre
usare JPEG2000 ... che è disponibile solo in implementazioni
proprietarie (esiste anche open-source, ma gira con una
lentezza esasperante ...)
http://en.wikipedia.org/wiki/Lossless_JPEG
esiste una specifica ufficiale JPEG-LS (lossless): ed esiste
http://charls.codeplex.com/documentation
da quanto affermano, si ottiene una compressione di
circa il 25% (niente male), e dovrebbe essere anche
"bella veloce".
appena ho il tempo di fare qualche test preliminare
vi faccio sapere se è vero :-)
ciao Sandro
ancora
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss a faunalia.it
http://lists.faunalia.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
460 iscritti al 15.7.2010
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.faunalia.it/pipermail/gfoss/attachments/20100720/3b6c4e5e/attachment.htm>
unknown
2010-07-22 08:23:38 UTC
Permalink
Post by unknown
mi fa piacere aver scatenato questa discussione interessantissima!
Prova su strada:

in QGIS, questa http://download.gfoss.it/TrueMarble/TrueMarble-250m.sqlite
e' enormemente piu' veloce di questa:
http://ueod-globe.net/globe/TrueMarble_GeoTIFF/TrueMarble.250m.21600x21600.D2.tif.gz

Provare per credere.
Saluti.
--
Paolo Cavallini: http://www.faunalia.it/pc
unknown
2010-07-23 19:43:22 UTC
Permalink
Post by unknown
Post by unknown
mi fa piacere aver scatenato questa discussione interessantissima!
in QGIS, questa http://download.gfoss.it/TrueMarble/TrueMarble-250m.sqlite
http://ueod-globe.net/globe/TrueMarble_GeoTIFF/TrueMarble.250m.21600x21600.D2.tif.gz
Con overview o senza la geotiff?
--
Francesco P. Lovergine
unknown
2010-07-23 22:02:03 UTC
Permalink
Post by unknown
Con overview o senza la geotiff?
plain, cosi' come sono. ovviamente su tiff si puo' fare di meglio, ma e' interessante
che di partenza ci sia un enorme vantaggio a favore di rasterlite.
saluti!
--
Paolo Cavallini: http://www.faunalia.it/pc
unknown
2010-07-20 09:12:18 UTC
Permalink
gfoss-bounces at faunalia.it scritti il 20/07/2010 11.02.41
Post by unknown
Ciao,
riguardo rasterlite, non ho provato con mapserver (o altre
applicazioni di web mapping),
ma in applicazioni di tipo desktop (grass, qgis, ossim) mi ha dato
ottimi risultati.
Qgis supporta rasterlite? Dal ticket seguente sembrerebbe di no...

https://trac.osgeo.org/qgis/ticket/2839
unknown
2010-07-20 09:16:53 UTC
Permalink
Post by unknown
Qgis supporta rasterlite? Dal ticket seguente sembrerebbe di no...
https://trac.osgeo.org/qgis/ticket/2839
Rasterlite viene letto tramite GDAL, quindi richiede GDAL 1.7.
Rimane il problema con i db che contengono >1 raster. Inoltre, lo spatialite manager
e' ancora in uno stadio precoce di sviluppo.
Invito gli interessati a collaborare allo sviluppo.
Saluti.
--
Paolo Cavallini: http://www.faunalia.it/pc
unknown
2010-07-20 10:31:38 UTC
Permalink
Post by unknown
Sicuramente non è un formato libero, e purtroppo ERDAS non ha ancora
rilasciato la nuova versione, ma che su Internet non sia un granchè
avrei i miei forti dubbi.
Qui <http://blog.webmapper.com.au/image-server-benchmark/>c'è un bel
benchmark che incrocia tecnologie server e formati.
Chiaramente ogni formato avrà i propri pregi e i propri difetti e tutto
è sempre opinabile.
Non ho detto che non sia veloce , ho detto che non e' un granche'.
l' ecw e' con perdita.

se lo usi per le OFC rifilate, va benissimo.
Prova a usarlo con immagini a colori georeferenziate dotate di un bel
bordino bianco, che non puoi rimuovere perche' il contenuto
non e' rettangolare.
E avrai qualche "sorpresa ".

Il jpeg2000 , ad esempio, e' anche lossless e questo permette di gestire i
bordi in maniera altamente efficiente.

Per un formato che pretende di essere moderno, la mancanza dell'opzione
lossless e' una grave mancanza.
--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.faunalia.it/pipermail/gfoss/attachments/20100720/ecf926ac/attachment.htm>
unknown
2010-07-20 11:20:33 UTC
Permalink
Post by unknown
Post by unknown
Sicuramente non è un formato libero, e purtroppo ERDAS non ha ancora
rilasciato la nuova versione, ma che su Internet non sia un granchè
avrei i miei forti dubbi.
Qui<http://blog.webmapper.com.au/image-server-benchmark/>c'è un bel
benchmark che incrocia tecnologie server e formati.
Chiaramente ogni formato avrà i propri pregi e i propri difetti e tutto
è sempre opinabile.
Non ho detto che non sia veloce , ho detto che non e' un granche'.
Il benchmark non l'ho fatto io e mi sembra sia proprio valido come formato.
Certo, mi hanno riferito che in Germania lo usano a tile non pensando
minimamente che si possano mosaicare fino ai terabyte. Insomma va usato
bene.
Post by unknown
l' ecw e' con perdita.
anche l'MP3 lo è.
ECW per l'occhio, mp3 per l'orecchio. Serve un formato di compressione
per la lingua e il naso.
Post by unknown
se lo usi per le OFC rifilate, va benissimo.
Prova a usarlo con immagini a colori georeferenziate dotate di un bel
bordino bianco, che non puoi rimuovere perche' il contenuto
non e' rettangolare.
E avrai qualche "sorpresa ".
In realtà attualmente
<http://www.erdas.com/LinkClick.aspx?fileticket=CPAMApyT6Us%3d&tabid=83&mid=418>è
supportata la seguente feature
/Imagery clipping and transparency is now supported during ECW file
compression. With opacity channel applied,
any artifacts outside of the actual image are set to transparent.
/
Post by unknown
Il jpeg2000 , ad esempio, e' anche lossless e questo permette di
gestire i bordi in maniera altamente efficiente.
Per un formato che pretende di essere moderno, la mancanza
dell'opzione lossless e' una grave mancanza.
E' una scelta progettuale e la risposta a tale carenza è proprio quella
di usare il JPEG2000.

Infatti

* ECW è stato sviluppato specificamente per i dati EO e per quelle
applicazioni dove è più importante l'impatto visivo del digital
number.
* JPEG2000 è general purpose e non può non avere la compressione
lossless.

Ciao
Cristoforo

PS: Ai miei clienti, per memorizzare informazioni raster, consiglio solo
ECW e JPEG2000, a seconda delle necessità (che sicuramente non sono
solamente quelle collegate al fatto che uno sia aperto e uno no). Gli
altri formati si discutono solo in seconda battuta.
Post by unknown
--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss a faunalia.it
http://lists.faunalia.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
460 iscritti al 15.7.2010
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.faunalia.it/pipermail/gfoss/attachments/20100720/d4e531f6/attachment.htm>
unknown
2010-07-20 12:23:41 UTC
Permalink
Post by unknown
In realtà attualmente
<http://www.erdas.com/LinkClick.aspx?fileticket=CPAMApyT6Us%3d&tabid=83&mid=418>è
supportata la seguente feature
/Imagery clipping and transparency is now supported during ECW file
compression. With opacity channel applied,
any artifacts outside of the actual image are set to transparent.
Conoscevo la tecnica.

Il problema e' che quella che defiiscono immagine e' il contorno di un
poligono semplice che delinea la parte da rendere opaca.

Il problema e' che delineare tale poligono non e' affatto semplice,
specie perche' con gli shapefile operi con vettori, mentre alla fine
il poligono deve ricondursi a celle (pixels) e quindi avere una trama a celle.
Altrimenti non sei sicuro se un pixel sul bordo verra' reso
trasparente oppure no.
E questo lavoraccio se te lo devi fare per una immagine passi, fallo
per qualche centinao di immagini e vedi che
forse finisci per preferire un formato ove il colore di sfondo (bianco
solitamente) viene conservato tale e quale.
Al che basta dire al sistema di rendere il bianco a trasparente e il
gioco e' fatto.
Post by unknown
* ECW è stato sviluppato specificamente per i dati EO e per quelle
Secondo me l'unico tipo di immagini su cui l' ecw funziona veramente
bene sono le OFC a colori e a livelli di grigio.
E funziona solo perche' le OFC non sono rifilate, ma hanno sempre una
parziale sovrapposizione.

Dove non funziona proprio e' quando le immagini provengono da singole
immagini prodotte e georeferenziate singolarmente.
A meno di compiere un enorme lavoro di rifilatura tramite quei
poligoni di delimitazione.
Post by unknown
applicazioni dove è più importante l'impatto visivo del digital
number.
Non e' un discorso di tipo di uso (impatto visivo), ma di tipo di dati:
infatti nelle OFC funziona bene, ma se metti a video delle immagini
con bordatura , non e' che sia di grande impatto visivo
vedere delle reticolature grigiastre che interferiscono qua' e la'
nella mosaicatura delle immagini.
Post by unknown
* JPEG2000 è general purpose e non può non avere la compressione
lossless.
Non e' un problema di destinazione d'uso, ma di approccio.

Formati come il jpeg2000 adottano degli algoritmi di compressione che
possono essere indifferentemente lossy o lossless.

Nel caso di altri formati piu' antichi, come il tiff la scelta era fisica.
Ovvero se sceglievi TIF con packbit avrai una compressione senza perdita
se scegli tiff con jpeg avrai compressione con perdita.
poi pero' ti ritrovavi a dei tiff che magari il tuo software GIS non leggeva
perche' magari conosceva il TIFF ma solo con la compressione packbit e non
quello con la compressione jpeg (o la lzw).

Nel caso dell' ecw e' semplicemente che lui adotta degli algoritmi che non
ammettono la lossless ma solo la lossy.
Poi si puo' anche dire che e' una lossy fatta molto bene, ma questo e' un
altro discorso.

Secondo me dire che se ha la capacita' lossless vuol dire che e' un formato
general-purpose e' riduttivo.
Io lo vedo invece come u segno di un algoritmo piu' versatile.

Comunque la prova migliore e' apettare e vedere se tra un po' di tempo erdas
non esce con una nuova versione di ecw in gado di fare
il lossless.
--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.faunalia.it/pipermail/gfoss/attachments/20100720/873cba9f/attachment.htm>
unknown
2010-07-20 13:19:36 UTC
Permalink
Post by unknown
Post by unknown
In realtà attualmente
<http://www.erdas.com/LinkClick.aspx?fileticket=CPAMApyT6Us%3d&tabid=83&mid=418 <http://www.erdas.com/LinkClick.aspx?fileticket=CPAMApyT6Us%3d&tabid=83&mid=418>>è
supportata la seguente feature
/Imagery clipping and transparency is now supported during ECW file
compression. With opacity channel applied,
any artifacts outside of the actual image are set to transparent.
Conoscevo la tecnica.
penso tu possa conoscere la vecchia tecnica, che non ha nulla a che fare
col formato di compressione (qualunque esso sia), ma era semplicemente
un passo di elaborazione dell'immagine.
La feature descritta è proprio nuova e ovviamente non prescinde
dall'individuazione delle zone da rendere opache, che, ripeto, non
centra nulla col formato di compressione, la cui unica capacità deve
essere quella di gestire e rendere disponibile un canale opaco (non di
costruirlo).
Post by unknown
Il problema e' che quella che defiiscono immagine e' il contorno di un poligono semplice che delinea la parte da rendere opaca.
Il problema e' che delineare tale poligono non e' affatto semplice, specie perche' con gli shapefile operi con vettori, mentre alla fine
il poligono deve ricondursi a celle (pixels) e quindi avere una trama a celle.
Altrimenti non sei sicuro se un pixel sul bordo verra' reso trasparente oppure no.
E questo lavoraccio se te lo devi fare per una immagine passi, fallo per qualche centinao di immagini e vedi che
forse finisci per preferire un formato ove il colore di sfondo (bianco solitamente) viene conservato tale e quale.
Al che basta dire al sistema di rendere il bianco a trasparente e il gioco e' fatto.
Penso che faccia proprio così. Infatti genera un canale opaco a partire
da un TIFF lossless.
Post by unknown
Post by unknown
* ECW è stato sviluppato specificamente per i dati EO e per quelle
Secondo me l'unico tipo di immagini su cui l' ecw funziona veramente bene sono le OFC a colori e a livelli di grigio.
E funziona solo perche' le OFC non sono rifilate, ma hanno sempre una parziale sovrapposizione.
Dove non funziona proprio e' quando le immagini provengono da singole immagini prodotte e georeferenziate singolarmente.
A meno di compiere un enorme lavoro di rifilatura tramite quei poligoni di delimitazione.
Non si capisce come un algoritmo di compressione (quale esso sia) possa
risolvere dei problemi collegati alla posizione spaziale dell'immagine o
al bilanciamento dei diversi colori. Se non va bene ECW dubito che gli
altri vadano bene.
Post by unknown
Post by unknown
applicazioni dove è più importante l'impatto visivo del digital
number.
infatti nelle OFC funziona bene, ma se metti a video delle immagini con bordatura , non e' che sia di grande impatto visivo
vedere delle reticolature grigiastre che interferiscono qua' e la' nella mosaicatura delle immagini.
ripeto quanto detto sopra. Non penso che un altro formato possa
migliorare le cose
Post by unknown
Post by unknown
* JPEG2000 è general purpose e non può non avere la compressione
lossless.
Non e' un problema di destinazione d'uso, ma di approccio.
Formati come il jpeg2000 adottano degli algoritmi di compressione che
possono essere indifferentemente lossy o lossless.
Nel caso di altri formati piu' antichi, come il tiff la scelta era fisica.
Ovvero se sceglievi TIF con packbit avrai una compressione senza perdita
se scegli tiff con jpeg avrai compressione con perdita.
poi pero' ti ritrovavi a dei tiff che magari il tuo software GIS non
leggeva perche' magari conosceva il TIFF ma solo con la compressione
packbit e non quello con la compressione jpeg (o la lzw).
Nel caso dell' ecw e' semplicemente che lui adotta degli algoritmi che
non ammettono la lossless ma solo la lossy.
Perchè l'obiettivo non era l'algoritmica, ma lo scopo ingegneristico
dell'inventore.
Post by unknown
Poi si puo' anche dire che e' una lossy fatta molto bene, ma questo e'
un altro discorso.
Secondo me dire che se ha la capacita' lossless vuol dire che e' un
formato general-purpose e' riduttivo.
Certo.
Post by unknown
Io lo vedo invece come u segno di un algoritmo piu' versatile.
Comunque la prova migliore e' apettare e vedere se tra un po' di tempo
erdas non esce con una nuova versione di ecw in gado di fare
il lossless.
Non credo lo voglia fare, proprio perchè esiste già il JPEG2000. A meno
che non scoprano cose per cui ne valga la pena.

Ciao
Cristoforo

PS: è bello disquisire con chi queste cose le capisce, però se siamo
noiosi bannateci! :'(
Post by unknown
--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss a faunalia.it
http://lists.faunalia.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
460 iscritti al 15.7.2010
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.faunalia.it/pipermail/gfoss/attachments/20100720/a9a20d70/attachment.htm>
unknown
2010-07-20 14:16:09 UTC
Permalink
Post by unknown
Almeno per come li conosco io i raster, gli indici spaziali su essi non
servono a nulla. A prescindere dal formato di archiviazione.
Un indice serve a mettere ordine ad un'informazione distribuita in
maniera più o meno casuale.
L'indice non serve a ordinare piu' in fretta, ma a selezionare piu' in fretta.

non e' la stessa cosa.
Un
select * from tabella order by campo1
esegue sempre e comunque un full-scan anche in presenza di un indice.

Tornando alle immagini:
poiche' nel nostro caso l'obiettivo e' selezionare una porzione di territorio
un indice spaziale aiuta a selezionare piu' agevolmente (piu
velocemente) la porzione cercata.
Post by unknown
In un raster non vedo alcun disordine.
Dal TopLeft al BottomRight ci sono tutti i pixel (diciamo al 99%).
Nel raster vi e' un ordine (come nei file vettoriali del resto), ma e'
un file sequenziale che
rappresenta un insieme bidimensionale di dati.
L'unica regole che realmente li differenzia dal vettoriale e' che nel
vettoriale la vicinanza dei records non implica
la vicinanza sul territorio, mentre nei file raster la vicinanza dei
pixel implica il piu' delle volte la vicinanza sul terreno.
Pero' non vale il viceversa (la lontananza non implica lontananza nel
terreno) e quindi
un indice spaziale aiuta a selezionare piu' rapidamente le porzioni di
interesse dell'immagine.
Perche' te non puoi limitarti a prendere tutti i pixel vicini nel
file, ma devi comunque scandire tutto il file per essere
sicuro di averli presi tutti quelli che ti interessava.

E quindi come dicevo all'inizio: un indice aiuta a selezionare.
--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.faunalia.it/pipermail/gfoss/attachments/20100720/0b431016/attachment.htm>
Continue reading on narkive:
Loading...