softwarefreedomday.org passa da GoogleMaps ad OpenLayers/OpenStreetMap

[Niccolo Rigacci]

Dopo uno scambio di mail con il comitato web del Software Freedom
Day siamo riusciti a far mettere la mappa di OpenStreetMap con
OpenLayers, piuttosto che la GoogleMap.

http://softwarefreedomday.org/
http://cgi.softwarefreedomday.org/2010/map.shtml

P.S. Questa volta mi ero preso dello "zelota" invece che del
"telebano", ma ne è valsa la pena comunque :-)

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

[a.furieri]

On Fri, 23 Jul 2010 18:25:31 +0200, Niccolo Rigacci wrote

> Dopo uno scambio di mail con il comitato web del Software Freedom
> Day siamo riusciti a far mettere la mappa di OpenStreetMap con
> OpenLayers, piuttosto che la GoogleMap.
>
> http://softwarefreedomday.org/
> http://cgi.softwarefreedomday.org/2010/map.shtml
>
> P.S. Questa volta mi ero preso dello "zelota" invece che del
> "telebano", ma ne è valsa la pena comunque :-)
>

obbravo, bella boccia :-)

ciao Sandro

p.s.: ma si può pretendere di essere un'associazione
seria avendo un presidente "talebano attivista" ed un
vicepresidente "zelota" ????????

cercasi urgentemente un "negro ebreo comunista e frocio"
per opportuno passaggio di consegne.
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
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

[luca menini]

Il 23 luglio 2010 18.25, Niccolo Rigacci <[hidden email]> ha scritto:
> Dopo uno scambio di mail con il comitato web del Software Freedom
> Day siamo riusciti a far mettere la mappa di OpenStreetMap con
> OpenLayers, piuttosto che la GoogleMap.
>

Grande!!!
Complimenti.

luca

--
Sabato 23 ottobre 2010
Nella tua città! http://www.linuxday.it
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
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

[Marica Landini]

Il 23/07/2010 22:04, luca menini ha scritto:

> Il 23 luglio 2010 18.25, Niccolo Rigacci<[hidden email]>  ha scritto:
>    
>> Dopo uno scambio di mail con il comitato web del Software Freedom
>> Day siamo riusciti a far mettere la mappa di OpenStreetMap con
>> OpenLayers, piuttosto che la GoogleMap.
>>
>>      
> Grande!!!
> Complimenti.
>
> luca
>
>    

Mi unisco ai complimenti!

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

[Giuseppe Sucameli]

Grande Niccolò,
sei riuscito addirittura a battere un colosso come Google ;)

2010/7/23 Marica Landini <[hidden email]>

Il 23/07/2010 22:04, luca menini ha scritto:

Il 23 luglio 2010 18.25, Niccolo Rigacci<[hidden email]>  ha scritto:
 

Dopo uno scambio di mail con il comitato web del Software Freedom
Day siamo riusciti a far mettere la mappa di OpenStreetMap con
OpenLayers, piuttosto che la GoogleMap.

   

Grande!!!
Complimenti.

luca

 

Mi unisco ai complimenti!

Marica

--
Giuseppe Sucameli

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

[Luca Delucchi]

Il 23 luglio 2010 18.25, Niccolo Rigacci <[hidden email]> ha scritto:
> Dopo uno scambio di mail con il comitato web del Software Freedom
> Day siamo riusciti a far mettere la mappa di OpenStreetMap con
> OpenLayers, piuttosto che la GoogleMap.
>
> http://softwarefreedomday.org/
> http://cgi.softwarefreedomday.org/2010/map.shtml
>

grande rigacci

> P.S. Questa volta mi ero preso dello "zelota" invece che del
> "telebano", ma ne è valsa la pena comunque :-)
>

:-D

beh mi sembra meglio zelota che talebano ;-)

> --
> Niccolo Rigacci
> Firenze - Italy

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

[a.furieri]

oggi tocca abbassare la cresta (e chiedere umilmente scusa):
anche nel mondo FLOSS ogni tanto si scopre qualche "cappella"

ho appena scoperto che libjpeg [la libreria open source
che gestisce *tutte* le immagini JPEG] è lenta da morire.

Ancor peggio: libjpeg quasi sicuramente è il codec JPEG
più inefficiente e lento oggi disponibile sul mercato:
qualsiasi equivalente proprietario gli bagna il naso,
quanto meno su piattaforme x86 / amd64

