> 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
_______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [email protected] 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
