Posts tagged ‘open-source’

27 agosto 2011

Calise 0.0.5

Dopo una lunga parentesi pseudo-vacanziera a Jesolo lido intrisa di studio e attività in genere (molto diversa dalla classica vacanza marina sotto l’ombrellone per capirci), scrivo qualche riga sulla nuova versione di Calise (0.0.5) che porta con se qualche cambiamento soprattutto in termini di stabilità.
Per spiegazioni squisitamente tecniche rimando al blog di Calise in inglese all’indirizzo: http://sourceforge.net/apps/wordpress/calise/.

In generale ho eccettato degli errori (in particolare un blocco che si imponeva arbitrariamente qualche volta ad opera della libreria camera di pygame) e stabilizzato/pulito il codice con cambiamenti a volte anche radicali.

Procederò ora verso la versione 0.0.6 dove faciliterò e migliorerò la velocità con cui si calibra nel caso in cui la videocamera usata sia già presente in uno dei profili utente.

L’obiettivo più in là poi è sempre quello: un ambiente GUI confortevole, da cui accedere a tutte le opzioni del programma (calibrazione compresa).
Tuttora sono indeciso fra una gui in Qt ed una in Wx…

Nel frattempo mi concentro per bene nello studio.

Annunci
18 luglio 2011

Calise 0.0.4

Non ancora pubblicato su Sourceforge per motivi che spiegherò fra poco, è ora disponibile la versione 0.0.4 di Calise.
Lo potete reperire temporaneamente qui: http://smilzoboboz.altervista.org/tmp/calise-0.0.4.tar.gz
Per la verifica del checksum:

MD5: 267a33b907ed433a4d9c267849c415c0
SHA1: a45a3f0769da945d6d752eec141b05a5b3fb295a
SHA256: b701cd852120c3ccd42a611a136daefb75e54296017e4145eda5625ae65c57d9

Il cambiamento di nome da Camsensor a Calise sta occupando più tempo del previsto e al momento il sito “ufficiale” su Sourceforge è da considerarsi down (come d’altro canto il blog ufficiale). Devo dire che questo mi ha creato e peraltro mi sta ancora creando qualche problema nella pubblicazione del pacchetto AUR per archlinux, ma ora la situazione è stabile.