la causa:
=========
fin dal tempo dei primi Pentium Intel ha introdotto in
hardware il set di istruzioni MMX/SSE con lo scopo di
supportare i codecs multimediali.
Con i Core 2, i7, i5 etc è stato introdotto SSE2 che
è ancora più potente.
Ma libjpeg ignora del tutto queste istruzioni, mentre
invece i codes proprietari le sfruttano al meglio.

la cura:
========
fortunatamente esiste il progetto libjpeg-turbo.
in pratica è un clone esattamanente identico a libjpeg (stesse
identiche API/ABI), che però gestisce (da assembler) le estensioni
MMX/SSE2 - in questo modo praticamente di dimezzano i tempi di coding
e decoding. risultati misurati personalmente sul campo (su i5):

coding: 2.5secs -> 1.1secs
decoding: 1.7secs -> 0.9secs

licenza: wxWidgets [LGPL, ma consente static linkage]

riferimenti:
============
http://libjpeg-turbo.virtualgl.org/
http://sourceforge.net/projects/libjpeg-turbo/

commento:
=========
probabilmente una "sega mentale" per qualsiasi uso ordinario.
ma in alcuni ambiti applicativi (penso in particolare ai
server WMS) potrebbe anche segnare una differenza significativa.
ovviamente il beneficio si estende anche ai Tiff/Jpeg

ad ogni modo libjpeg-turbo mi pare assolutamente stabile
ed affidabile.
- fare la build è un piacere (anche su WinOZ MSYS+MinGW)
- occorre preinstallare l'assembler NASM
- dopo di che basta copiare la "nuova" libjpeg al posto
  di quella "di sistema" ... voila, il gioco è fatto :-)

ciao Sandro

P.S. (per Frankie)
fare un pensierino per debianizzare libjpeg-turbo: perchè no ???
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
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

[a.furieri]

Saluti a tutta la lista.

Se ben vi ricordate qualche giorno fa si era svolta
in lista una discussione stimolante (ed abbastanza
partecipata) a proposito delle tecnologie per le immagini
raster. Il pretesto iniziale era nato dal fatto che non è
più disponibile il supporto "free as in free beer" per gli ECW.

In quella sede avevo avanzato il suggerimento di fare un
bel benchmark comparativo, quanto meno per avere un minimo
di solida oggettività.

Ok, il benchmark ora è disponibile, e lo trovate qua:
http://www.gaia-gis.it/raster_benchmark

---------

vi faccio direttamente il riassunto di quello che risulta
dal benchmark (a beneficio dei più pigri):

a) JPEG è "infinitamente" più veloce di JPEG2000
b) anche il meno noto JPEG-LS è molto più veloce di JPEG2000
c) per farla breve, JPEG2000 si piazza sicuramente all'ultimo
   posto in classifica in qualsiasi contesto, e con distacco
   veramente abissale.

le compressioni basate su WAVELET paiono essere decisamente
un'idea poco felice: questo algoritmo sofisticato e complesso
(forse, troppo sofisticato e complesso) rimane decisamente
"un'osso duro" anche per l'HW più recente e pimpante.

tuttavia emerge anche come JPEG2000 / WAVELET recuperi poi
alla grande in quanto offre una buona capacità multi-risoluzione,
e quindi può fare tranquillamente a meno delle "piramidi".

conclusione: il segreto sta tutto nell'implementare le
piramidi in modo semplice ed efficiente.
ma questo possiamo tranquillamente ottenerlo anche senza
ricorrere alla complessità delle wavelet: basta ed avanza
il buon vecchio JPEG, se saggiamente utilizzato in tutte
le sue capacità, assai spesso sotto-utilizzate.
Vedi p.es. TIFF/JPEG che ignora del tutto la possibilità di
supportare "a costo zero" i livelli piramidali 1:2, 1:4 ed 1:8

Purtroppo ad oggi nessuna implementazione open source offre
tutto questo: se non RasterLite, ed anche RasterLite solo
in parte.

Quindi: tenetevi pronti per RasterLite v.2.0 :-)

ciao, Sandro


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

[epi]

Ciao Sandro,

ti ringrazio tantissimo per il confronto fatto
ho trovato le informazioni da te descritte di effettiva utilità.
Trovo inoltre molto piacevole il "tono" che usi nello spiegare qualsiasi cosa.

Grazie!


Massimo.

Il giorno 27/lug/2010, alle ore 19.18, [hidden email] ha scritto:

