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

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

29 giugno 2011

Videogiochi del nuovo millennio

Non posso fare a meno di scrivere due righe di auto-risposta ad una domanda che a me sorge spontanea quando vedo il gameplay di almeno il 99% dei videogiochi (e anche giochi ‘fisici’) in commercio: Perché non riesco ad avvicinarmici?

Quasi in ogni opera videoludica a cui ho modo di approciarmi – con rarissime ma notevoli eccezioni – percepisco la sensazione che la giocabilità (gameplay appunto) sia stata sacrificata in termini di tempo e cura, per un apparenza grafica allettante, dettagliata, sfumata, bagliorizzata, etc, con degli estremi che diventano sinceramente così pieni di effetti da risultare quasi inavvicinabili. Certo, è possibile che il mio approccio sia ormai vecchio e sorpassato. Allora, perché prendendo in mano un prodotto degli anni novanta, giusto per non andare troppo sotto a livello grafico (anche se gli anni ottanta colori esclusi, non si perdono niente), riesco fisicamente a giocare e invece con giochi degli ultimi 6-7 anni no? Cosa è cambiato così radicalmente negli ultimi anni da segnare (almeno per me) un salto incolmabile?

IoriRugal

Sicuramente la componente personale nel mio caso un po’ conta, visto che sono molto legato ad uno dei genere principi degli anni novanta (i picchiaduro), ma non può essere solo quello. Ad esempio, chi non prova soddisfazione a giocare a tetris? Tutti vero. Bene, chi non prova soddisfazione a giocare ad una app clone con grafica rifatta o simili? Molti abbandonano dopo 1-2 ore di utilizzo totali l’applicazione/gioco perché in quel breve lasso di tempo è già scaduta.

Purtroppo la logica commerciale odierna punta a trailer mozzafiato, grafica accattivante, etc, con il solo scopo di attirare più clienti possibile (e magari di tutte le età), perdendo totalmente di vista la qualità del gioco. Un’altra caratteristica che via via si è persa con il passare del tempo è la semplicità (da non confondere con basicità, banalità). Secondo me non è vero che più funzioni vengono inserite nel gameplay, più il gioco è bello, anzi, in molti casi, opzioni studiate ad arte per essere facilmente assimilabili e allo stesso tempo permettere una longevità di gioco estrema. Per fare un esempio concreto in questo campo vorrei citare una perla di inizio millennio che è DiabloII della Blizzard.

E qui torniamo al punto di partenza, quanti giochi degli ultimi 6-7 anni hanno o prevedono un futuro prospero, si contano sulle dita di una mano? Se guardiamo invece quelli che tuttora sono molto giocati e amati del decennio precedente troviamo parecchi più titoli (non bastano né piedi né mani per contarli).

Minecraft

Ora, per concludere, è giusto andare avanti così o a breve ci sarà una ventata di cambiamento? Chi può dirlo, intanto Minecraft che si è scostato fortemente dagli schemi commerciali in favore della qualità è stato ampiamente premiato, vedremo se si rivelerà un guizzo nel mare piatto o se scatenerà una bella onda di cambiamento.

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/

21 giugno 2011

Camsensor in beta

Ieri notte ho deciso che il progetto aveva raggiunto una maturità tale da poter passare in fase beta. Il programma così come è ora ha tutti i punti che in fase pre-alpha avevo previsto di raggiungere.

Scrivo solo ora perché volevo poter annunciare di più di un semplice passaggio da alpha a beta. Ho delineato infatti i punti da raggiungere per la versione 0.0.2 che mi aspetto di raggiungere a breve:

  • Distribuzione per le maggiori distribuzioni linux
  • Integrazione completa con il sistema xdg_dir per i percorsi di sistema
  • Miglioramento della chiarezza e riorganizzazione grafica nei passaggi di calibrazione

Il primo punto degli obbiettivi per la versione 0.0.2 è stato raggiunto, il codice attualmente caricato su svn infatti è compatibile con tutte le distribuzioni debian-based (debian,ubuntu,…) e con tutte le RPM-based (red-hat,Fedora,…) nonché con Archlinux e Gentoo. In realtà ho parlato di compatibilità, perché ho avuto modo di testare effettivamente il funzionamento solo su Archlinux (XFCE), Fedora 14 (GNOME) e Ubuntu 11.04 (Unity). Ma a rigor di logica dovrebbe essere portabile in ogni distribuzione basata su kernel 2.6.
Il secondo punto sarà meno complesso del primo, ma richiederà comunque del tempo (soprattutto per il testing), in quanto ad ogni cambiamento di una variabile per le configurazioni, devo testare che non si sballino riferimenti.
Il terzo punto a livello di applicazione è veloce e semplice, ma richiederà tempo per pensare ad un layout efficente e allo stesso tempo chiaro per tutti.

La versione beta è caricata su sourceforge e disponibile all’indirizzo http://sourceforge.net/projects/camsensor/files/camsensor-beta/0.0.1/camsensor-0.0.1.tar.gz ha un bug per quanto riguarda la localizzazione, quindi per evitare errori, bisogna cambiare riga 39 del file camsensor.py così:
gettext.install(‘camsensor’,unicode=False)
‘nella versione originale unicode e impostato su True’

Spero di poter dare presto nuove nuove 🙂

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

1 giugno 2011

E dopo qualche ora di studio…

E dopo qualche oretta di studio cosa c’è di meglio di una morbida, sugosa, nutriente e sana pizza?

Pizza fatta in casa

Avevo diligentemente preparato la pasta tornato dall’utilissima visita-seminario all’INSIE di Udine ieri mattina (che mi aveva fatto venire una fame assurda dato che non avevo fatto a tempo a fare colazione).
Così, dopo qualche ora di studio ho ben farcito un buon terzo di pasta e dopo una ventina di minuti abbondante di forno… magia.

Avevo proprio voglia di pizza!

Faccio notare la genuinità… pizza con pasta fatta in casa, sugo di pomodoro fatto in casa, mozzarella fresca (non hanno senso di esistere le mozzarelle da pizza), pomodorini datterini a quarti, rucola fresca e GranaPadano a scaglie.

Chiedo scusa se in questo periodo lo sviluppo di camsensor è un po’ fermo, ma devo occuparmi degli esami per il momento, in ogni caso tutte le cose vitali sono sistemate. In ogni caso su subversion dovrebbero già esserci due o tre revisioni successive alla versione alpha12 se volete provare qualcosa di nuovo (non mi pare in realtà ci siano nuove features, ma solo bugfix)

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