Archive for luglio, 2011

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).

8 luglio 2011

Calise

Breve articolo per dare due comunicazioni di servizio:

ho aperto un blog wordpress in inglese su sourceforge per permettere ai non italofoni di seguire lo sviluppo, in maniera non tecnica, di camsensor.

Cercando in internet ho aihmè visto che camsensor è già marchio registrato e, nonostante per un uso privato e sconosciuto nessuno si arrabbi, se il progetto cresce e non affonda, non vorrei mai rubare pubblicità ad altri (magari che fanno cose simili). Nelle prossime settimane, quindi, aggiornerò tutta la pagina del progetto su sourceforge per cambiare il nome in calise (Camera Light Sensor), attualmente ho già caricato tutto il codice aggiornato con il nuovo nome su svn.

Visto che ci sono elenco alcune delle aggiunte attualmente caricate su svn:

  • nell’interfaccia interattiva ho aggiunto il tasto “a” per cambiare “al volo” il parametro logdata, in pratica, premendo “a” comincia a mantenere i valori oltre quelli che rientrano nella media, ripremendolo, si ferma, questo, quante volte si vuole, una volta che viene richiesto di esportare, verranno esportati anche tutti i pezzi registrati (in realtà questa cosa presenta un “bug” per cui registra/esporta tutto tranne i valori mediati, a meno che non si esporti mentre logdata è attivo)
  • ho sistemato la gestione dei segnali per cui ora reagisce (come doveva essere in principio), senza errori di sistema, ai segnali POSIX stop/continue e terminate, interrupt, ovvero rispettivamente SIGTSTP/SIGCONT e SIGTERM, SIGINT

Ho provato a cercare “clues” (indizi) riguardo all’interfaccia D-bus per il controllo della retroilluminazione in maniera meno “barbara”, ma da quando hal è diventato deprecato, sembra che nessuno si sia messo a scrivere mezza riga sulla retroilluminazione (e su molto altro in realtà) e quindi avrei bisogno di tanta pazienza, anche se, sapendo che dopo protocolli e policy varie alla fine fa esattamente quello che fa il mio programma, non vedo tutta questa urgenza in questo senso.

Altra cosa è l’interfaccia grafica… il modello è preparato, grossomodo le linee guida ci sono, unica cosa, devo informarmi sull’implementazione visto che una “prova veloce” (copia e incolla sperando che vada), pur andando non permetteva alle due parti (GUI ed processo) di comunicare fra loro.

A tutti i miei lettori (so che sono un numero naturale inferiore a π) chiederei se il nome calisep piace o risulta poco appetibile, ci sono in realtà poche alternative sensate, ma andando sull’irrazionale si può esaggggerare senza troppi timori.
Se ci sono consigli commentate o, se mi conoscete e vi vergognate delle idee che vi sono venute in mente, mandate una mail.

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%.