l'esposizione multipla come filtro antirumore

Premessa
La K7 non è un mostro ad alti ISO, anzi...
Già ad 800ISO ha una grana visibile, ed aumentare la sensibilità oltre 1600ISO comporta una quantità di rumore negli scatti spesso inaccettabile.
Gli algoritmi di riduzione del rumore sono più o meno avanzati, ma danno luogo ad una inevitabile riduzione nel dettaglio. Quello presente in camera, poi, è veramente poco efficace.
 Inoltre, partendo dal file .pef, si nota al crescere degli iso una riduzione dell'intervallo dinamico già di per sé non eccezionale (le varie k 5 / 30 / 01 hanno ben altro comportamento!), ed una crescente difficoltà nel trattare il file con i vari software per la demosaicizzazione.
Cosa si può fare in queste situazioni?
Se ci sono soggetti in movimento poco o niente. In quei casi bisogna andare di flash, se la cosa è permessa ed il tempo di sincronizzazione a 1/180 non è troppo lento.
Con i soggetti immobili si può sfruttare un tempo un po' più lungo, ma talvolta questo tempo diventa una esposizione lunga secondi e secondi, e allora il rumore termico rientra in gioco...
ma... un momento!!!

Lo stacking, dall'astronomia alle foto "quotidiane"
In spettroscopia, con l'avvento delle tecniche di accumulo, si è avuto un miglioramento del rapporto segnale/rumore, che aumenta proporzionalmente alla radice quadrata del numero di misure.
L'idea di prendere un sensore, anzi un pixel, registrare più volte nel tempo il segnale su quel pixel e poi mediare il risultato è una tecnica già in uso ad esempio nella spettroscopia di emissione con plasma ad argon o nell'NMR, ed ha portato ad un aumento spaventoso di prestazioni e di velocità. Anche in fotografia può essere  una soluzione.
L'idea non è originale, perché in fin dei conti i software di stacking in astrofotografia fanno già una cosa del genere.
Però la k7 offre un vantaggio competitivo rispetto ad altre macchine Canon-nikon-sony: è possibile effettuare l'esposizione multipla, fino a 9 scatti, ed avere il raw "finale".
Di fatto, si unisce la qualità del file Raw alla tecnica di accumulo, evitando il passaggio per un jpg, la successiva postproduzione in Gimp/photoshop, e la perdita qualitativa risultante.

Vediamo come va questo "trucchetto" in pratica.

Per provare "al volo" la mia teoria ho preso la k7, ho montato il 18-135 wr impostato a f8 e 35mm. Ho provato quest'ottica a quella focale e quel diaframma perché ha un comportamento buono, e perché ce l'avevo già montata sulla macchina fotografica! :D
Importante: bisogna ricordarsi di togliere lo shake reduction, la correzione in camera dei parametri dell'obiettivo, e la correzione automatica delle ombre o delle alte luci.

Ho fatto 3 "scatti":

1. uno scatto a 1600 ISO, 1/3 di secondo
2. tre scatti a 400ISO, 1/3 secondo, modalità esposizione multipla, senza correzione automatica dell'esposizione
3. quattro scatti a 1600ISO, 1/3 secondo, modalità esposizione multipla con correzione automatica dell'esposizione

La seconda e la terza immagine differiscono in termini di "costruzione" del segnale. In un caso si prendono tre segnali "puliti" e se ne fa la somma,  nel secondo caso si prendono tre segnali "sporchi" e si fa la media.
Ho scattato in modalità RAW+JPG, per cui ho ottenuto comunque 3 raw trattati con photivo in modo da avere tre immagini con esposizione sostanzialmente uguale. In nessuna delle immagini ho utilizzato  filtri per la riduzione del rumore, o particolari "esaltatori" di immagine, e la differenza di "trattamento" consiste solo in una leggera variazione della curva di L nel caso 2 rispetto agli altri casi.

Vediamo gli scatti. Per chi vuole, con il tasto destro può scegliere di visualizzare le immagini e/o salvarle sul disco per poterle comparare al meglio.

Primo caso: immagine a 1600ISO
Questa è l'immagine al 50% di ingrandimento

Il rumore è abbastanza evidente anche senza voler fare i pixel peeper.
Andando al 100% su due dettagli, si nota il "brutto" rumore della k7.

Direi che i commenti sono superflui.

Caso 2: stacking su più foto scattate a sensibilità inferiore
Scattando 3 immagini di seguito e "sommando" i risultati si ottiene qualcosa di molto meglio rispetto ad uno scatto singolo ad alta sensibilità. Il rumore è decisamente inferiore, anche nelle zone scure, il file è decisamente più "lavorabile", e si ha un piccolo incremento di dettaglio e di range dinamico. Ad esempio, sulla scatoletta celeste appare la texture bianca, e sull'illustrazione di Shrek si riconoscono meglio i personaggi.

 
Terzo caso: 1600ISO mediati su quattro scatti
Questo caso è quello da cui sono partito come ragionamento.
Di fatto una media del genere è una specie di filtro anti rumore, perché se il rumore si dispone casualmente nella griglia, viene dimezzato con 4 scatti e ridotto a 1/3 con 9 esposizioni.

E se domani, volessi stampare...

...un libro fotografico, aka fotolibro.
Un fotolibro è un modo comodo ed elegante per stampare i propri scatti con dimensioni fino a 20x30. Si evitano le scatole di scarpe, lo spazio per le foto, si ha un prodotto editoriale carino anche da mostrare, ed in generale si alimenta ampiamente il proprio ego, cosa che non fa mai male.

Bene, questa procedura è dedicata a chi vuole stampare con linux (un linux recente, diciamo con meno di un paio di anni) un fotolibro tramite BLURB.

Blurb non è l'unico servizio che permette di stampare fotolibri, ed io stesso uso spesso Snapfish, mentre di Pixum ho scaricato ed istallato il software ma non ho mai usufruito dei suoi servizi. Dei tre, Snapfish è sicuramente il più economico, ed ha un software "nativo" (l'ultima volta che l'ho usato anche "problematico") per linux. Blurb, tuttavia, permette di usare carte particolari che danno al fotolibro una marcia "in più", soprattutto con foto in bianco e nero.

 Come prima cosa bisogna scaricare il software di Blurb nella sua versione per Mac. Attenzione, MAC! 

Si va quindi nella cartella dove è stato scaricato il programma e si dà il comando:

dmg2img BookSmart*.dmg

dmg2img è un programma che si trova normalmente nei repository delle distro più famose. In alternativa lo si può prendere da qui. Usando l'asterisco nel nome del file "BookSmart_qualcosa.dmg" si evita di dover copiare esattamente il nome del file sul terminale, per cui si evitano errori e noie varie. Ovviamente bisogna evitare di avere due versioni differenti del file di istallazione nella stessa cartella.

A questo punto si è reso "utilizzabile" il contenuto del file dmg che verrà copiato in una cartella che monteremo con il comando mount passando per una directory temporanea sulla directory radice:

