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 [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