> Saluti a tutta la lista.
>
> Se ben vi ricordate qualche giorno fa si era svolta
> in lista una discussione stimolante (ed abbastanza
> partecipata) a proposito delle tecnologie per le immagini
> raster. Il pretesto iniziale era nato dal fatto che non è
> più disponibile il supporto "free as in free beer" per gli ECW.
>
> In quella sede avevo avanzato il suggerimento di fare un
> bel benchmark comparativo, quanto meno per avere un minimo
> di solida oggettività.
>
> Ok, il benchmark ora è disponibile, e lo trovate qua:
> http://www.gaia-gis.it/raster_benchmark
>
> ---------
>
> vi faccio direttamente il riassunto di quello che risulta
> dal benchmark (a beneficio dei più pigri):
>
> a) JPEG è "infinitamente" più veloce di JPEG2000
> b) anche il meno noto JPEG-LS è molto più veloce di JPEG2000
> c) per farla breve, JPEG2000 si piazza sicuramente all'ultimo
>   posto in classifica in qualsiasi contesto, e con distacco
>   veramente abissale.
>
> le compressioni basate su WAVELET paiono essere decisamente
> un'idea poco felice: questo algoritmo sofisticato e complesso
> (forse, troppo sofisticato e complesso) rimane decisamente
> "un'osso duro" anche per l'HW più recente e pimpante.
>
> tuttavia emerge anche come JPEG2000 / WAVELET recuperi poi
> alla grande in quanto offre una buona capacità multi-risoluzione,
> e quindi può fare tranquillamente a meno delle "piramidi".
>
> conclusione: il segreto sta tutto nell'implementare le
> piramidi in modo semplice ed efficiente.
> ma questo possiamo tranquillamente ottenerlo anche senza
> ricorrere alla complessità delle wavelet: basta ed avanza
> il buon vecchio JPEG, se saggiamente utilizzato in tutte
> le sue capacità, assai spesso sotto-utilizzate.
> Vedi p.es. TIFF/JPEG che ignora del tutto la possibilità di
> supportare "a costo zero" i livelli piramidali 1:2, 1:4 ed 1:8
>
> Purtroppo ad oggi nessuna implementazione open source offre
> tutto questo: se non RasterLite, ed anche RasterLite solo
> in parte.
>
> Quindi: tenetevi pronti per RasterLite v.2.0 :-)
>
> ciao, Sandro
>
>
> _______________________________________________
> Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
> [hidden email]
> 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

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

[Paolo Corti]

>> ti ringrazio tantissimo per il confronto fatto
> ho trovato le informazioni da te descritte di effettiva utilità.
> Trovo inoltre molto piacevole il "tono" che usi nello spiegare qualsiasi cosa.
>

quoto tutto, grande Sandro!
P

--
Paolo Corti
GIS Architect and Developer
web: http://www.paolocorti.net
twitter: @paolo_corti
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
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

[Simone Giannecchini]

Ciao Sandro,
comparativa molto interessante anche se un po biased imho :)

- Quando parli di performance sarebbe interessante sapere se/come hai
misurato i tempi e che librerie/sdk hai usato.

- Quando parli di jpeg2000, bisogna tenere conto del fatto che _ogni_
libreria open conosciuta fa veramente pena, mentre se usi kakadu o ecw
sdk le performance possono essere diventare interessanti.

Ciao,
Simone.
-------------------------------------------------------
==
IMPORTANT NOTICE
I will be on vacation from 2nd of August to 9th of August.
For urgent matters, please, contact Daniele Romagnoli at
[hidden email]
==
Ing. Simone Giannecchini
GeoSolutions S.A.S.
Founder
Via Carignoni 51
55041  Camaiore (LU)
Italy

phone: [phone]
fax:      [phone]
mob:    [phone]


http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/simonegiannecchini
http://twitter.com/simogeo

-------------------------------------------------------



2010/7/27  <[hidden email]>:

