[Gfoss] consiglio HARDWARE per sistema webgis

[a.furieri a lqt.it]

On Fri, 26 Oct 2012 11:41:31 +0200, Andrea Aime wrote:
> Dall'altra parte abbiamo un process (WMTS) che deve prendere N tiles,
> necessariamente in PNG (o eventualmente TIFF) visto che abbiamo 
> bisogno
> della traslucenza, combinarle in un'unica immagine, e produrre un 
> file in
> output, eventualmente applicando una quantizzazione al volo se si 
> vuole
> servire un PNG8.
> La parte lenta qui è aprire le n PNG
>

suppongo che spesso questa sia esattamente la parte che spesso sfugge
all'attenzione di molti.
PNG e' sicuramente un ottimo formato, e' lossless e supporta pienamente
le trasparenze; ma in termini velocistici non e' esattamente un 
fulmine.

giusto per fare la classica comparazione tra mele ed arance; JPEG in
confronto a PNG e' un codec decisamente piu' veloce, specie se si usa
la recente libjpeg-turbo su qualche processore Intel di ultima 
generazione,
che supporta appositi codici macchina ottimizzati direttamente in 
hardware.

se poi si tratta di un PNG RGB (PNG24), che magari comprende anche il 
canale
ALPHA (trasparenza), allora il tempo di compressione diventa 
sicuramente
tutt'altro che trascurabile.
semplificando ed approssimando: libpng comprime ciascun canale per 
proprio
conto; quindi un PNG24+ALPHA (rgb + trasparenza) in pratica richiede 
ben
quattro passate successive di compressione.

applicando qualche opportuna quantizzazione si puo' facilmente ottenere
un PNG8 (palette-based), che e' sicuramente piu' leggero, ed anche piu'
veloce da produrre.
ma un buon algoritmo di quantizzazione capace di offrire buoni 
risultati
visivi (tipo median cut) tende a consumare moltissimi cicli macchina, e
quindi introduce ulteriori rallentamenti.

il recentissimo formato Google WEBP potrebbe anche essere in teoria una
alternativa appetibile: e' sia lossy che near-lossy (molto compatto, ma
con alta qualita' apparente), ed a differenza di JPEG supporta anche le
trasparenze.
peccato pero' che il compressore WEBP e' quanto di piu' lento mi sia
mai capitato di incontrare (a parte qualche penoso codec JPEG2000
open source come Jasper o OpenJpeg): per fortuna la decompressione e'
invece molto efficiente.

insomma, o per un verso o per l'altro la gestione dinamica di un 
elevato
volume di immagini compresse richiede comunque risorse di calcolo molto
ingenti.
usare formati non compressi garantisce sicuramente risultati 
velocistici
di eccellenza, ma impone l'uso di spazi di archiviazione 
impressionanti.

purtroppo questo e' quanto offre lo stato dell'arte corrente: temo che
non esistano scorciatoie facili ed indolori.

ciao Sandro

-- 
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.