PDIC : Porter Duff Image Compositing Parte 1

Questa è la mia traduzione della guida per PDIC Porter / Duff compositing creata da Rogue di Hyperion, alias Hans-Joerg Frieden. Pertanto, il sottoscritto non vuole far intendere in alcun modo di essere l'autore del documento, di cui mi sono limitato ad effettuare un lavoro di semplice traduzione, a beneficio degli utenti Amiga.

Il documento originale, in lingua inglese è qui: documento

Traduzione di Luca Baccari.

• Avviso importante

Questa traduzione mi è costata molto lavoro. Nel caso voleste mostrarla a qualcuno, vi chiedo gentilmente di non copiarla ma di inviare l'indirizzo di questa pagina a chi volete e dove vi pare. Potete tranquillamente linkarla su qualunque sito, chat, indirizzo email o forum vogliate. In questo modo, questo mio sito amatoriale avrà la possibilità di essere di aiuto ad un numero maggiore di persone. Grazie.

Introduzione

Voglio fare una serie di mini articoli sul PorterDuff e su come lavora ed è utilizzato sotto AmigaOS 4.1 e possibilmente coprire anche CAIRO. Sembra che alcune persone abbiano ancora difficoltà con il concetto e l'uso di Porter / Duf e sul perchè sarebbe usato. Questa è la prima parte. Copriremo soltanto i concetti basilari qui, che non richiedono conoscenze di programmazione.
Vediamo cos'è e come è usato.

Visione d'insieme