> Saluti a tutta la lista.
>
> Se ben vi ricordate qualche giorno fa si era svolta
> in lista una discussione stimolante (ed abbastanza
> partecipata) a proposito delle tecnologie per le immagini
> raster. Il pretesto iniziale era nato dal fatto che non è
> più disponibile il supporto "free as in free beer" per gli ECW.
>
> In quella sede avevo avanzato il suggerimento di fare un
> bel benchmark comparativo, quanto meno per avere un minimo
> di solida oggettività.
>
> Ok, il benchmark ora è disponibile, e lo trovate qua:
> http://www.gaia-gis.it/raster_benchmark
>
> ---------
>
> vi faccio direttamente il riassunto di quello che risulta
> dal benchmark (a beneficio dei più pigri):
>
> a) JPEG è "infinitamente" più veloce di JPEG2000
> b) anche il meno noto JPEG-LS è molto più veloce di JPEG2000
> c) per farla breve, JPEG2000 si piazza sicuramente all'ultimo
>   posto in classifica in qualsiasi contesto, e con distacco
>   veramente abissale.
>
> le compressioni basate su WAVELET paiono essere decisamente
> un'idea poco felice: questo algoritmo sofisticato e complesso
> (forse, troppo sofisticato e complesso) rimane decisamente
> "un'osso duro" anche per l'HW più recente e pimpante.
>
> tuttavia emerge anche come JPEG2000 / WAVELET recuperi poi
> alla grande in quanto offre una buona capacità multi-risoluzione,
> e quindi può fare tranquillamente a meno delle "piramidi".
>
> conclusione: il segreto sta tutto nell'implementare le
> piramidi in modo semplice ed efficiente.
> ma questo possiamo tranquillamente ottenerlo anche senza
> ricorrere alla complessità delle wavelet: basta ed avanza
> il buon vecchio JPEG, se saggiamente utilizzato in tutte
> le sue capacità, assai spesso sotto-utilizzate.
> Vedi p.es. TIFF/JPEG che ignora del tutto la possibilità di
> supportare "a costo zero" i livelli piramidali 1:2, 1:4 ed 1:8
>
> Purtroppo ad oggi nessuna implementazione open source offre
> tutto questo: se non RasterLite, ed anche RasterLite solo
> in parte.
>
> Quindi: tenetevi pronti per RasterLite v.2.0 :-)
>
> ciao, Sandro
>
>
> _______________________________________________
> Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
> [hidden email]
> 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
>

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

[a.furieri]

Mi sono accorto (in modo del tutto casuale) di
una cosa abbastanza strana:

- su http://trac.osgeo.org/proj/
  la versione corrente è la 4.7.0
- la tar ha il suffisso 4.7.0, così come la
  dir che viene estratta
- l'header-file proj_api.h riporta:
  #define PJ_VERSION 470

quindi sembrerebbe decisamente che si tratti
della v.4.7.0

tuttavia chiamando la funzione pj_get_release()
appare il messaggio: "Rel. 4.7.1, 23 September 2009"

immagino che si tratti semplicemente di una svista
innocua: mica per caso a qualcuno di voi risulta
qualcosa di più preciso che invece a me sfugge ?

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

[a.furieri]

On Tue, 27 Jul 2010 23:30:46 +0200, Simone Giannecchini wrote
> Ciao Sandro,
> comparativa molto interessante anche se un po biased imho :)
>

ma noi siamo biased per natura, vocazione e missione:
mica siamo l'ONU, che sta neutralmente nel mezzo.
direi che noi siamo dichiaratamente schierati, e dovrebbe
anche essere abbastanza chiaro da quale parte stiamo :-)

 
> - Quando parli di performance sarebbe interessante sapere se/come hai
> misurato i tempi e che librerie/sdk hai usato.
>

è tutto pubblicato sul sito:
http://www.gaia-gis.it/raster_benchmark/test_jpeg8a.html

giusto in pillole:
libjpeg, libpng, libtiff, gcc
per Jpeg2000: OpenJPEG
insomma, solo ed esclusivamente roba o.s. 100% DOC

ho accuratamente intercettato i tempi (dal clock di
sistema) immediatamente prima che iniziasse la compressione
ed immediatamente appena la compressione terminava.
tutto memory-cached, i tempi di I/O etc etc sono
accuratamente esclusi.
insomma: ho misurato i tempi nudi e crudi imputabili
esclusivamente alla libreria che effettuava il coding/encoding.


> - Quando parli di jpeg2000, bisogna tenere conto del fatto che _ogni_
> libreria open conosciuta fa veramente pena, mentre se usi kakadu o
> ecw sdk le performance possono essere diventare interessanti.
>

Non ne dubito affatto: mi fido ad occhi chiusi.
Rimangono però un paio di fatti *critici*:

