La luce delle api e i colori di compiz-fusion/2

(qui la puntata precedente)

Finalmente convinco Edo (quello, per intenderci, che usava pekwm...) a provare compiz e in particolare il Tabbing windows. Ne rimane, non dico entusiasta, ma almeno soddisfatto e conviene con me che, se non tutte, alcune (molte, direi io) funzionalità di compiz non sono solo un fattore estetico ma rappresentano degli strumenti realmente utili. Un'altra di queste funzionalità che piacque ad Edo è Negative, che "negativizza" le finestre:

...leggi tutto

hronir: e per cosa lo usi?
   Edo: per dire, skype 
   Edo: per wikipedia
   Edo: il nero su bianco diventa bianco su nero
   Edo: e per me e' molto meglio
   Edo: t'ho mandato uno screenshot
hronir: figo :)
   Edo: molto piu' riposante
hronir: anche secondo me
   Edo: ach
   Edo: non dovro' abituarmi a compiz
   Edo: sul mio portatile non ce lo posso avere!
hronir: vedi che anche tu rischi l'assuefazione?
hronir: ci sono effetti grafici carini, ma molti sono proprio... UTILI!
   Edo: considero utile:
   Edo: 1) window tabbing
   Edo: 2) neg
   Edo: il resto sono stronzate...

ok, ok, censura.

Come potete immaginare dalla tonalità di questo blog, anch'io ho sempre pensato che, su schermo, testo bianco su fondo nero sia più riposante dell'opposto. E proprio nel gestire il blog, per adattare al suo sfondo nero immagini "normali" su sfondo bianco, mi era già capitato di giocare con l'inversione fotografica. Invertire un'immagine permette di scambiare il bianco col nero, ma ha l'effetto collaterale di invertire anche i colori: il rosso diventa azzurro (ciano), il verde diventa rosso (magenta), il blu diventa giallo e così via. Ma smanettando con GIMP ero riuscito a trovare una specie di compromesso in un'ulteriore trasformazione dell'immagine da applicare dopo l'inversione, e cioè una rotazione di 180 gradi del parametro di tonalità (hue), che corrisponde, appunto, ad'ulteriore inversione "puramente cromatica". Tanto per capirci, un'immagine originale come questa diviene così dopo una semplice inversione, e così se si applica ancora un'inversione di tonalità.

hronir: oltre al neg ci vorrebbe una rotazione di 180 gradi nell'hue
hronir: cosi' i colori rimangono simili all'originale
hronir: ma non credo esista questa feature :(
   Edo: cosa fa?
hronir: prova a giocare con un'immagine (non una foto, meglio uno screeshot) con GIMP 
hronir: e applica il negativo e poi uno shift di 180 gradi nell'hue
hronir: l'effetto e' quasi di aver scambiato il bianco col nero
hronir: lasciando i colori piu' o meno uguali
   Edo: mah, no
   Edo: il bianco mi rimane bianco
hronir: no, prima fai il negativo
hronir: e poi gira l'hue
   Edo: aaaaaaa
hronir: l'hue non cambia bianco/nero
   Edo: e' vero
   Edo: non dovrebbe essere impossibile
hronir: eh, infatti, non dovrebbe essere complicato
hronir: bisognerebbe trovare un qualche sito per i feedback per compiz
   Edo: sembrerebbe esserci un plugin che cambia i colori
hronir: come si chiama?
   Edo: si chiama color filter

Ora, color filter sembrerebbe proprio quel che fa per noi, solo che non ha, fra i filtri disponibili quello per le rotazioni dell'hue. Leggo che si possono aggiungere filtri personalizzati, ma bisognerebbe mettersi a imparare l'OpenGL fragment program, una specie di assembler per schede grafiche. La prima idea, ovviamente, è quella di cercare qualcuno che abbia già scritto un simile filtro, ma google sembra non portare ad alcun risultato. Mi toccava davvero imparare l'ARBfb1.0? Ora, imparare è una parola grossa: sarebbe bastato trovare un filtro qualsiasi e provare a modificarlo. I filtri disponibili con compiz si trovano in /usr/share/compiz/filters/ e dando un'occhiata a filtri come swap-green-blue o green-gray sembra che tutto stia nel giocare con i "campi" rgb della texture, scambiandoli o invertendoli.

Purtroppo, però, non esiste alcuna semplice operazione di shuffle delle componenti RGB che corrisponda ad un'inversione dell'hue e anzi la relazione fra RGB e HS* è espressa con un sacco di condizionali... E questa era una brutta notizia, perchè la mia idea era semplice: trasformare le componenti red-green-blue del colore in componenti hue-saturation-value, invertire la componente hue (o ruotarla di 180 gradi) e riconvertire in red-green-blue. Ma per implementare in assembler quelle formule piene di casistiche non mi sarebbe bastato usare qualche semplice operazione matematica. Testardo, provo a scrivere un codice lunghissimo, implementando i salti in maniera "acrobatica" usando le istruzioni SLT, KIL e CMP... ma ovviamente appena provo ad aggiungerla ai filtri attivi di compiz mi crasha non X ma tutto il computer!

Tutto sembrava perduto quando, serendipicamente, trovo La Soluzione Semplice. Nonostante ovunque, su internet, le trasformazioni ufficiali RGB-HSV sono quelle riportate da wikipedia, e nonostante ovunque, su internet, i mille e mille piccoli codici di esempio nei linguaggi più disparati traducono quelle trasformazioni in maniera pedissequa, con i corrispondenti costrutti if-case che tanto mi hanno fatto impazzire con ARBfp1.0, la realtà è che... esistono trasformazioni lineari fra RGB e HSV!!!

A quel punto tutto è in discesa, e infatti in una manciata di minuti metto insieme non più di una dozzina di linee... et voilà, il gioco è fatto.

(to be continued)