sudo mkdir /macbooksmart
sudo mount -t hfsplus -o loop BookSmart*.img /macbooksmart

Anche in questo caso l'uso dell'asterisco serve per accorciare la procedura, chi vuole può provare ad usare il nome del file completo di versione.

mkdir ~/booksmart/
sudo cp -r /macbooksmart/BookSmart.app/Contents/Resources/Java/lib/ ~/booksmart/
sudo cp -r /macbooksmart/BookSmart.app/Contents/Resources/Java/resources/ ~/booksmart/ 
sudo cp /macbooksmart/BookSmart.app/Contents/Resources/booksmart.icns ~/booksmart/

 Creata la directory booksmart nella propria home, si istalla il programma lì dentro dalla directory temporanea montata in precedenza.

A questo punto si crea il lanciatore ed il gioco è fatto.

echo '#! /bin/sh
cd ~/booksmart
classpath=""

# Build classpath with all jars in the lib directory
for jar in lib/*.jar
do
classpath=$classpath:$jar
done

java -Xincgc -ea -Xms256m -Xmx1024m -classpath $classpath com.blurb.booksmart.application.BookSmart

exit $?
' > ~/booksmart/booksmart.sh 

Infine, si danno al lanciatore i giusti permessi:

sudo chmod a+x ~/booksmart/booksmart.sh

 e si cancellano i file o le cartelle creati durante l'istallazione

sudo umount /macbooksmart
sudo rmdir /macbooksmart
rm BookSmart_* 

Se poi si vuole creare una voce dal menu di Gnome invece che dover cliccare ogni volta sul lanciatore, basta procedere come normalmente quando si aggiungono voci di menu, e selezionare:

~/booksmart/booksmart.sh

come comando, mentre per l'icona si utilizzerà quella propria di booksmart:

~/booksmart/booksmart.icns

Il gioco è fatto.

2012, demosaicizzazione, ultima frontiera!

Premessa

Quando si scatta in RAW (in PEF, per chi usa Pentax), si sta scattando una foto usando una matrice di colori, per la maggior parte dei casi secondo uno schema detto "Bayer".

Lo schema Bayer consta di fotodiodi schermati in modo che possano ricevere solo fotoni nella frequenza del verde, del rosso e del blu. Da notare il numero doppio di fotodiodi "verdi" rispetto agli altri, legato alla fisiologia del nostro occhio, che dà luogo ad un rumore in crominanza nel canale del verde in genere piuttosto ridotto rispetto agli altri due canali.

Ovviamente una fotografia con la matrice di Bayer nuda e cruda è pressoché inutilizzabile. L'operazione matematica che si effettua per passare dal segnale registrato dal sensore (il cosiddetto file RAW) al file "immagine" desiderato è chiamata demosaicizzazione, e consiste sostanzialmente nel prendere sottoinsiemi di pixel e trasformarli in un colore in RGB tramite operazioni matematiche per poter ricostruire i colori "mancanti" nei vari pixel.

In base all'algoritmo utilizzato si potrà avere un maggiore o minore dettaglio, un maggiore o minore rumore, o la presenza di artefatti legati all'operazione matematica condotta dall'algoritmo di demosaicizzazione.

Tipicamente, gli artefatti sono legati all'effetto Moiré ", e tra questi molto comuni sono quelli "a labirinto".

L'effetto Moiré è un effetto ottico molto presente lì dove si opera con matrici di punti (quindi sensori fotografici, scanner, monitor o stampa tipografica, ma anche una stampante laser monocromatica può dare effetto Moiré con alcuni pattern), ed il soggetto in stampa o inquadrato possiede un livello di dettaglio tale da essere sostanzialmente dello stesso ordine di grandezza della densità di pixel del sensore o della risoluzione impostata per la stampa o per la visualizzazione (in questi casi si parla di frequenza di Nyquist). L'effetto Moiré può creare o segnali inesistenti (come certe forme geometriche che sembrano esserci in certi pattern, una sorta di "illusione ottica") o falsare i colori o entrambe le cose.

I difetti "a labirinto" sono una specie particolare di effetto Moiré, per cui nella parte più dettagliata dell'immagine appaiono dei "labirinti". La cosa è particolarmente evidente quando si hanno molti dettagli regolari (un muro di mattoni in lontananza o una maglia di lana a costine, ad esempio).

Un buon software di demosaicizzazione deve rendere il maggior dettaglio possibile senza tuttavia dare luogo all'effetto Moiré. La classica coperta troppo corta, insomma! 

Bisogna poi tener presente che i software commerciali hanno in genere l'algoritmo di demosaicizzazione di quella software house, e non permettono di elaborare l'immagine con altri motori, motivo in più per utilizzare un software open-source.

Algoritmi di demosaicizzazione

Trattare tutti gli algoritmi di demosaicizzazione in un post su un blog è davvero utopistico. Mi limiterò quindi agli algoritmi più "antichi" in ambiente open presenti in DCraw e nei software che ne implementano il codice, in Photivo, Darktable e RawTherapee, e nella comparazione degli algoritmi attualmente più promettenti. Per gli algoritmi più semplici c'è anche una piccola trattazione teorica, per capire "come funzionano" e da cosa derivano i problemi riscontrati in precedenza con le immagini demosaicizzate.

interpolazione bilineare

L'interpolazione bilineare è un'operazione per cui si ricostruisce la coppia di colori primari assenti in un pixel facendo la media aritmetica dei valori dei pixel confinanti.

Volendo ricavare il valore del verde nella posizione 8, dove c'è il pixel blu B8, si può approssimare mediando il valore dei pixel verdi intorno, ovvero:

G8 = (G3+G7+G9+G13) / 4

Nelle posizioni dei pixel verdi, i valori di blu e rosso possono essere mediati solo fra due pixel vicini, per esempio:

B7 = (B6+B8) / 2 ; R7 = (R2+R12) / 2

Mentre nelle altre posizioni possono anch'essi essere mediati fra quattro pixel:

R8 = (R2+R4+R12+R14) / 4 ; B12 = (B6+B8+B16+B18) / 4

Questo algoritmo ha il vantaggio di essere molto veloce, ma ha un serio problema di "color fringing" legato alla presenza, o sarebbe meglio dire assenza, di toni di uno dei colori primari quando si hanno rapidi cambiamenti di colore in orizzontale o verticale da un colore scuro ad uno chiaro. L'effetto in questi casi è il classico bordino colorato, come nel caso delle aberrazioni cromatiche legate ad una specifica ottica.

VNG (gradienti a numero variabile, variable number gradients)

In questo caso  il calcolo è un po' più complesso

Supponiamo di dover ricavare i valori del pixel verde e di quello blu nella posizione 13, ovvero G13 e B13. Si definiscono 8 gradienti nelle direzioni cardinali (Nord, Est, Sud, Ovest, NordEst, SudEst, NordOvest, SudOvest):

Gradiente N = |G8 - G18| + |R3 - R13| + |B7 - B17| / 2 + |B9 - B19| / 2 + |G2 - G12| / 2 + |G4 - G14| / 2 ;
Gradiente E = |G14 - G12| + |R15 - R13| + |B9 - B7| / 2 + |B19 - B17| / 2 + |G10 - G8| / 2 + |G20 - G18| / 2;
Gradiente S = |G18 - G8| + |R23 - R13| + |B19 - B9| / 2 + |B17 - B7| / 2 + |G24 - G14| / 2 + |G22 - G12| / 2;
Gradiente O = |G12 - G14| + |R11 - R13| + |B17 - B19| / 2 + |B7 - B9| / 2 + |G16 - G18| / 2 + |G6 - G8| / 2;
Gradiente NE = |B9 - B17| + |R5 - R13| + |G8 - G12| / 2 + |G14 - G18| / 2 + |G4 - G8| / 2 + |G10 - G14| / 2;
Gradiente SE = |B19 - B7| + |B25 - R13| + |G14 - G8| / 2 + |G18 - G12| / 2 + |G20 - G14| / 2 + |G24 - G18| / 2;
Gradiente NO = |B7 - B19| + |R1 - R13| + |G12 - G18| / 2 + |G8 - G14| / 2 + |G6 - G12| / 2 + |G2 - G8| / 2;
Gradiente SO = |B17 - B9| + |R21 - R13| + |G18 - G14| / 2 + |G12 - G8| / 2 + |G22 - G18| / 2 + |G16 - G12| / 2;

Ciascuno di questi valori è un indice di quanto brusco sia il passaggio di luminosità nelle direzioni indicate dal nome, rispetto alla posizione 13. Più alto è il valore e più secco è il passaggio di luminosità. Le direzioni con valore più alto sono da scartare, perchè introdurrebbero un errore grande se le utilizzassimo per fare una media, mentre quelle con valore più basso sono più attendibili se utilizzate per mediare i valori mancanti (in questo caso del verde e del blu). Facciamo un esempio numerico, supponiamo di avere trovato questi valori:

Gradiente	N	E	S	W	NE	SE	NW	SW
Valore	12	13	7	8	4	7	12	14

Nel passaggio successivo si fissa un valore tale per cui tutti i gradienti con valore superiore saranno scartati. Tale soglia vale:

S = k1*Min + k2 * (Max - Min)

dove k1 e k2 sono costanti il cui valore empirico è rispettivamente 1.5 e 0.5, Min e Max sono i valori minimo e massimo dei gradienti (nell'esempio valgono rispettivamente 4 e 14).

S dunque risulta uguale a 11 e il sottoinsieme di gradienti che non ho scartato sarà:

Gradient subset = {S, W, NE, SE}

Considerando solo le direzioni dei gradienti individuati, e definendo i valori medi in tali direzioni nel modo seguente:

	G	B	R
S	G18	( B17 + B19 ) / 2	( R13 + R23 ) / 2
W	G12	( B7 + B17 ) / 2	( R11 + R13 ) / 2
NE	( G4 + G8 + G10 + G14 ) / 4	B9	( R13 + R5 ) / 2
SE	( G14 + G18 + G20 + G24 ) / 4	B19	( R13 + R25 ) / 2

si possono definire e calcolare le somme Gsum, Bsum e Rsu, che si ottengono sommando i valori incolonnati nella tabella:

Gsum = G18 + G12 + ( G4 + G8 + G10 + G14 ) / 4 + ( G14 + G18 + G20 G24 ) / 4;
Bsum = ( B17 + B19 ) / 2 + ( B7 + B17 ) / 2 + B9 + B19;
Rsum = ( R13 + R23 ) / 2 + (R11 + R13 ) / 2 + ( R13 + R5 ) / 2 + ( R13 + R25 ) / 2;

E finalmente si ricavano i valori cercati:

G13 = R13 + ( Gsum - Rsum ) / 4;
B13 = R13 + ( Bsum - Rsum ) / 4; 

dove 4 è il numero di gradienti considerati.

Per calcolare il valore del pixel verde vengono utilizzati i valori del pixel rosso. Questo perchè i tre valori RGB, nella realtà, risultano molto correlati.

Per ricavare il valori dei pixel rossi e blu nelle posizioni dei verdi si fa lo stesso ragionamento, cambiano solo le definizioni dei gradienti iniziali, ovvero:

Gradiente N = |G3 - G13| + |B8 - B18| + |G7 - G17| / 2 + |G9 - G19| / 2 + |R2 - R12| / 2 + |R4 - R14| / 2 ;
Gradiente E = |R14 - R12| + |G15 - G13| + |G9 - G7| / 2 + |G19 - G17| / 2 + |B10 - B8| / 2 + |B20 - B18| / 2;
Gradiente S = |B18 - B8| + |G23 - G13| + |G19 - G9| / 2 + |G17 - G7| / 2 + |R24 - R14| / 2 + |R22 - R12| / 2;
Gradiente W = |R12 - R14| + |G11 - G13| + |G17 - G19| / 2 + |G7 - G9| / 2 + |B16 - B18| / 2 + |B6 - B8| / 2;
Gradiente NE = |G9 - G17| + |G5 - G13| + |R4 - R12| + |B10 - B18|;
Gradiente SE = |G19 - G7| + |G25 - G13| + |B20 - B8| + |R24 - R12|;
Gradiente NW = |G7 - G19| + |G1 - G13| + |B6 - B18| + |R2 - R14|;
Gradiente SW = |G17 - G9| + |G21 - G13| +|R22 - R14| + |B16 - B8|;

 Il VNG è molto più complicato dell'interpolazione bilineare perché prevede un numero di operazioni elevato, anche con la migliore ottimizzazione dell'algoritmo. Tuttavia, l'effetto ottenuto è decisamente migliore, per cui se è plausibile pensare ad una previsualizzazione con il metodo bilineare, sicuramente in fase di esportazione dell'immagine è consigliabile un algoritmo più ricercato.

Adaptive Homogeneity-Directed interpolation (AHD)

E' un metodo piuttosto complesso basato su un lavoro di Keigo Hirakawa e Thomas Parks. In un'immagine registrata da un sensore, lungo le linee di discontinuità orizzontali o verticali, nascono degli artefatti di colore molto evidenti e fastidiosi. Anche gli algoritmi "adattativi", cioè quelli che variano la direzione di interpolazione in modo intelligente (come quello dei gradienti) non riescono ad eliminare questo inconveniente che prende il nome di zippering (effetto cerniera lampo). Ciò avviene perchè in queste zone, critiche per la struttura stessa della matrice di bayer, la direzione di interpolazione commuta continuamente, dando luogo al un pattern di questo tipo:

 In una transizione da un colore scuro ad uno chiaro, in una situazione reale, il passaggio di colore è graduale, cioè due pixel vicini, nella direzione della transizione, avranno colori "visivamente" simili. Se utilizzassimo le coordinate Lab, vedremmo che lungo la transizione, i pixel adiacenti, a due a due, avrebbero un dE definito come:

dE = RadiceQuadrata ( (L_R-L_R')² + (a_R-a_R')² + (b_R-b_R')² )

che sarà piccolo e che diventerebbe ancora più piccolo se riducessimo le dimensioni dei pixel. Quindi, nell'operazione di demosaicizzazione, se dovessimo scegliere tra una direzione di interpolazione che determina un deltaE grande e una direzione che ne determina uno piccolo, sceglieremmo quest'ultima perchè molto più probabile.

Applicando questo concetto nella realtà, si può verificare facilmente che se il canale verde varia rapidamente, anche i canali rosso e blu in quei punti variano rapidamente, in modo da rendere graduale (sempre in senso visivo) la transizione (in altre parole i tre canali RGB risultano fortemente correlati).

L'algoritmo AHD si basa sul concetto di "omogeneità": un pixel avrà un grado di omogeneità alto se rispetto ai pixel circostanti il deltaE è piccolo, mentre avrà un valore di omogeneità basso nel caso contrario. Per una data immagine è possibile costruire una mappa di omogeneità, assegnando ad ogni pixel il suo grado di omogeneità. Lo spazio Lab risulta particolarmente adatto a questo scopo per la sua proprietà di uniformità, in quanto il concetto di omogeneità risulta strettamente legato al concetto di dE, parametro facilmente calcolabile e indice della differenza visiva fra due colori.

Il metodo di interpolazione AHD consiste in questi tre passi:

1. Interpolare prima secondo la direzione fissa orizzontale e poi quella verticale
2. Convertire in Lab le due immagini ricavate e creare le mappe di omogeneità
3. Combinare le due immagini interpolate utilizzando le mappe di omogeneità

Il terzo punto significa:

• considero il primo pixel
• guardo nelle mappe in quale delle due immagini interpolate il pixel ha il grado più alto di omogeneità
• scelgo questo pixel e lo metto nell'immagine finale.

Poi si passa al secondo pixel e così via.

In generale l'operazione di interpolazione soffre di due tipi di artefatti: uno dovuto alla scelta della direzione di interpolazione (che questo sofisticato metodo risolve nel modo migliore) e uno dovuto alla limitazione nell'interpolazione stessa. Per esempio, supponendo di aver scelto la direzione di interpolazione perfetta, per ricavare il valore di un pixel mancante potrei, per esempio, mediare tra i due pixel adiacenti, oppure potrei considerare anche quelli più lontani, oppure potrei usare tecniche ancora più sofisticate. Ovviamente il risultato finale cambierebbe molto.

 L'algoritmo AHD (almeno nelle sue forme più semplici), rispetto al VNG ed al bilineare soffre parecchio in termini di artefatti "a labirinto":

L'algoritmo AHD è stato nel tempo ottimizzato e potenziato, con sottoinsiemi di pixel considerati nel calcolo maggiori o con condizioni al contorno differenti. In Photivo è possibile operare sia con l'AHD "classico" che con la sua versione "modificata".

Altri algoritmi di demosaicizzazione

In campo open, oltre ai classici VNG (o VNG 4 colori, che guadagna in termini di effetto Moiré ma perde in definizione dei dettagli) e AHD (EAHD, AHD modificato ecc.), sono stati proposti anche il PPG, il DCB, il VCD (Variance of Color Differences di K.H Chung and Y.H Chan) l' LMMSE (basato su un algoritmo di tipo Hamilton-Adams illustrato brevemente qui).
Gli stessi algoritmi "classici" sono stati spesso rivisti ed ottimizzati, mentre in alcuni casi c'è chi ha fuso il risultato di più algoritmi nella speranza di ottenere risultati migliori.
Cercando sulla Rete si trovano numerosi esempi di algoritmi in fase sperimentale. In generale, non è un'impresa "facile", perché sono richieste conoscenze matematiche e di programmazione tali per cui di fatto i nomi nel campo sono quasi sempre gli stessi. Qui e qui sono riportati due esempi (in inglese) significativi di cosa vuol dire studiare un algoritmo di demosaicizzazione e cosa si va a cercare. Da notare che un ambiente "open" permette a più persone di intervenire sul codice, per cui lo stesso algoritmo può essere ottimizzato nel tempo o si possono applicare modifiche che migliorano la qualità del risultato finale. Una cosa del genere su un sistema "chiuso" è molto difficile (gli sviluppatori sono comunque un numero limitato). Chi pensa che un software commerciale come quello di DxO debba avere per forza un algoritmo migliore può ricredersi quardando l'immagine seguente

Ogni algoritmo ha le sue caratteristiche ed è difficile "premiare" un vincitore.  Tuttavia è relativamente facile affermare che, al netto dell'effetto Moiré, gli algoritmi migliori sono AMaZE, DCB e LMMSE, con i primi due che danno foto generalmente più "nitide" dell'ultimo. Nel caso di DCB è possibile impostare un numero di iterazioni il cui effetto finale è limitare fortemente l'insorgere di "labirinti" senza perdita di dettaglio. In genere il numero di iterazioni massimo possibile è elevato, ma nella maggior parte dei casi conviene non spingersi oltre 4, perché oltre questa soglia non si hanno risultati apprezzabilmente differenti.

crop al 200%, demosaicizzazione bilineare

crop al 200%, demosaicizzazione VNG

crop al 200%, demosaicizzazione VNG a 4 colori

crop al 200%, demosaicizzazione PPG

crop al 200%, demosaicizzazione AHD

crop al 200%, demosaicizzazione AMaZE

crop al 200%, demosaicizzazione DCB

crop al 200%, demosaicizzazione VCD

crop al 200%, demosaicizzazione LMMSE

In generale, è importante che il flusso di lavoro nel programma utilizzato effettui le eventuali correzioni di aberrazioni cromatiche prima del processo di demosaicizzazione (http://www.imatest.com/docs/sfr_chromatic/). Riflettendo sul principio di funzionamento degli algoritmi visti in precedenza, e considerando che le zone in cui il colore cambia rapidamente sono spesso anche quelle in cui si ha aberrazione cromatica, si capisce immediatamente che la correzione del fenomeno ottico produce un file da processare sicuramente migliore, per cui l'immagine "demosaicizzata" ne godrà sicuramente. Rawtherapee compie le operazioni nel giusto ordine, mentre ignoro cosa facciano gli altri software.

Altro aspetto da tenere in considerazione è il rumore digitale presente nelle foto, perché in questi casi AMaZE non è la scelta "primaria", mentre DCB fornisce risultati migliori.

L'estremo dettaglio reso da DCB può essere eccessivo in alcuni casi, come ad esempio con i ritratti, per i quali un LMMSE "funziona" meglio.

La regola principale è che non ci sono regole, se non quella del buonsenso di mettersi a cercare i difetti (che si conosce essere in determinate zone dell'immagine) ed eventualmente cambiare algoritmo oppure salvare le immagini con due algoritmi differenti e poi fonderle in postproduzione.
Nell'esempio seguente i dettagli sulla finestra e l'aliasing sono resi meglio dall'algoritmo creato ad hoc dal programmatore rispetto agli altri (-q 0 è l'opzione che il programmatore ha indicato per il suo algoritmo in DCRaw, uno dei software più utilizzati dagli "smanettoni" amanti della riga di comando)!

Confronto tra differenti software di demosaicizzazione

Sulla Rete si trovano varie pagine con confronti costruiti più o meno ad arte per i differenti motori di demosaicizzazione.

A questo indirizzo è possibile osservare come si comportano molti algoritmi con un'immagine particolarmente ostica da trattare.

Sulle pagine web del creatore dell'algoritmo DCB si trova un confronto in cui sono presenti anche alcuni algoritmi commerciali. Su quelle stesse pagine, si può capire anche come funzionano i vari algoritmi per aspetti differenti dalla sola nitidezza.

Sui forum dei vari software (rawtherapee, Photivo, darktable ecc.) si possono trovare vari esempi caricati da utenti che fanno il confronto tra i vari algoritmi per scatti "problematici".
Al di là dei classici esempi "preconfezionati", credo che il primo metro di giudizio debbano essere le proprie immagini. Sotto questo aspetto è utile la funzione di Darktable di fornire un confronto diretto tra diverse versioni della stessa immagine lavorata con parametri differenti.


Algoritmi "secondari"

Tra gli algoritmi presenti nel flusso di lavoro che porta dalla matrice di Bayern all'immagine come siamo abituati a vedere ci sono alcuni che lavorano prima o dopo rispetto al motore di demosaicizzazione e che possono migliorare alcuni aspetti della resa finale.
EECI: è un algoritmo basato sui gradienti che si può accoppiare facilmente all' LMMSE in quanto va a migliorare alcuni pixel favorendo il lavoro successivo del motore di demosaicizzazione. Da quello che ho capito, dovrebbe essere alla base dell' "edge threshold" - "soglia bordi" nella traduzione italiana del programma- nel plugin di demosaicizzazione presente in darktable.
FDBB: è sostanzialmente un riduttore di rumore che agisce a monte dell'operazione di demosaicizzazione. L'autore dell'algoritmo è lo stesso del DCB. L'algoritmo ha due livelli di funzionamento, uno blando ed un altro più "vigoroso", ma ha effetti abbastanza "evidenti" soprattutto sul canale del rosso, come si vede nell'immagine di esempio (da notare i comignoli ed i binari "desaturati"). Come tutti gli algoritmi di riduzione del rumore, anche l' FDBB tende a rendere meno risolta l'immagine.

immagine "originale" (sinistra) ed immagine trattata con FDBB (destra)

Conclusioni

Parlare di fotografia oggi implica parlare di tecnologia e di matematica. La "fotografia" per come la vediamo è ormai un insieme di dati numerici, per cui dobbiamo sempre considerare "postprodotta" qualsiasi immagine che vediamo e che proviene da una camera digitale. Le stesse immagini in jpg che escono dalla macchina fotografica non sono altro che file elaborati dal software interno alla macchina!
La demosaicizzazione è la prima operazione che si fa sulla matrice di punti colorati che viene registrata inizialmente, e sapere che tipo di algoritmo usare può essere essenziale per migliorare la qualità dei nostri scatti.
Il mondo open, nonostante i brevetti software, offre ottimi algoritmi di demosaicizzazione, e soprattutto permette (a chi vuole) di modificare i codici per creare il proprio algoritmo.
Il resto sta a noi e alla nostra capacità.

fonti:
http://www.cambridgeincolour.com/tutorials/camera-sensors.htm
http://www.pentaxiani.it/forum/viewtopic.php?f=27&t=52435
http://www.linuxphoto.org
http://www.photoactivity.com
http://www.stampolampo.it/dblog/articolo.asp?articolo=585

Impostiamo una workstation grafica con linux - parte seconda

Premessa

Dopo aver introdotto l'argomento nella prima parte, con questo post vorrei elencare un po' di software utile per chi vuole cimentarsi nella grafica, anzi nella postproduzione grafica delle proprie fotografie.

Indipendentemente dalla distribuzione, c'è da aspettarsi che chi vuole fare grafica abbia un pc decentemente potente, magari con un buon monitor da 22-24 pollici ben tarato, magari con uno scanner ed una stampante inkjet, tutto hardware opportunamente calibrato così da avere un trattamento dei colori quanto più fedele possibile. Poiché non dovrebbero esserci esigenze di ottimizzazione o di risparmio di risorse, inserisco software che gira in ambienti Gnome o KDE, poiché ho notato che alcuni software per KDE non hanno omologhi altrettanto potenti in Gnome e viceversa. Nella guerra di religione KDE vs Gnome preferisco rimanere neutrale e prendere il meglio dei due mondi.

Visualizzare/catalogare le foto

Un ottimo software per catalogare le foto, il migliore che ho provato fino ad ora anche pensando ad "altri" sistemi operativi, è DigiKam che è parte dell'ambiente KDE. Digikam ha una serie di caratteristiche interessanti, poiché oltre a catalogare le immagini, gestisce un gran numero di formati RAW, permette operazioni elementari di photoediting (ma anche non tanto elementari...), permette di sviluppare un gruppo di immagini con le stesse opzioni in modalità "batch", e supporta immagini con 16bit per canale.

immagine presa dal photostream su flickr di uno dei curatori del progetto: http://www.flickr.com/people/digikam/

Parzialmente sovrapponibile a DigiKam, ma più indirizzato al trattamento delle immagini RAW è Darktable, un software davvero interessante, soprattutto per la rapidità d'esecuzione anche su hardware non recentissimo. Anche se non offre molte opzioni in termini di demosaicizzazione, ed è dotato di un'interfaccia e di un flusso di lavoro un po' inconsueti (in piena anarchia linuxiana), tuttavia offre gran parte degli strumenti utili per ottenere un'immagine che non deve poi essere processata da altro software. In attesa di Gimp 3.0, un software del genere fa davvero comodo, evitando tra l'altro il proliferare di "immagini di lavoro", ovvero di immagini che sono salvate solo per essere date in pasto ad un programma di grafica. Tra le "chicche" nascoste di Darktable ci sono l'eccellente modulo per il bianco e nero, la possibilità di correggere la geometria di un gran numero di obiettivi, ed un sistema di correzione geometrica e prospettica davvero semplice da usare. Di contro, offre pochi motori di demosaicizzazione rispetto ad altre soluzioni.

schermata di Darktable, dal sito del progetto

Altri due convertitori da formato RAW sono RawTherapee e Photivo, ed in particolare quest'ultimo è molto ricco di funzioni relative allo sviluppo del file RAW. Tuttavia manca di un manuale "organico" (o meglio, ce n'è uno in spagnolo) e soprattutto presenta molti strumenti in un'interfaccia particolarmente cervellotica, per cui parte del vantaggio legato alla potenza sfuma considerando la curva di apprendimento iniziale piuttosto ripida.

Infine, un po' di considerazione la meritano anche Ufraw e DCRaw. Ufraw è un software molto semplice da utilizzare, relativamente veloce, ma con molti limiti rispetto a photivo o darktable, che hanno mediamente più scelte per quanto riguarda la gestione dei colori. DCRaw è un tool a linea di comando il cui limite maggiore è dato dall'uso di motori di rendering ormai poco "attraenti" rispetto ad Amaze o dcb. Per gli sviluppatori DCraw è una sorta di "coltellino svizzero" con cui testare al volo i nuovi algoritmi, e le librerie di DCRaw sono la base praticamente di tutti i software di demosaicizzazione presenti su linux, ma per l'utente "utente" forse si tratta di un software poco consigliabile.

Gestione del colore su GNU/Linux

Gestione del colore su GNU/Linux

NOTA: Questo post è sostanzialmente la traduzione di una pagina su un blog (http://blog.pcode.nl/2012/01/29/color-management-on-linux/). Tradotta al volo con l'ausilio di google translator e corretta-rivista "on the fly", potrebbe contenere ancora degli orrori grammaticali e sintattici.
Edit del 7-3-2011: ho leggermente modificato il post, integrando qualcosa da http://en.wikipedia.org/wiki/Linux_color_management

Sembra che ci sia molta confusione su ciò che è la gestione del colore, che cosa si deve fare, e più in particolare come la si usa su Linux. La maggior parte delle informazioni di seguito è genericamente applicabile, mentre nei casi in cui devo essere specifico mi concentrerò su Ubuntu / GNOME / Unity.

 

La prima cosa da evidenziare è la semplice domanda "che cosa il color management dovrebbe fare per me?". La gestione del colore è usata per ottenere risultati coerenti e affidabili nel flusso di lavoro che prevede il passaggio da dispositivo a dispositivo (fotocamera, monitor, stampante). Quindi, se prendo una foto con la mia telecamera "gestita" in termini di colori, la visualizzo sul mio monitor "gestito" dandola in pasto ad un software di image editing (CinePaint, Digikam, GIMP, Krita, Scribus, ecc.) e la stampo con la mia stampante "gestita", dovrebbe apparire quasi la stessa ovunque. Ciò non implica che l'immagine abbia un aspetto migliore (qualunque cosa ciò possa significare...). 

Altra cosa che la gestione del colore non può fare è trasformare un'attrezzatura scadente in qualcosa di migliore. Qualsiasi soluzione di gestione del colore deve sempre lavorare entro i limiti delle attrezzature che sta gestendo. Naturalmente ogni soluzione per la gestione del colore cerca di compensare i limiti di un dispositivo come meglio può, ma ci sono dei limiti intrinseci. Quando questi limiti vengono raggiunti, i colori non vengono più riprodotti.
Inoltre il passaggio dai colori prodotti da un dispositivo a quelli prodotti da un altro dispositivo è un'operazione matematica che può essere condotta in vari modi, e che non necessariamente produce risultati che l'occhio umano considera "migliori".

Ora dobbiamo definire un po' di terminologia corretta. 

La calibrazione è la modifica delle caratteristiche di un dispositivo per soddisfare una certa specifica (per esempio cambiando la luminosità di un display).  

La caratterizzazione è la registrazione del comportamento di dispositivi per la correzione via software. Questi termini sono spesso usati in modo intercambiabile erroneamente (anche da me, scusatemi se faccio io). Il risultato finale della caratterizzazione è un profilo (standard) di colore ICC.

 

Mentre praticamente qualsiasi dispositivo può essere gestione per il colore, mi concentrerò sui monitor per il resto di questo articolo.

Per gestire un display a colori è necessario un dispositivo in grado di "leggere" (caratterizzare) le caratteristiche del display. Per caratterizzare il display ci sono due tipi di dispositivi che è possibile utilizzare: colorimetri e spettrofotometri. I colorimetri sono il dispositivo più comune per caratterizzare display, in quanto sono abbastanza convenienti (100-200 euro). I colorimetri hanno i loro limiti, sono in sostanza solo una macchina fotografica digitale con una finalità molto speciale, con solo una manciata di pixel. Mentre personalmente non ho mai avuto problemi, ho letto di vecchi colorimetri che hanno problemi con i nuovi tipi di tecnologia di display, come gli schermi retroilluminati a LED, e alcuni colorimetri entry level potrebbero non funzionare anche con display professionali con ampia gamma (ne riparleremo più avanti). L'altra opzione è uno spettrofotometro. Questi dispositivi sono piuttosto cari. Gli spettrofotometri entry level come il ColorMunki Photo, sono ad un prezzo leggermente al di sotto di 400 euro (se vedete qualsiasi dispositivo a un prezzo significativamente più basso, è probabile che il dispositivo non è uno spettrofotometro vero). Gli spettrofotometri effettivamente leggono lo spettro completo della luce che ricevono, il che significa che producono informazioni molto più dettagliate. Questo significa che gli spettrofotometri difficilmente saranno ingannati dalle nuove tecnologie. La maggior parte degli spettrofotometri include anche una sorgente luminosa di riferimento, il che significa che possono illuminare (per esempio) la carta, in modo che possano essere utilizzati anche per "profilare" stampanti (in combinazione con inchiostro e carta).

Ora abbiamo bisogno di spiegare qualche concetto in più. 

Quindi, prima dirò quanto è veramente sciocco parlare (per esempio) di RGB 245/0/0. Immaginate di possedere una macchina, e di essere bloccati con il serbatoio vuoto. Utilizzando l'ultima goccia di benzina si cerca di arrivare a un distributore di benzina. Facciamo l'esempio in Europa, per cui dite al benzinaio "metto 40", in modo che lui riempia il serbatoio con 40 litri di benzina. Se qualcuno che vive negli Stati Uniti dice la stessa cosa ad un addetto di un distributore di benzina degli Stati Uniti, otterrà 40 galloni di benzina. Quindi verrebbe da dire "beh, hai detto bene, è RGB..."

Ma in realtà RGB non significa nulla. Dal momento che RGB dice solo che si stanno definendo i colori in tre componenti: rosso, blu e verde. Non dice nulla su quanto il rosso è rosso, quanto è verde il verde più verde, né blu il blu più intenso. Per definire questo, è stato creato il concetto di spazio di colore. Uno spazio di colore definisce la gamma di colori che un dispositivo è in grado di riprodurre, questo è anche chiamato il gamut di un dispositivo (la wikipedia inglese è più esaustiva a riguardo: http://en.wikipedia.org/wiki/Gamut). Il modello di colore RGB è definito nel modello di colore CIE 1931 XYZ. Si fa così perché lo spazio di colore XYZ comprende tutti i colori l'occhio umano medio può vedere. Tutti gli spazi di colore RGB sono definiti come un sottoinsieme dello spazio di colore XYZ. Ancora più importante, negli anni '90 due dei più importanti spazi di colore sono stati definiti: sRGB (da Microsoft e HP) [si può vedere anche la voce inglese di wikipedia: http://en.wikipedia.org/wiki/SRGB], e AdobeRGB (da, erhm ... beh ... Adobe) [idem: http://en.wikipedia.org/wiki/Adobe_RGB_color_space]. sRGB era più o meno definito come il medio comun denominatore della maggior parte dei display a prezzi accessibili. In quel tempo qualsiasi cosa non esplicitamente definita in uno spazio colore specifico era "definita" in sRGB. D'altra parte, AdobeRGB è stato definito per comprendere molti più colori, con lo scopo principale di coprire quanti più colori le soluzioni di stampa professionali potessero coprire.

 

Oltre a definire che l' RGB è in uno spazio di colori, c'è ancora il problema che l'occhio umano non avverte la luce in modo lineare, quindi abbiamo bisogno della correzione di gamma [http://en.wikipedia.org/wiki/Gamma_correction] per fare in modo che le immagini non appaiano come un pasticcio torbido. Di questi tempi un valore di gamma pari a 2.2 è universalmente accettato come standard per i display. Ci sono alcune avvertenze però. Possiedo un netbook con un LCD di basso costo che sembra avere una gamma nativa di visualizzazione di circa 1,8, il che significa che manca di contrasto.

E poi c'è la questione del punto di bianco, poiché non vi è nessun bianco "giusto". Per la maggior parte dei casi, un punto di bianco a 6500K (questo è vero almeno sia per sRGB che AdobeRGB) è buono come standard bianco neutro. L'aumento delle temperature in Kelvin dà un look blu ai display (cosa comune con i display portatili), e temperature più basse in Kelvin danno al display un aspetto più giallo.

E per ultimo c'è la questione della luminanza, che è un termine sciccoso per la luminosità. Se nel lavoro il colore è fondamentale, basta mettere lo schermo ad un livello confortevole (di solito non troppo brillante), se il vostro lavoro è critico per il colore, è cosa comune calibrare il monitor a 120cd/m2.

Detto questo, ci sono alcuni problemi comuni da affrontare. Come ho detto il risultato di caratterizzazione è un profilo ICC. I profili ICC di solito hanno l'estensione del file .Icc o su Windows .ICM. A seconda del software che ha generato il profilo, i profili possono essere nelle versioni 2 o 4. Almeno su Linux (ma anche per versioni precedenti di software proprietari), molti programmi non possono applicare correttamente le versioni 4 dei profili, quindi è meglio al momento procedere con la versione 2. Fortunatamente ArgyllCMS, la suite per il profiling open source genera la versione 2 dei profili di default. Ovviamente i profili ICC sono cross-platform, quindi il profilo generato sotto un sistema operativo può essere iportato senza problemi sotto linux, con l'unica attenzione legata al fatto che i colori dipendono sia dal monitor che dalla scheda video, quindi il profilo è dell'intera sezione grafica, non solo del monitor o della scheda video.

 

Inoltre, è necessario essere consapevoli che la maggior parte dei browers web non sono a conoscenza della gestione del colore (Safari e Firefox dalla versione 3.5 sono l'eccezione se correttamente configurati). Il W3C ha precisato che "il web" dovrebbe essere in sRGB . Ciò significa che si deve caricare immagini sui siti Web, solo in sRGB. Se si caricano immagini che non sono sRGB, non possono apparire come dovrebbero ai potenziali visitatori del sito (con risultati variabili a seconda del browser che usano). Un problema comune è dato dal fatto che la gente è solita caricare le immagini sul web in AdobeRGB, ricevendo reclami relativi al fatto che le immagini sembrano desaturate (in quanto il browser web sta assumendo che siano sRGB, anche se non lo sono).

 

Ora torniamo alla creazione dei profili per i display. Ci sono diversi modi per ottenere questo risultato su Linux. E' possibile farlo manualmente con ArgyllCMS , che è una suite di strumenti a riga di comando. Ci sono tuttavia alcuni front-end disponibili. I due più importanti sono dispcalGUI e GNOME Color Manager . Entrambi gli strumenti hanno il proprio target di destinazione.  DispcalGUI si rivolge a utenti avanzati che conoscono davvero la gestione del colore dentro e fuori. Mentre GNOME Color Manager si rivolge agli utenti entry level, e cerca di rendere tutto il più semplice possibile. Per essere franchi, se tutto in questo articolo non è veramente ovvio per voi, la cosa migliore è probabilmente GNOME Color Manager. GNOME Color Manager fornisce generalmente default sensati, e guida l'utente attraverso il processo tramite una procedura guidata.

Infine, alcune informazioni sulla anatomia generale dei profili dei display. I profili dei display, in particolare, hanno tre componenti importanti: VCGT,  TRC e la matrice XYZ. Il primo bit, il VCGT, spesso chiamato VideoLUT, è una tabella di ricerca che è stata progettata per correggere il bianco sullo schermo e le potenziali aberrazioni tra i canali R, G e B. Il VCGT viene caricato nel driver X11, e funziona solo se il driver è in modalità 24 bit. Quando il VCGT viene caricato in X11 (di solito nel login manager o appena dopo l'accesso) si dovrebbe vedere che i colori del display si spostano un po'. Il VCGT è la sola parte del profilo che risulta vantaggioso per tutte le applicazioni (per come viene applicato da X11), mentre le altre due parti devono essere attivamente applicate dall'applicazione (se configurata correttamente, ne riparleremo più avanti). Abbiamo quindi il TRC che fondamentalmente modella la curva di gamma dello schermo. E infine la matrice XYZ determina il massimo rosso, blu e verde per il particolare schermo. E' possibile avere l' XYZLUT in alternativa per ottenere una correzione più dettagliata, però non è raccomandabile, poiché non tutte le applicazioni applicano correttamente l' XYZLUT.

Dal momento che le ultime due parti (TRC + XYZ) devono essere applicate dalle applicazioni di gestione del colore, hanno bisogno di essere configurate correttamente. Per facilitare questa operazione c'è una cosa chiamata la specifica XICC, che consente un profilo "attivo" da caricare anche questo in X11. Questa procedura è ancora molto rudimentale, in quanto solo il file viene caricato in _ICC_PROFILE (che è fondamentalmente come una variabile d'ambiente), in modo che può essere facilmente caricato da applicazioni di gestione del colore. Invece, le applicazioni normalmente utilizzano la libreria LittleCMS su Linux per applicare TRC e matrice XYZ.

GNOME Color Manager (via GNOME Settings Daemon) assicura che il VCGT di un profilo viene caricato nel driver video X11, così come l'impostazione dell'atom _ICC_PROFILE. È possibile verificare se l'atomo _ICC_PROFILE è stato correttamente impostato utilizzando xprop:

 

  # Xprop-display: 0.0 14-len-root _ICC_PROFILE

E' noto che i driver proprietari (nVidia / ATI) possono causare problemi, e anche configurazioni dual head possono complicare le cose.

 

Ora, alcune applicazioni fanno la gestione del colore di default (assumendo che l'atom _ICC_PROFILE sia stato correttamente impostato), ad esempio Eye of GNOME e Darktable. Altre applicazioni sembrano ignorare l'atomo _ICC_PROFILE di default, come Firefox e GIMP.

Per verificare se il profilo viene applicato, è necessaria una buona immagine di test per valutare. Io consiglio vivamente SmugMug per questo. 

Nel caso particolare di GIMP, caricare l'immagine in GIMP, e andare in Edit e Preferenze, sezione Color Management. Poi selezionare la casella "Cerca di utilizzare il profilo del monitor di sistema" guardando l'immagine. Nella maggior parte dei casi si dovrebbe vedere un cambiamento (se no utilizzare xprop per controllare l'atom _ICC_PROFILE), e soprattutto si dovrebbe essere in grado di distinguere le chiazze grigie una dall'altra nella parte superiore.

 

Per ultima c'è la questione delle immagini che vengono editate su display non calibrati, cosa probabilmente vera per il 99% di tutte le immagini sul web. Se l'autore ha un display a basso contrasto e non gestito, è probabile che avrà aumentato il contrasto in una particolare immagine. Quando si dà un'occhiata a quella immagine su un monitor con i colori gestiti (e con il contrasto corretto), l'immagine può sembrare troppo contrastata. E il rovescio della medaglia, se l'autore aveva un display ad elevato contrasto non gestito, è che è probabile che abbia diminuito il contrasto in una particolare immagine. Quando si dà un'occhiata a quella immagine con un display profilato opportunamente (con un contrasto appropriato), può sembrare priva di contrasto. Quindi non è strano avere discrepanze tra configurazioni con i profili di colore gestiti o non gestiti.

Con questo testo spero di aver fatto luce sulla gestione del colore in generale, e su alcune delle questioni specifiche riguardanti il ​​suo utilizzo su Linux.

 

Impostiamo una workstation grafica con linux - parte prima

Premessa

C'era una volta la workstation grafica. 

Ricordo ancora alla fine degli anni '90 il professore in sala computer all'università che, mostrandomi il Digital da 300MHz e la successiva Silicon Graphics (non ne ricordo il modello, ma su wikipedia si trovano un po' di informazioni a riguardo http://en.wikipedia.org/wiki/Silicon_Graphics), mi enunciava orgoglioso le caratteristiche dei sistemi per il calcolo avanzato e per le esigenze di grafica legata alla dinamica molecolare. Ovviamente i sistemi operativi erano i vari Unix proprietari, perché al tempo windows non era un sistema operativo "per compiti seri".

Poi venne windowsXP, apple entrò in crisi e dovette richiamare Steve Jobs per non fallire, e nel mondo *nix si affermava come attore quasi unico GNU/Linux nelle sue varie versioni.

Nel frattempo tutti noi compravamo fotocamere digitali, ed imparavamo che la camera oscura era ormai stata soppiantata dai programmi di editing grafico, anzi da Photoshop, che usavamo a prescindere dalla licenza...

E oggi?

Unix, fatto uscire malamente dalla porta dei personal computer dal successo di windows, è ormai rientrato ampiamente dalla finestra, nei prodotti apple ( la "X" in macosX sta per "10" ma è anche la x di Unix), nei tablet e smartphone android, nei sistemi linux e derivati.

Non solo, il passaggio di Apple al mondo unix ed il crescente successo di linux tra gli addetti ai lavori ha fatto si che si formasse un'intera generazione di programmatori per i quali il mondo windows è un mondo per alcuni aspetti "alieno", e che sono capaci di creare e portare avanti progetti molto interessanti.

Con i post che seguiranno voglio fare una panoramica su quelli che, ad oggi, ritengo essere i software più interessanti in campo grafico per linux, tenendo presente comunque il gran fermento che c'è nel mondo del pinguino.

Distribuzione:

Tra le varie distro linux, a mio parere le migliori per chi inizia rimangono tuttoggi quelle più famose: Ubuntu, Fedora, Mint, CentOS, Debian...

Dal punto di vista pratico, una distro più diffusa garantisce un miglior supporto da parte della comunità. Chi è alle prime armi non dovrebbe mettere in secondo piano la possibilità di ricevere un aiuto dai vari forum delle comunità nella sua lingua natìa.

Inoltre, molti progetti hanno già dei repository per le distro più famose e diffuse in cui sono presenti le versioni compilate dei programmi o delle librerie, e quindi l'istallazione e l'aggiornamento di questi software diventa estremamente semplice.

Ovviamente, chi è un po' più "smart" può destreggiarsi più facilmente davanti alla compilazione dei sorgenti, e creare il proprio sistema ottimizzato o addirittura la propria distribuzione.

L'unico aspetto su cui bisogna fare attenzione è la scelta dell'hardware. Linux negli ultimi anni è diventato il sistema operativo più compatibile oggi presente sul mercato, e riesce a riconoscere automaticamente hardware molto vecchio o recentissimo. Tuttavia una nuovissima scheda grafica o l'ultimo modello di webcam possono non essere ancora supportate, ed ovviamente esiste una pletora di dispositivi (non moltissimi, e non essenziali, per lo più) che non sono mai stati supportati.

Sapere se e cosa ci aspetta è essenziale nel momento in cui si sta istallando una distribuzione linux. Far girare una distro di prova da penna usb o da CD può essere un ottimo sistema per capire se ci sono incompatibilità. Una sessione sulla Rete ci dirà poi se queste incompatibilità sono risolvibili (spesso lo sono) o no.

Per il caso delle stampanti e degli scanner Epson rimando allo specifico wiki di Ubuntu (la distribuzione che utilizzo ormai dal 2006): http://wiki.ubuntu-it.org/Hardware/StampantiScanner/EpsonMulti. L'ultima volta che ho visitato il sito della Avasys, tuttavia, ho scaricato direttamente i pacchetti compilati, quindi la procedura nel wiki ubuntu è (oggi) da aggiornare. Per scaricare i driver, cercare la propria stampante ed il proprio scanner qui: http://www.avasys.jp/english/linux_e/dl_scan.html

Infine, vorrei specificare una cosa. Da tempo ho deciso di sostituire i software proprietari con quelli sotto licenza free oppure open-source, per motivi etici e pratici. Per questo motivo non voglio avere a che fare con software virtualizzati o emulati tramite Wine, e cercherò di avere il meno a che fare con Mono. Non sono un ultras del software libero, ma se è possibile un'alternativa, perché non usarla?

Alla prossima puntata!