a) sicuramente wavelet è un bel po' più pesante di jpeg:
   per quante magie ed ottimizzazioni tu possa usare,
   resta comunque "un bel pachiderma"
b) ho valutato ben 3 (*tre*) librerie o.s. che supportano
   wavelet [a quanto mi risulta, non ne esistono altre].
   tutte e tre mi danno più o meno (a spanne) gli stessi
   tempi ... lenti, lentissimi.
c) giusto per pignoleria: in effetti ne ho usate due sole
   (Epsilon ed OpenJpeg). La terza (JasPer) non l'ho neppure
   provata: mi è bastato vedere qualche riferimento sul web:
   sicuramente siamo sempre più o meno sugli stessi tempi.
   
Dato che si tratta di tre implementazioni assolutamente
autonome ed indipendenti (una è russa, una è canadese,
l'ultima è mezza belga e mezza perugina), non c'è nulla
che mi induca a ritenere che ci sia sotto qualche errore
sistematico (o qualche svarione di implementazione) che
possa falsare i risultati.
evidentemente, i tempi sono proprio quelli.

a meno che ... i prodotti proprietari usino qualche
"diavoleria" non documentata in letteratura, possibilmente
coperta da segreto industriale e debitamante brevettata.
Possibilissimo: vedo che attorno al Jpeg2000 c'è una
vera e propria "fioritura" di brevetti.

Ma questo taglia decisamente la testa al toro, no ?
Se le cose stanno proprio così, allora a maggior
ragione è saggio evitare di sprecare tempo e risorse
dietro ad una tecnologia (Jpeg2000) che resterà sempre
e comunque chiusa e proprietaria, almeno per i
prossimi decenni.

Tanto più se gli stessi esatti risulati (e forse anche
migliori) li possiamo ottenere comunque utilizzando
tecnologie libere e non brevettate.
almeno, a me pare così.

ciao Sandro




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

[Stefano Salvador]

Ciao a tutti,

riesumo questa vecchia discussione (che lascio per intero qua sotto
per riferimento) perché mi è capitato di dare un'occhiata al nuovo
formato proposto da Google : WEBP [1] ed ero curioso di sapere se può
essere preso in considerazione come candidato per la cartografia
raster e se qualcuno ha già fatto qualche esperimento a riguardo.

Ciao,

Stefano


[1] http://code.google.com/speed/webp/

Il 27 luglio 2010 19:18,  <[hidden email]> ha scritto:

> Saluti a tutta la lista.
>
> Se ben vi ricordate qualche giorno fa si era svolta
> in lista una discussione stimolante (ed abbastanza
> partecipata) a proposito delle tecnologie per le immagini
> raster. Il pretesto iniziale era nato dal fatto che non è
> più disponibile il supporto "free as in free beer" per gli ECW.
>
> In quella sede avevo avanzato il suggerimento di fare un
> bel benchmark comparativo, quanto meno per avere un minimo
> di solida oggettività.
>
> Ok, il benchmark ora è disponibile, e lo trovate qua:
> http://www.gaia-gis.it/raster_benchmark
>
> ---------
>
> vi faccio direttamente il riassunto di quello che risulta
> dal benchmark (a beneficio dei più pigri):
>
> a) JPEG è "infinitamente" più veloce di JPEG2000
> b) anche il meno noto JPEG-LS è molto più veloce di JPEG2000
> c) per farla breve, JPEG2000 si piazza sicuramente all'ultimo
>   posto in classifica in qualsiasi contesto, e con distacco
>   veramente abissale.
>
> le compressioni basate su WAVELET paiono essere decisamente
> un'idea poco felice: questo algoritmo sofisticato e complesso
> (forse, troppo sofisticato e complesso) rimane decisamente
> "un'osso duro" anche per l'HW più recente e pimpante.
>
> tuttavia emerge anche come JPEG2000 / WAVELET recuperi poi
> alla grande in quanto offre una buona capacità multi-risoluzione,
> e quindi può fare tranquillamente a meno delle "piramidi".
>
> conclusione: il segreto sta tutto nell'implementare le
> piramidi in modo semplice ed efficiente.
> ma questo possiamo tranquillamente ottenerlo anche senza
> ricorrere alla complessità delle wavelet: basta ed avanza
> il buon vecchio JPEG, se saggiamente utilizzato in tutte
> le sue capacità, assai spesso sotto-utilizzate.
> Vedi p.es. TIFF/JPEG che ignora del tutto la possibilità di
> supportare "a costo zero" i livelli piramidali 1:2, 1:4 ed 1:8
>
> Purtroppo ad oggi nessuna implementazione open source offre
> tutto questo: se non RasterLite, ed anche RasterLite solo
> in parte.
>
> Quindi: tenetevi pronti per RasterLite v.2.0 :-)
>
> ciao, Sandro
>
>
> _______________________________________________
> Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
> [hidden email]
> 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
>

