Portable Network Graphics- parte I
Dario de Judicibus
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.