>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
>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 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
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.
Il giorno 20/lug/2010, alle ore 09.43, Andrea Peri ha scritto:
>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 prestazionidella 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 àèìòù
-----------------_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss@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
Il 20/07/2010 10:23, Cristoforo Abbattista ha scritto:
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
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
gfoss-bounces@faunalia.it scritti il 20/07/2010 11.02.41
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...
Il 20/07/2010 11:12, luca_manganelli@comune.trento.it ha scritto:
Qgis supporta rasterlite? Dal ticket seguente sembrerebbe di no...
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
Qui [<http://blog.webmapper.com.au/image-server-benchmark/>](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](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!
E’ una cosa curiosa che è accaduta e un commento dei validi GFOSSARI sarebbe sicuramente spunto per ulteriori considerazioni.
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: 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
b) 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’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.
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 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 questione:
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
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.
Il giorno 20 luglio 2010 11.38, <a.furieri@lqt.it> ha scritto:
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: 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/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’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 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 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.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 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 questione:
peccato solo che p.es. il MrSID SDK esclude esplicitamente nelle condizioni di
licenza la possibilità di fare benchmarking comparativo rendendo pubblici i datiInfine, 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 àèìòù
On Tue, 20 Jul 2010 12:56:33 +0200, Andrea Peri wrote
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
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.
Il giorno 20 luglio 2010 13.24, <a.furieri@lqt.it> ha scritto:
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.
–
Andrea Peri
. . . . . . . . .
qwerty àèìòù
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 15:28:03 +0200, Cristoforo Abbattista wrote
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?
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
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:
-
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. -
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. -
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
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@lqt.it>
Giuro solennemente che poi la smetto di tediarvi:
ma personalmente trovo questo thread assolutamente
stimolante, anche per sviluppi futuribili ma non troppoinsomma, 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:
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.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.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_JPEGesiste una specifica ufficiale JPEG-LS (lossless): ed esiste
anche una libreria FLOSS (BSD-like) che lo gestisce:
http://charls.codeplex.com/documentationda 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 è verociao Sandro
ancora
Iscriviti all’associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss@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
Il 20/07/2010 22:23, Alberto Valente ha scritto:
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
On Thu, Jul 22, 2010 at 10:23:38AM +0200, Paolo Cavallini wrote:
Il 20/07/2010 22:23, Alberto Valente ha scritto:
> 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
Con overview o senza la geotiff?
--
Francesco P. Lovergine
Il 23/07/2010 21:43, Francesco P. Lovergine ha scritto:
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