Ho già fatto dei cambiamenti disponibili su svn (tarball disponibile qui: http://calise.svn.sourceforge.net/viewvc/calise/?view=tar) di tipo qualitativo e visuale.

La GUI attualmente copre solo la parte di esecuzione, ed è per questo che ho deciso di non avanzare alla serie 0.1.x. Molto probabilmente, in questo periodo di vacanza che mi aspetta mi concentrerò su una versione GUI per la calibrazione ed eventuali bug che mi vengano segnalati. Fatto questo e diversi test su varie distribuzioni, rilascerò la versione 0.1.0 con annessi pacchetti AUR, DEB, RPM (se ci riesco).

5 luglio 2011

Camsensor 0.0.3 beta

Poche ore fa mi sono reso conto di aver soddisfatto i punti che volevo per la nuova versione e quindi eccoci qua: camsensor 0.0.3 beta è ora disponibile.
Questa versione corrisponde alla r81 su svn. link: camsensor

I cambiamenti in questa versione sono:

  • esecuzione in un processo (thread) separato, tuttavia non demone; dopo una attenta analisi delle problematiche legate al fatto di tenere occupata una videocamera, ho deciso che un demone non poteva essere la soluzione più corretta, quanto lo era invece un programma non invasivo da poter facilmente “mettere in pausa”;
  • aggiunta di una interfaccia interattiva in stile mplayer per mettere in pausa, riprendere, terminare ed esportare i dati del programma. Sempre a livello grafico, ho aggiunto qualche info sui parametri in uso e ridotto ad una riga che si autoaggiorna l’output del programma. NON ho usato curses per vari motivi non del tutto condivisibili (avrei dovuto ma preferivo un metodo di output più lineare dal punto di vista visivo);
  • come già accennato, per integrare le due modifiche precedenti, ho riordinato il programma e spostato anche la parte di calcolo dello step e quanto ad esso collegato in libreria, per info su eventuali implementazione fate riferimento alla libreria stessa che è ampliamente commentata; inoltre ho messo sotto classe processata separatamente (threaded) la parte esecutiva del programma, in pratica tutto ciò che viene dopo l’inizializzatione di argomenti e parametri;
  • ho pulito il codice – in diversi casi anche intensamente e non senza difficoltà – e l’ho adeguato, a meno di sviste, alle direttive opzionali PEP-8;
  • infine, anche se non era programmata, ho fatto una piccola ma fantastica modifica/aggiunta per cui, dando l’opzione “–logdata”, il programma tiene in memoria ogni dato ottenuto dall’avvio, per cui, durante l’esecuzione, con il tasto “e” viene esportato l’intero parco dati in formato universale csv (comma separeted values). L’unica pecca di questo è che l’intero ammontare di dati viene mantenuto in RAM, per cui dopo diverse ore (direi più di un giorno) il consumo di risorse risulta considerevole. Questo risulta di grande utilità in ambito sperimentale, ad esempio per monitorare l’intensità di luce durante l’arco della giornata, o gli sbalzi della stessa o in generale qualsiasi genere di analisi fattibile con il livello di luce esterna (o del monitor). Se “–logdata” non è presente, il programma esporterà solo i dati mantenuti per fare la media dei valori.

Qui potete vedere un esempio di grafico ottenuto dopo qualche ora di utilizzo (dalle 17.45 alle 21.00):

Graph

Un bel grafico… La linea rossa rappresenta gli step di retroilluminazione (10 nel mio caso, da 0 a 9) e invece i punti blu sono TUTTE le catture da webcam normalizzate rispetto alla luminosità dello schermo. Si vedono due punti di discontinuità poco prima delle 18.00 e poco dopo le 18.30 (probabilmente sono andato via per mezz’oretta e il programma ha reagito al cambiamento drastico), ma soprattutto la precisione non invasiva per cui, da solo ha regolato gradualmente la retroilluminazione soprattutto nel periodo 20.00/21.00.
Da notare come la cattura della luminosità dalla webcam frontale sia veramente difficile da gestire per la sua variabilità (giustamente, voi davanti allo schermo vi muovete e d’altro canto la webcam prova in continuazione a bilanciare il bianco), da qui il tempo che ci ho messo per elaborare un algoritmo che eliminasse il più possibile, senza spendere troppo in termini di cpu, il disturbo ambientale.
Non ho registrato in questo grafico, il sistema di bloccaggio che evita che succedano cambiamenti di retroilluminazione consecutivi entro i 30 secondi (in più punti di questo grafico, ad esempio, sarebbe entrato in funzione).
In questo grafico ho usato due dei dati a disposizione, ma ci sono infinite possibilità di utilizzo per questo strumento.

Gli obiettivi per il futuro rilascio – la fantomatica versione 0.1.0 – in realtà al momento si riducono ad uno solo (che oltre tutto è in uno stato piuttosto avanzato), ovvero, una GUI (interfaccia grafica) attraverso la quale interagire col programma al pari, se non meglio che con l’interfaccia testuale. In realtà, l’interfaccia c’è già, e in qualche modo anche funzionante, ma ci sono delle barriere strutturali (del mio programma così com’è ora) che mi impediscono di sviluppare al meglio le sue potenzialità.
La mia intenzione originale era di inserire nella GUI, oltre ai bottoni per il controllo remoto (fatto), la possibilità di lanciare un terminale grafico con lo storico entro la media dell’output (fatto) e/o un grafico sempre con lo storico entro la media di una o più caratteristiche a scelta (da studiare, e parecchio)
In pratica, sarà “un solo cambiamento”, ma comunque valido per decidere addirittura di passare dalla versione 0.0 alla 0.1 (non mi aspetto di venirne fuori prima di settembre).

Piccola nota purtroppo, una regressione di performance in termini di tempo del processore dell’8~10% (in realtà attesa, viste le aggiunte), quindi sulla mia macchina è passato da poco più dello 0.8% a poco meno dell’1.0%.

27 giugno 2011

Seconda beta per camsensor (0.0.2)

Pochi giorni fa ho rilasciato la seconda beta per il programma.
Non ci sono sostanziali cambiamenti rispetto alla 0.0.1, ma in questa versione ho migliorato l’approccio visivo – in particolar modo della parte di calibrazione che non era molto intuitiva nella versione precedente – ed ho aggiunto un’override per i segnali di sistema per fare in modo di spegnere, uccidere mettere in pausa e riprendere il programma dall’esterno.

Tutto quello che c’è ora, almeno a livello di meccanismo interno, con ogni probabilità rimarrà pressoché immutato nelle versioni future, gli unici cambiamenti possono essere solo migliorativi in termini di consumo di risorse e/o usabilità a livello libreria. In ogni caso farò in modo di non stravolgere nessuna delle funzioni in libreria.

Per la versione 0.0.3 gli obiettivi sono:

  • demone eseguibile indipendentemente a livello utente
  • backend (testuale ma forse anche grafico) per controllare l’esecuzione
  • aggiunta in libreria di tutto ciò che è iterabile
  • pulizia generale del codice e adesione alle regole PEP 8.

In realtà ho detto 0.0.3 perché su svn è questa la versione che ho dato temporaneamente, ma se il backend funziona a dovere penso si possa parlare di 0.1.0. In ogni caso non vedo futuro per una 0.0.4…

Come al solito trovate versioni beta stabili e sorgente su http://sourceforge.net/projects/camsensor/

10 giugno 2011

I giorni di pioggia non fanno poi così male

Questi ultimi giorni di pioggia mi hanno portato a scoprire un serio bug (o quasi) su camsensor che non impediva il cambio continuo del valore di retroilluminazione in caso di valori di luce esterna “stabili” nell’intorno di un salto (15%, 25%, 35%, …).

La scala percentuale della luminosità ambientale infatti non è lineare – in realtà è quasi logaritmica – e quindi le normali oscillazioni del valore di luminosità che si hanno a causa dei limiti materiali (la webcam e i normali movimenti dell’utente) provocano delta sulle misure notevoli. Se per disgrazia il cielo temporalesco, ovvero 50-60% di luminosità (con la pendenza della funzione che comincia a farsi sentire), diventa più/meno annuvolato rapidamente, ci si trova nella brutta situazione di avere la retroilluminazione che passa da passo precedente a successivo e vice-versa ad ogni cattura (ogni 0.5 secondi… disturbante)

Poiché, come dicevo uno o due articoli fa, ormai sono totalmente dipendente da questa mia applicazione, il doverla escludere anche solo per brevi periodi di tempo (altra grossa feature da implementare in futuro) non mi dava pace. Ho pensato un pochetto e alla fine ho adottato questa banale soluzione:
appena cambia la retroilluminazione parte un conteggio a 60 secondi, prima dello scadere del conteggio viene inibita l’azione di scrittura dei valori di retroilluminazione, a meno che non si tratti di un cambio repentino (classica luce accesa/spenta) che è ininfluente all’atto del conteggio. Ci tengo a precisare che i valori mostrati nei log non risentono dell’inibizione e quindi sono “reali”, non falsati.

Poiché queste modifiche potrebbero ledere in maniera consistente la risposta del programma nel primo minuto di avvio (per ora i test che ho effettuato non hanno presentato anomalie), come le altre dalla revisione 19 in poi per ora rimangono solo su subversion.
Ormai pensavo di pulire qualcosina sul codice, ottimizzare questa nuova feature e quindi rilasciare una nuova alpha. Il tutto, tra esami e resto penso mi occuperà un mesetto.

Per tutti quelli che non hanno pazienza (io consiglio CALDAMENTE di usare la versione sperimentale su subversion…) il link è il solito: camsensor/code

19 maggio 2011

Camsensor 0.0.1-alpha11

Ieri sera ho finalmente terminato la completa riscrittura del codice in forma ad oggetti. Mentre analizzavo e scrivevo codice mi sono accorto di quanti bug e funzioni ridondanti si possano ottenere rattoppando/aggiungendo senza pianificare prima il risultato finale.

schermata camsensor con opzione debug

Per i curiosi o per chi volesse collaborare alla scrittura, attualmente il codice è caricato e continuamente aggiornato via subversion su Sourceforge, per scaricarlo e analizzarlo/modificarlo voi stessi (dopo in caso scrivetemi o addirittura inviatemi patch per le cose che vorreste cambiare/aggiungere) basta che installiate subversion e lanciate:
svn co https://camsensor.svn.sourceforge.net/svnroot/camsensor camsensor

Dapprima il codice può sembrare complicato, ma in realtà il vero lavoro viene delegato a una o due classi specilizzate.
Ora i primi obbiettivi in vista sono: la gestione di profili personalizzati e la totale indipendenza da input dell’utente esterni alla calibrazione (mediante l’uso di profili), così da poter girare in background come demone di sistema.

Devo dire che il progetto mi sta sempre più prendendo e, nonostante fosse partito così per mettere un’idea in piazza, sta prendendo una sua forma.
Ultima nota, ho aggiornato appena prima la licenza del programma, ora è ufficialmente rilasciato sotto GPLv3.

Nota: io ora uso il programma all-day-long e non riuscirei a farne a meno, oltre al tramonto e annuvolamenti vari, lo trovo utilissimo anche quando di notte accendo o spengo la luce. La vita non sarebbe più la stessa senza

20 aprile 2011

Camsensor alpha

Annuncio con immenso piacere di aver cominciato un progetto che avevo intenzione di fare da parecchio tempo, o meglio, che come le altre decine di piccole idee avevo abbozzato e poi abbandonato per quasi un anno.

camsensor logoIl progetto in questione è camsensor (http://sourceforge.net/projects/camsensor), un programma, ridotto ad un singolo script in python, che permette di usare la normale webcam del laptop, o una dedicata (con piccoli aggiustamenti alla scala di riferimento) come sensore di luce.
Il progetto dipende solo da python e dai moduli opencv (o cv) di python.
Attualmente, la versione è appena passata da pre-alpha ad alpha ed ha queste caratteristiche:
– Cattura di un immagine dalla webcam
– Calcolo della luminosità media sulla base di una versione scalata 8×6 px dell’immagine catturata
– Confronto fra la retroilluminazione dello schermo attuale e quella consigliata per l’ambiente (per sistemi congruenti al mio laptop)
Giusto stamattina ho velocizzato le operazioni di calcolo (non che ce ne fosse troppo bisogno) eliminando due passaggi ridondanti.

Inizialmente pensavo di tenere per me lo script (come ho quasi sempre fatto finora), ma data la bellezza/pulizia del risultato finale ho pensato di renderlo pubblico, così – spero – avrò modo di imparare a scrivere sempre meglio grazie ai consigli di chi ne sa più di me e dà un occhiata al codice.

14 aprile 2011

Perché dire no alla pirateria

La pirateria è una cosa molto sbagliata. Per me dovrebbe essere permesso lo scambio di contenuti protetti solo su canali privati (come si faceva una volta scambiando il CD/cassetta). Vedo di spiegare.
Chiunque mette in un blog, forum, torrent o comunque condivide su rete p2p dei contenuti protetti da copyright, PUBBLICA del materiale non suo senza chiedere autorizzazione ai detentori dei diritti.
Pubblicare è una cosa molto seria e, sinceramente, è stata presa troppo sotto gamba.
Illustro molto brevemente come la vedrei io in materia di copyright per un giusto riconoscimento agli autori senza limitare troppo la libertà di scambio dei cittadini:
– pubblicare in qualsiasi forma materiale la cui licenza non lo permetta è pirateria
– condividere fisicamente o digitalmente tramite canali privati (email, connessione diretta p2p) è lecito purché non si tratti noleggio (se non previsto dalla licenza)

Come molti della mia generazione, anni fa (ancora minorenne) spesso ho “scaricato” giochi, musica o film, senza curarmi più di tanto delle conseguenze delle mie azioni o delle responsabilità che avevo, perché “tanto lo facevano tutti”. Solo dopo essere “entrato” nel mondo open-source ed aver capito la grande battaglia che viene portata avanti contro la chiusura, mi è stato chiaro come sia sbagliato combattere con la violenza – in questo caso pirateria – le cose che non ci piacciono.
Se i film, i giochi o la musica, ma anche il software in maniera differente, costano troppo, è sbagliato usarli lo stesso “rubandoli”, è giusto non usarli e far così capire ai vertici che il prezzo è troppo alto.

Ci sarebbero così tante cose da dire che mi stanno venendo in mente, comportamenti sbagliati che vengono legittimati dalla routine e dall’impossibilità di controllare senza privare.

Faccio un esempio che riguarda me stesso. Io amo il jazz, ma come chiunque, da teenager ho ascoltato musica pop/rock di ogni genere, senza aver mai comprato un solo cd, certo, all’inizio erano dischi prestati da amici/parenti digitalizzati (cosa che io ritengo legittima), ma poi ho scaricato musica da internet. Qualche anno fa (quando ho capito il movimento open-source) mi sono reso conto di aver avuto della musica che – oltre a non essere stata ascoltata da anni – era pirata, salvata sul mio hard-disk e ho fatto questo pensiero: ma vale la pena possederla? Infatti nella foga di possedere non mi ero reso conto che quella musica, come del resto dei film o dei videogiochi, non aveva senso di essere posseduta.

Esistono i trailer dei film, le presentazioni dei dischi e le versioni dimostrative dei videogiochi proprio perché ci si faccia un idea del prodotto ed eventualmente, a “sangue freddo” lo si acquisti.
Se la musica o il film di turno non vale la pena di essere comprato, grazie alla pubblicità – per la musica su internet, per i film in televisione – è possibile ascoltare/guardare senza pagare, legalmente. Si tratta solo perciò di avere la pazienza che o che il prezzo scenda, o che venga distribuito gratuitamente.

Piccola eccezione che vale la pena di essere menzionata è il fansub

Vedrò di sviscerare tutto il guazzabuglio che ho in testa su questi argomenti che mi stanno parecchio a cuore e scrivere più chiaramente, espandendo la scrittura nei punti più importanti.