_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
502 iscritti all'11.2.2011

[a.furieri]

On Mon, 28 Feb 2011 12:32:19 +0100, Stefano Salvador wrote
> Ciao a tutti,
>
> riesumo questa vecchia discussione (che lascio per intero qua sotto
> per riferimento) perché mi è capitato di dare un'occhiata al nuovo
> formato proposto da Google : WEBP [1] ed ero curioso di sapere se
> può essere preso in considerazione come candidato per la
> cartografia raster e se qualcuno ha già fatto qualche esperimento a
> riguardo.
>

Stefano,
per me WEBP è una novità assoluta: da una prima
veloce lettura sembra decisamente *molto*
interessante.

in pratica, da quanto ho capito fino ad ora,
utilizza un algoritmo di compressione lossy
(reversibile, senza perdita) che dovrebbe
assicurare un risparmio di spazio di circa
il 40% rispetto ad un JPEG "alta qualità".
Se è vero, è decisamente una bomba :D

Deriva direttamente da un codec video,
quindi immagino che sia anche molto veloce,
almeno in fase di estrazione.

Non mi è invece del tutto chiaro quale licenza
utilizzi: parrebbe una specie di BSD-like, ma
qua e la si accenna anche a brevetti Google.
insomma, forse questo aspetto è da verificare
più approfonditamente.

appena trovo il tempo sicuramente farò tutti
i test del caso: magari tra un po', perchè
ora sono preso dietro ad altre pippe :-)

ciao Sandro

_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
502 iscritti all'11.2.2011

[Andrea Antonello]

>> riesumo questa vecchia discussione (che lascio per intero qua sotto
>> per riferimento) perché mi è capitato di dare un'occhiata al nuovo
>> formato proposto da Google : WEBP [1] ed ero curioso di sapere se
>> può essere preso in considerazione come candidato per la
>> cartografia raster e se qualcuno ha già fatto qualche esperimento a
>> riguardo.
>>
>
> Stefano,
> per me WEBP è una novità assoluta: da una prima
> veloce lettura sembra decisamente *molto*
> interessante.
>
> in pratica, da quanto ho capito fino ad ora,
> utilizza un algoritmo di compressione lossy
> (reversibile, senza perdita)

correggo il tuo quick-lapsus: lossy == con perdita, irreversibile.

> che dovrebbe
> assicurare un risparmio di spazio di circa
> il 40% rispetto ad un JPEG "alta qualità".
> Se è vero, è decisamente una bomba :D
>
> Deriva direttamente da un codec video,
> quindi immagino che sia anche molto veloce,
> almeno in fase di estrazione.
>
> Non mi è invece del tutto chiaro quale licenza
> utilizzi: parrebbe una specie di BSD-like, ma
> qua e la si accenna anche a brevetti Google.
> insomma, forse questo aspetto è da verificare
> più approfonditamente.
>
> appena trovo il tempo sicuramente farò tutti
> i test del caso: magari tra un po', perchè
> ora sono preso dietro ad altre pippe :-)
>
> ciao Sandro
>
> _______________________________________________
> Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
> [hidden email]
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> Non inviate messaggi commerciali.
> I messaggi di questa lista non rispecchiano necessariamente
> le posizioni dell'Associazione GFOSS.it.
> 502 iscritti all'11.2.2011

_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
502 iscritti all'11.2.2011

[a.furieri]

On Mon, 28 Feb 2011 13:03:50 +0100, andrea antonello wrote
> > in pratica, da quanto ho capito fino ad ora,
> > utilizza un algoritmo di compressione lossy
> > (reversibile, senza perdita)
>
> correggo il tuo quick-lapsus: lossy == con perdita, irreversibile.
>

OOPS, sorry :-(
maledetta fretta: ok è effettivamente lossy;
quindi resta tutta da verificare la qualità
reale rispetto al buon vecchio JPEG
Andrea, grazie per avere segnalato il mio
precedente "farfallone"

ciao
Sandro

_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
502 iscritti all'11.2.2011