Porter Duff (PDIC da qui in avanti) è una tecnica usata originalmente in motion pictures per livellare differenti percorsi renderizzati o per combinare immagini generate al computer con azioni reali.
Originariamente distribuito dalla LucasFilm per il motion picture Star trek II, è una tecnica che curiosamente divenne abbastanza popolare negli anni recenti nel mercato dei computer desktop.
Essenzialmente, PDIC "compone" una immagine sorgente in una immagine di destinazione. Questo è simile come principio ad un blitter normale - l'operazione essenzialmente sostituisce pixel nella destinazione che dipende dal pixel sorgente (e di destinazione).
Alcuni blitter supportano anche qualcosa che è chiamato "Transparent blits", che sostituisce solo quei pixel di destinazione che non sono pari a zero ( cioè non trasparenti) nel sorgente bitmap.
Il blitter degli Amiga classic fu meglio di molti chip analoghi di oggi in quanto poteva usare tre differenti informazioni (Piu' spesso usate come sorgenti, destinazioni e maschere) e usava uno stampino per tagliare parti dell'immagine sorgente e sostituirle con la destinazione (tra le altre cose: Il blitter Amiga potrebbe attualmente calcolare una funzione binaria basata sulla forma canonica della funzione chiamata minterms).

In un senso, PDIC porta il blitter originale di Amiga un passo avanti. Invece di permettere uno stampino di singolo pezzo, PDIC permette di assegnare al programmatore/artista un valore di "copertura" per ogni pixel.
Ciò significa questo: Supponete di avere un bitmap che ha un triangolo rosso verniciato su di essa. All'orlo del triangolo, se il triangolo era matematicamente corretto, ciascun pixel sarebbe coperto solo parzialmente dalla forma del triangolo. Il resto dei pixel non sarebbe coperto.
Ovviamente, se noi coloriamo questo triangolo come normale bitmap, noi otteniamo qualcosa che è frequentemente chiamato "jaggies" o "aliasing" - principalmente, un pixel non può essere parzialmente colorato ma o è colorato ( di rosso in questo caso) o non lo è. Questo effetto aliasing diventa tanto piu' ovvio quanto è bassa la risoluzione, ma anche in alte risoluzioni, esso è molto evidente. Ci sono dei modi per prevenirlo (chiamati anti-aliasing), ma queste tecniche di solito funzionano bene per forme basilari come archi e cose simili ( AmigaOS usa queste tecniche per il "font smoothing" per esempio).

Se noi presumiamo che ogni pixel della nostra forma contiene anche un valore che specifica la sua copertura ( cioè quale percentuale del pixel è attualmente colorata dall'immagine, e quanto è realmente trasparente), possiamo usare questa informazione per mescolare il triangolo rosso con il colore che è già nella nostra bitmap di destinazione.
Per esempio, se vogliamo comporre questo triangolo sopra una tela bianca, possiamo far gravare il colore del pixel in arrivo con la sua copertura e il colore della destinazione reciprocamente. Con questo sistema, i pixel all'orlo del triangolo iniziano ad "accendersi", in pratica l'informazione della copertura ci permette di far gravare il contributo dei pixel sorgenti e di destinazione per calcolare un colore più ottimale per un pixel. Questo processo è solitamente chiamato alpha blending, dato che la copertura è di solito chiamata alpha per ragioni storiche (incidentalmente, questo è anche il significato della "A" nel modo colore ARGB). L'alpha blending è solo un caso speciale di PDIC. PDIC di solito funziona attraverso esso.

Per i novizi, non c'e' nulla che ci impedisca di fare bene la stessa supposizione di copertura sulla bitmap di destinazione.
Non abbiamo bisogno di limitarci a lavorare soltanto con destinazioni completamente opache. Per quello che vale, il risultato dell' operazione di composizione potrebbe essere l'input di un'altra operazione. Supponiamo per esempio di voler marcare il triangolo rosso con un testo su cui è stato applicato l'anti-aliasing. Siccome, come menzionato sopra, le informazioni di copertura di archi e linee sono esattamente calcolate e i font sono creati con archi e linee, la copertura dei font è facile da ottenere. Una font può essere composta perciò sopra il nostro triangolo rosso senza sforzo.

Consideriamo un altro esempio. Tutti probabilmente avranno familiarità con l'effetto che è spesso usato nei film per dare l'impressione di guardare attraverso un telescopio. Di solito, l'immagine del fim è tagliata in una forma circolare per generare questa impressione.
Allo stesso modo, un effetto grafico che si è talvolta incontrato è la visualizzazione di un'altra immagine attraverso un ampio testo ( per esempio, la sequenza titolo di un film). Mentre è facile generare un cerchio "invertito" per l'effetto telescopio, generare l'inverso di un font può essere più difficile; è probabile che noi non vogliamo generare bitmap addizionali ma usare una bitmap esistente che contiene un testo renderizzato con informazioni di copertura. In questo caso, usando il semplice alfa blending non funziona, - noi otterremmo il contrario di quello di ciò che davvero vogliamo, lettere nere sopra alla destinazione.

PDIC lavora con operatori. Un operatore è una regola su come calcolare il pixel risultante e le informazioni di
copertura, basato sulla fonte e sulla destinazione. Queste regole determinano come la fonte e bitmap di destinazione colpiscono l'un l'altro. Un operatore comunemente usato è il Source_Over_Destination (quello che abbiamo descritto sopra). Una descrizione particolareggiata di questi operatori è fuori dallo scopo di questa introduzione; Il documento originale che introduce la composizione dell'immagine con Porter Duff è disponibile qui: link

L'implementazione di PDIC per AmigaOS 4.1 può fare più della "sola" composizione. Ci sono due modi di base di operare: modo Blit e modo triangolo. Il modo Blit lavora come un Blitter, infatti, voi date due bitmap (fonte e destinazione) ed il motore di composizione applica la fonte alla destinazione con un operatore specifico ad un set di coordinate determinato, scalando la fonte con fattori arbitrari e tagliando il risultato in uno specifico rettangolo sulla destinazione.

Il modo triangolo è molto più flessibile dell'altro. Invece di coordinate di obiettivo, il programmatore può passare
al motore di composizione un elenco di triangoli. Ogni triangolo è fatto su di tre vertici ognuno dei quali può avere coordinate di texture individuali (inclusa una coordinata di profondità per correzione di prospettiva). I triangoli individuali sono ancora applicati usando l'operatore di composizione Porter/ Duff, ma il programmatore ha un controllo molto accurato sulla 'grana', la disposizione e la mappatura. E' facile, ad esempio, ruotare o distorcere la bitmap. Effetti come il "cubo desktop" e le famose finestre 'tremolanti' e gli alri effetti desktop sono perfezionate facilmente con questa funzionalità.

CAIRO

La Cairo API Graphic è un vettore API grafico che permette al programmatore di avvantaggiarsi di grafica 'raster-free' ed internamente usa un compositore per alcuni dei suoi rendering (per esempio per testo con anti-alias e forme). Supporta dispositivi di uscita multipli; questo vuol dire che lo stesso codice che disegna ad esempio un documento di testo in un elaboratore di testi può generare output per stampante attraverso un PostScript o un file PDF.

CAIRO E COMPOSIZIONE - APPLICAZIONI

La domanda ovvia ora : per che cosa abbiamo bisogno di questo ? Certamente, avere finestre trasparenti ed angoli rotondi è bello ma dannatamente da 'scienza spaziale'. Perciò, noi avremo un'occhiata ad alcuni campioni di applicazioni per queste tecnologie nuove.

L'applicazione ovvia: Mozilla Firefox

Mozilla Firefox ha, fin da versione 3.0, ha convertito tutta la sua interpretazione verso Cairo.
Va da sè dire che una veloce ed efficiente implementazione ed accelerazione hardware di Cairo sia una pietra miliare per il porting di questa applicazione per AmigaOS4.1. Ci sono un paio di applicazioni, oltre Firefox, che dipendono dal supporto Cairo, come OpenOffice ClassPath, ed altre. Pertanto, Cairo è il primo gradino per realizzare il porting di queste applicazioni.

UN MIGLIORE DESIGN DELL'INTERFACCIA GRAFICA

Principalmente, l'uso di Cairo e Porter / Duff compositing ci permette migliori interfacce utente.
A causa della sua natura, il disegno di bitmap in shermi e poi la composizione di ciò nella finestra visibile, è libero dallo scintillio (flicker-free). Voi non vedete nulla disegnato, voi vedete solo il risultato finale. Questo previene il solito scintillamento irritante quando si disegnano elementi animati.

In aggiunta, permette a noi di fare un uso migliore dell'animazione in interfacce utente.
Mentre è probabile che molte persone rigettino questo metodo come 'eyes candy', virtualmente tutte interfacce
utente moderne se ne avvalgono. Supponete di avere un bottone 'iconizzato' nel bordo di finestra che avete appena cliccato. Se avete molte icone sul vostro desktop, è probabile che voi cominciate a cercare l'icona della vostra finestra iconificata. Comunque, se l'iconificazione di finestra è animata (per esempio, zoomando la finestra "dentro" l'icona) sapete immediatamente dove è andata a finire l'icona.

L'animazione permette anche di mettere meglio a fuoco con illuminazione. Se avete un elenco di oggetti in una finestra, l'uso di grafica di GUI scalabile ( Cairo) permette di zoomare l'oggetto su cui vi è sopra il cursore, possibilmente rivelando informazioni supplementari. Gli importanti elementi di interfaccia utente come grafica
di vettore permettono a noi di zoomare arbitrariamente sugli oggetti, sia esso per attirare l' attenzione su di loro, o per adattare più oggetti sopra lo schermo quando gli elementi si accalcano.

Compositing aiuta anche a permettere ad utenti di avere più controllo sull'aspetto della loro interfaccia utente.
Tipicamente, i "temi" di GUI sono costruiti da un set di bitmap che di solito sono 'regolate' per andare bene insieme. Una casella di immissione (checkbox), per esempio, di solito è realizzata in tale modo che si adatti
ad esempio, al pattern di sfondo. Compositing, d'altra parte, permette ad un artista o al disegnatore di GUI di definire canali di trasparenza per gli elementi di immagini delle loro GUI, ed il programma può semplicemente comporre insieme questi elementi.

Questo non solo rende il design più flessibile, permette anche all'utente di scambiare certi elementi (per esempio lo sfondo). Qt4 toolkit di Trolltech di TrollTech fa un uso esteso di queste caratteristiche per permettere la modifica di una applicazione attraverso fogli di stile.

IMPATTO PER AMIGA OS 4.1

Chiaramente, non ci siamo ancora. Ma AmigaOS 4.1 e le nuove tecnologie introdotte con esso sono la fondamenta per una esperienza di interfaccia utente più ricca nelle future versioni. Per gli sviluppatori di applicativi, Cairo e PDIC offrono grandi possibilità per migliorare l'aspetto e il feelling delle loro applicazioni.
Ci sarà eye candy? Molto probabilmente, sì. Ma se lo guardate, il nome "interfaccia utente" già implica quanto è importante questa parte del sistema - è, dopo tutto, l'interfaccia diretta tra il sistema e te, l'utente. Una buona esperienza di interfaccia utente è una parte molto importante del lavorare con il computer.

Questa è la mia traduzione della guida per PDIC Porter / Duff compositing creata da Rogue di Hyperion, alias Hans-Joerg Frieden. Pertanto, il sottoscritto non vuole far intendere in alcun modo di essere l'autore del documento, di cui mi sono limitato ad effettuare un lavoro di semplice traduzione, a beneficio degli utenti Amiga.

Il documento originale, in lingua inglese è qui: documento

Traduzione di Luca Baccari.

• Avviso importante

Questa traduzione mi è costata molto lavoro. Nel caso voleste mostrarla a qualcuno, vi chiedo gentilmente di non copiarla ma di inviare l'indirizzo di questa pagina a chi volete e dove vi pare. Potete tranquillamente linkarla su qualunque sito, chat, indirizzo email o forum vogliate. In questo modo, questo mio sito amatoriale avrà la possibilità di essere di aiuto ad un numero maggiore di persone. Grazie.