PNG Φ un formato grafico
pensato appositamente per la Rete. Ma perchΘ disegnare un nuovo formato e quali vantaggi
offre rispetto ad altri ben pi∙ famosi e diffusi come GIF e JPEG?
Proviamo a spiegarlo
PNG si legge ping, ma non ha niente
a che vedere con il comando utilizzato per verificare se un certo indirizzo IP Φ
collegato alla rete. In realtα si tratta di un nuovo formato per immagini non vettoriali.
Forse qualcuno si chiederα che cosa c’entra un formato grafico con una rivista che
si occupa di Internet. Semplice: PNG Φ pensato e disegnato appositamente per la Rete e
inteso a sostituire con il tempo il ben pi∙ famoso GIF. Ma perchΘ definire un nuovo
formato, e cosa vuol dire "pensato appositamente per la Rete"?
Vediamo prima quest’ultimo punto.
Supponiamo di dover trasmettere un’immagine via TCP/IP affinchΘ venga
visualizzata all’interno di una pagina Html. Qualunque sia il formato utilizzato,
l’approccio pi∙ semplice Φ quello di scaricare completamente l’immagine prima
di visualizzarla. Sebbene pi∙ facile da implementare, questo approccio ha alcuni
svantaggi. Innanzitutto il visualizzatore deve aspettare che l’intera immagine sia
stata scaricata prima di mostrarla, ritardando cos∞la riproduzione e quindi la
comprensione dell’intera pagina. Ci≥ Φ ancor pi∙ vero quando la pagina contiene pi∙
di un’immagine. Inoltre, non solo l’utente non potrα vedere l’immagine
fino a quando non sarα stata completamente scaricata, ma lo stesso visualizzatore non
potrα fare alcuna considerazione o elaborazione fino a quel momento. Per esempio, non
potrα riservare il giusto spazio per l’immagine all’interno della pagina a meno
che tale informazione non sia stata preventivamente fornita dal disegnatore della pagina
in modo indipendente dall’immagine stessa, per esempio utilizzando i parametri WIDTH e HEIGHT
dell’istruzione Html <IMG>. Inoltre, se lo schermo Φ in grado di visualizzare solo
un numero limitato di colori, non sarα possibile definire un sottoinsieme delle tavolozze
di tutte le immagini della pagina in modo da ottimizzarne la resa cromatica media fintanto
che esse non saranno state tutte scaricate.
Per poter sopperire almeno in parte a questi problemi Φ necessario utilizzare un
formato che permetta alle applicazioni di iniziare a fare alcune considerazioni
sull’immagine stessa prima che tutti i dati dell’immagine siano disponibili;
affinchΘ ci≥ sia possibile Φ necessario che l’immagine sia completamente
definibile all’interno del flusso di dati trasmesso in rete (fully streamable).
Per esempio, un’immagine in cui sono presenti puntatori o riferimenti ad altri dati
non Φ completamente serializzabile, in quanto, in linea di principio, non Φ possibile
utilizzare le informazioni ricevute prima che siano arrivati anche i dati cui fa
riferimento. Pensate a un’immagine compressa con un algoritmo basato su una chiave
variabile e in cui la chiave Φ posizionata alla fine dell’area dati.
Un’immagine del genere non potrα essere utilizzata finchΘ non sarα arrivata la
chiave, anche se tutti gli altri dati sono giα stati ricevuti. Un altro esempio Φ quello
di un’immagine che deve essere completamente letta per poter calcolare alcune
informazioni necessarie per la visualizzazione. Per esempio, potrebbe trattarsi di
un’immagine di cui non vengono date le dimensioni, ma in cui la fine di ogni singola
linea di scansione cos∞ come quella dell’intera immagine Φ segnalata da un
carattere terminatore. Ovviamente, finchΘ non sono arrivati tutti i dati, non sarα
possibile fare alcuna congettura sulle sue possibili dimensioni. Quelli descritti
rappresentano casi estremi, ma evidenziano come, a priori, non tutti i formati siano
necessariamente serializzabili. Uno dei vantaggi di questo tipo di formati Φ che non solo
Φ possibile visualizzare l’immagine man mano che si riceve, ma Φ addirittura
possibile trasmetterla man mano che viene generata, anche in tempo reale.
Il controllo
dell’integritα
Un altro aspetto importante Φ quello
dell’integritα dei dati. Per integritα si intende uno o pi∙ meccanismi di
controllo che segnalino alterazioni nei dati dovuti a eventuali problemi durante la loro
trasmissione. Per un’immagine il controllo d’integritα (integrity checking)
Φ fondamentale, dato che l’informazione trasmessa non ha caratteristiche intrinseche
di riconoscimento. Facciamo un esempio. Un testo ASCII a 7 bit (US-ASCII) Φ un oggetto
facilmente riconoscibile, dato che Φ formato solo da un ben preciso insieme di caratteri.
Un’alterazione casuale pu≥ trasformare uno o pi∙ caratteri in ottetti che non hanno
senso all’interno del testo, come per esempio un carattere nullo. Oppure potrebbe
trasformare un carattere valido in un altro che si trovi al di fuori dell’insieme di
validitα, cioΦ un carattere con l’ottavo bit impostato a uno. Riconoscere
l’alterazione a questo punto Φ semplice. Non solo Φ facile scrivere un programma
che la segnali, ma Φ visibile a vista. Un’immagine invece Φ una serie di dati
relativi alla posizione e al colore dei pixel in una certa area rettangolare. Se un pixel
da blu diviene verde, chi pu≥ accorgersene? Ecco perchΘ servono meccanismi di controllo
che quantomeno identifichino eventuali alterazioni. Non Φ questo il caso, ma alcuni
meccanismi pi∙ sofisticati permettono persino di ricostruire i dati mancanti o
modificati. Nel caso delle specifiche PNG, viene garantita almeno la segnalazione di
eventuali alterazioni e il rilevamento degli errori di trasmissione pi∙ comuni.
Il terzo aspetto da considerare Φ la quantitα di dati da spedire. Foto, illustrazioni
e disegni hanno un loro peso, spesso molto maggiore in proporzione al testo in cui vanno
posizionati. Pensate che anche un’immagine di un paio di kilobyte pesa spesso di pi∙
della pagina Html che la contiene. E 2 KB sono veramente pochi per un’immagine non
compressa! Per risolvere il problema si ricorre appunto alla compressione. Ne esistono di
due tipi: senza perdita di informazione (lossless) e con una perdita controllata
dell’informazione (lossy). Il primo tipo di compressione Φ, per esempio,
utilizzato dal formato GIF, mentre un esempio del secondo tipo Φ caratteristico del
formato JPEG, anche se esiste un formato JPEG con compressione lossless. Ad ogni
modo, la compressione Φ fondamentale per un formato grafico che deve essere utilizzato in
Rete, mentre la salvaguardia dell’informazione compressa Φ un aspetto importante,
soprattutto per immagini non fotografiche, dove la perdita di anche pochi pixel pu≥
rendere illeggibile una figura. Ecco perchΘ servono entrambe.
Quarto aspetto: la portabilitα. Dato che operiamo in Rete, non sappiamo su che sistema
e su che piattaforma l’immagine sarα visualizzata. Θ quindi fondamentale operare
scelte appropriate nel disegnare il formato, tali che garantiscano "a priori" la
massima portabilitα. Alcuni formati assumono capacitα grafiche disponibili solo su certi
sistemi. Un’immagine del genere potrα sempre essere filtrata in modo da
visualizzarla anche su piattaforme che non hanno tali caratteristiche, ma il risultato
finale potrebbe non essere accettabile.
Ultimo aspetto. Dato che l’immagine Φ serializzata, pu≥ risultare utile avere la
possibilitα di visualizzare parzialmente o in una risoluzione pi∙ bassa l’immagine
man mano che viene caricata. Se per esempio l’immagine Φ utilizzata come mappa per
una serie di collegamenti selezionabili (image map) l’utente pu≥ riconoscere
una mappa giα utilizzata in passato anche se non Φ stata ancora completamente
visualizzata. Questo permetterα di selezionarne una parte precisa e saltare quindi alla
pagina desiderata ancor prima che il caricamento dell’immagine sia stato completato.
Per ottenere ci≥ Φ necessario che il formato permetta la visualizzazione progressiva
dell’immagine (progressive display).
PerchΘ PNG?
Questo Φ appunto ci≥ che si intende per
"formato pensato per la Rete".
Ma di formati che soddisfano i requisiti sopra elencati ce ne sono giα, a partire dai
due giα menzionati, e cioΦ GIF e JPEG, senza dimenticare formati quali il TIFF o
l’IFF che comunque soddisfano uno o pi∙ di questi requisiti e che si potrebbero
estendere piuttosto che cercare di creare un formato "ex novo". Allora, perchΘ
qualcuno ha deciso di impegnare tempo e risorse per scrivere le specifiche PNG?
Incominciamo dal formato GIF, che Φ poi quello che giα soddisfa la maggior parte dei
requisiti qui riportati. Questo formato non pu≥ pi∙ essere utilizzato liberamente in
quanto lo schema di compressione ideato per questo formato Φ adesso protetto da un
brevetto. Naturalmente, nulla avrebbe impedito di definirne una variante compatibile con
l’attuale formato ma basata su un meccanismo di compressione non brevettato. Questo
avrebbe tuttavia richiesto di riscrivere almeno in parte tutti i programmi che leggono e
scrivono immagini GIF, per cui ci si Φ ritenuto che valesse la valeva approfittare della
situazione e scrivere un nuovo formato che avesse le stesse caratteristiche dello standard
GIF, ma che risolvesse contemporaneamente anche una serie di limitazioni conosciute di
quel formato.
In effetti, delle specifiche GIF il PNG mantiene la possibilitα di contenere immagini
basate su una tavolozza indicizzata fino a 256 colori, il fatto di essere completamente
serializzabile, la possibilitα di visualizzare l’immagine in modo progressivo, la
possibilitα di definire un colore come "trasparente", quella di aggiungere
informazioni accessorie all’interno del formato, per esempio del testo, il fatto di
non richiedere un particolare hardware o poter essere utilizzato solo su alcuni sistemi
operativi (e non altri) e, infine, un meccanismo di compressione efficiente senza perdita
di informazione. A queste caratteristiche se ne aggiungono altre non sono disponibili nel
formato GIF. Innanzitutto PNG supporta immagini truecolor fino a 48 bit per pixel e
immagini a toni di grigio fino a 16 bit per pixel. Inoltre, permette di definire il
livello di opacitα di ogni singolo pixel, ovverosia supporta quello che in linguaggio
tecnico si chiama il canale alfa. Non solo, il nuovo formato Φ stato disegnato per
trasportare all’interno dell’immagine informazioni relative al fattore gamma
dell’immagine stessa (x). Per chi non sapesse cos∞ il fattore gamma si rimanda
all’articolo del mese prossimo, in cui, tra l’altro, descriveremo in dettaglio
il formato vero e proprio.
PerchΘ pi∙ veloce
e semplice
Abbiamo giα sottolineato che
l’integritα dei dati Φ fondamentale per un formato pensato per la Rete, e PNG
fornisce un meccanismo molto affidabile d’individuazione di eventuali alterazioni dei
dati. Per quanto riguarda poi la visualizzazione progressiva, l’algoritmo utilizzato
da PNG Φ molto pi∙ veloce di quello utilizzato dal formato GIF. In pratica PNG inizia a
mostrare l’immagine dopo che solo un sessantaquattresimo dei pixel sono stati
trasmessi, contro l’ottavo di GIF. Ovviamente, l’immagine iniziale sarα pi∙
rozza, ma spesso giα sufficiente a far capire di che si tratta. Una serie di test ha
inoltre dimostrato che se l’immagine contiene del testo, questo sarα giα leggibile
dopo che solo il 25% dell’immagine Φ stata visualizzata, contro il 50% del formato
GIF. Ci≥ Φ dovuto a un incremento pi∙ bilanciato della risoluzione man mano che
arrivano i dati, bilanciamento basato sul cosiddetto metodo Adam7, dal nome del suo
inventore, Adam M. Costello. Particolarmente efficiente Φ anche il meccanismo di
compressione, soprattutto per quanto riguarda la compressione senza perdita
d’informazioni delle immagini truecolor.
Esistono tuttavia una serie di caratteristiche disponibili nel formato GIF o in altri
formati che sono state di proposito omesse da quello PNG. Il motivo Φ quasi sempre lo
stesso: definire un formato che fosse estremamente semplice da implementare, in modo da
garantire robustezza, portabilitα e interoperabilitα.
Primo, non esiste una versione di PNG non compressa. Questo in quanto si Φ considerata
la compressione una caratteristica essenziale per dati che devono viaggiare in Rete, tanto
pi∙ che il meccanismo scelto non prevede perdita d’informazione (inflate/deflate).
Secondo, non Φ previsto che PNG possa utilizzare anche un meccanismo di compressione
pi∙ spinto, ma che comporti la perdita controllata d’informazione. Esistono giα
altri formati che gestiscono abbastanza bene questo tipo di compressione, come il JFIF, e
a ogni modo un utilizzo non attento di questi metodi pu≥ rovinare irrimediabilmente una
buona immagine. Senza contare che l’utilizzo di tecniche di questo tipo, quali per
esempio quelle utilizzate nel formato JPEG, aumenterebbero le dimensioni e la complessitα
di un decodificatore PNG.
Terzo, PNG supporta solo la codifica RGB per quanto riguarda i colori. Non c’Φ
supporto per altri schemi, come per esempio CMYM, il quale, tra l’altro, Φ troppo device-dependent
per essere utilizzato in una rappresentazione portabile di un’immagine. Ma di questo
tratteremo la prossima volta.
Quarto, PNG non contiene una sezione che pu≥ essere utilizzata per memorizzare una
miniatura dell’immagine (thumbnail). A parte il fatto che questa
caratteristica Φ poco utilizzata dalle applicazioni anche per quei formati in cui Φ
presente, non ha molto senso definire una miniatura le cui dimensioni siano prestabilite
quando in genere Φ l’utente a volerne definire l’altezza e la larghezza a
seconda delle necessitα.
Ad ogni buon conto, gli autori delle specifiche hanno previsto la possibilitα di
definire estensioni private del formato che, pur dovendo seguire rigidamente determinate
regole al fine di garantire gli obiettivi che essi si erano dati al momento di scriverne
le specifiche, permettano in teoria di reintrodurre alcune se non tutte le opzioni
suddette.
Infine PNG non supporta immagini multiple come GIF e quindi tanto meno immagini
animate. Per quanto quest’ultima scelta possa essere oggetto di discussione, gli
autori hanno ritenuto opportuno tenere separati i due formati: PNG Φ un formato disegnato
per una singola immagine. Il giorno in cui si dovesse definire un formato basato su PNG
per la memorizzazione d’immagini multiple, questo sarebbe comunque considerato un
formato differente, con una propria struttura e un diverso identificatore.
Un’ultima
domanda
Resta comunque la domanda: se GIF non va
bene, perchΘ non utilizzare un altro dei tanti formati giα esistenti, magari
estendendoli in qualche modo! TIFF non va bene perchΘ Φ troppo complesso. Si sarebbe
potuta realizzare una versione semplificata di TIFF, ma a quel punto sarebbe comunque
stato un formato diverso, in quanto le applicazioni che supportano questo formato
avrebbero dovuto comunque essere modificate per distinguere fra le due differenti
versioni. Di nuovo, tanto vale creare un nuovo formato. Senza contare che TIFF non Φ un
formato completamente serializzabile, non prevede la visualizzazione progressiva, nΘ un
buon metodo di compressione senza perdita d’informazione.
Un buon formato avrebbe potuto essere IFF, utilizzato ampiamente sull’Amiga, e in
effetti PNG riprende dall’IFF alcune caratteristiche strutturali. Purtroppo
anch’esso non Φ serializzabile.
Infine JPEG. Questo formato non prevede la memorizzazione di immagini basate su una
tavolozza di colori indicizzati, e spesso il meccanismo di compressione utilizzato risulta
inferiore a quello definito per PNG.
Il prossimo mese vedremo in dettaglio la struttura del formato PNG e spiegheremo che
cosa sono esattamente il canale alfa e il fattore gamma di un’immagine.
(ddejudicibus@tecnet.it)