<HTML>
<HEAD>
<META content="text/html; charset=iso-8859-1" http-equiv=Content-Type>
<META content="OPENWEBMAIL" name=GENERATOR>
</HEAD>
<BODY bgColor=#ffffff>
<font size="2"><b>On Mon, 13 Jun 2011 11:23:55 +0200, G. Allegri wrote</b>
<br />> Nel frattempo? Sostieni anche
tu, Sandro, che Tiff tilizzato con overview può
<br />> portare a risultati, in termini
di performance, comparabili ad ecw?
<br />> Sto parlando sia in locale che in ambito
server.
<br />>
<br />
<br />mi sono ben guardato dal fare qualsiasi benchmark comparativo su
<br />ECW e/o MrSID (anche perchè le rispettive licenze d'uso lo proibiscono
<br />tassativamente !!!)
<br />
<br />comunque, ragionando a spanne, tutti gli algoritmi basati sulle Wavelet
<br />sono estramamente pesanti (e quindi assai lenti).
<br />il buon vecchio onesto JPEG (specie in alcune implementazioni come
<br />libjpeg-turbo) ha dei margini competitivi in termini prestazionali
<br />assolutamente irraggiungibili.
<br />
<br />quindi (sempre a spanne) un buon GeoTIFF debitamente
<br />strutturato per TILES e supportato da piramidi non lascia
<br />probabilmente nulla da rimpiangere in termini prestazionali.
<br />e se si ha l'accortezza di comprimere le TILES come JPEG
<br />anche la differenza in termini di allocazione disco diventa
<br />meno catastrofica.
<br />
<br />come giustamente sostiene Andrea Peri, il vero limite
<br />d'uso dei GeoTIFF è quando risiedono su un server centrale
<br />e molte workstation cercano di leggerli direttamente tramite
<br />LAN. in quel caso l'approccio "stream-oriented" di ECW è
<br />sicuramente imbattibile.
<br />
<br />ma molto probabilmente (come sostiene Giovanni Manghi) mettere
<br />nel mezzo un server WMS che provveda a "spezzettare" le
<br />singole tiles, magari con l'accortezza di veicolarle in rete
<br />in forma compressa (p.es. jpeg) riesce a ripristinare la parità.
<br />(almeno ... in teoria ... in pratica non ho mai provato ...)
<br />
<br />ciao Sandro
<br />
</font>
</BODY>
</HTML>