[Gfoss] ecw con geoserver/gdal: Erdas ha rimosso ecw3.3 runtime lib

Mar 20 Lug 2010 12:56:33 CEST

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 a 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/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
>

-- 
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.faunalia.it/pipermail/gfoss/attachments/20100720/d92f0378/attachment-0001.htm>