\nuovoarticolo{Daniele Finocchiaro, Gianluca Marcoccia e Marco Menichetti} {WT (wedi tutto$\ldots$ o quasi!)}{% Daniele Finocchiaro \\ Via P.~Scuderi 1 \\ I-95015 Linguaglossa CT \\ Tel.:~(095)643014 \\ \medskip \\ Gianluca Marcoccia \\ Via Garibaldi 78 \\ I-56100 Pisa PI \medskip \\ Marco Menichetti \\ Via Monteverdi 4/C \\ I-50144 Firenze FI } {Internet:~marcocci@cli.di.unipi.it~(Marcoccia)} {italian}{% {\em The lesser-known programming languages \#12: LITHP} \\ This otherwise unremarkable language is distinguished by the absence of an ``S'' in its character set; users must substitute ``TH''. LITHP is said to be useful in protheththing lithtth.}{} % Idee e implementazione: Gianluca Marcoccia % Supporto formati arcani e % ottimizzazioni assembler: Marco Menichetti % ottimizzazioni numeriche: Daniele Finocchiaro \sez{Introduzione} Nella babele di sistemi operativi con cui ci troviamo a convivere, e con il frenetico sviluppo di sistemi di archiviazione sempre più sofisticati, negli ultimi anni sono state create diverse decine di formati grafici, con peculiarità spesso molto differenti tra loro. Un computer nato con la vocazione alla grafica come il nostro beneamato \amiga{} si trova sempre più spesso a dover interpretare file grafici in formati alieni. A questo scopo sono state programmate molte utility per la visualizzazione di immagini grafiche, molti dei quali di ottima fattura, ma con pregi e difetti di diverso genere. Il primo problema è insito nel fatto che è spesso necessario avere un programma di visualizzazione per ogni formato che si intende visualizzare; inoltre, molto spesso questi programmi sono stati convertiti da programmatori senza conoscenza specifica dello hardware sul quale il programma deve girare, e ciò porta solitamente a software scarsamente efficiente sotto il punto di vista dell'utilizzo di CPU, oppure delle risorse grafiche della macchina. L'obiettivo che questa utility si pone è quello di fornire un unico programma per la gestione di archivi grafici dei formati più utilizzati, con particolare riguardo alla velocità di visualizzazione e alla qualità dell'immagine visualizzata. \sez{Formati grafici specifici \amiga{} (più o meno arcani)} Con il passare degli anni, la grafica del computer che alla data della sua uscita aveva sconvolto per l'incredibile numero di colori disponibili (ben 4096!) andava normalizzandosi agli occhi dei suoi utenti. Fu allora che alcuni programmatori pensarono di sfruttare alcune delle potenti caratteristiche dello hardware di \amiga{} per aumentare il numero di colori normalmente visualizzabili sullo schermo. Il concetto su cui si basano questi visualizzatori (chi più, chi meno) è la possibilita offerta dallo hardware di \amiga{} di cambiare (parte) dei colori in palette tra una riga e l'altra dell'immagine visualizzata, permettendo di scegliere i colori più appropriati per ogni riga. Il numero di colori che è possibile sostituire in palette è in funzione del modo grafico utilizzato e, in particolare, in alta risoluzione (640 pixel per riga) è possibile sostituire al massimo 7 colori su 16 per ogni riga. Alcuni programmatori progettarono queste modalità per ben integrarsi con l'ambiente operativo di \amiga{}, producendo buone alternative ai formati normalmente disponibili. Altri invece, poco accorti alle necessità di un ambiente multitasking, ci hanno lasciato formati difficili da maneggiare, per visualizzare i quali è spesso necessario scendere a compromessi. In particolare, alcuni formati, come lo {\em Sliced HAM\/} (HAM a fette) e il {\em Dynamic Hires}, che cambiano 15 colori tra una riga e l'altra, si aiutano con la CPU e richiedono (nel secondo caso) il blocco del multitasking. Spesso è un peccato dover rinunciare a vecchie collezioni di schermate solo perché sono salvate in un particolare formato grafico. L'obiettivo di questo programma è anche il trattamento di questi formati grafici. \sez{Formati grafici non specifici \amiga{}} La grande quantità di formati che si sono sviluppati rende impossibile il supporto di tutti i formati esistenti; fortunatamente, le grandi collezioni di immagini si sono orientate verso l'utilizzo di pochi e ben conosciuti formati. Supportando questi abbiamo la garanzia di riuscire a visualizzare il 95\% dei file grafici che ci possono capitare a portata di mano; in particolare, abbiamo preso in considerazione tre formati: Targa (TGA), JPEG e GIF. Il TGA è stato scelto per l'immagazzinamento di immagini con un numero arbitrario di bit per componente-colore. Il TGA effettua (quando praticata) una compressione {\em lossless\/} preservando l'intera informazione contenuta nella schermata; ovviamente i file in questo formato possono presentarsi in grandezze apocalittiche. Il JPEG è invece un formato che applica una compressione {\em lossy\/} (cioè con perdita di informazione) dal rapporto di compressione incredibile: fino a 40:1. Inoltre, permette l'immagazzinamento di immagini da 24 bitplane in uno spazio ridottissimo, pur preservandone pressoché interamente l'informazione originale. Il formato GIF (nonostante stia oramai dimostrando tutte le sue limitazioni) è tuttora il formato più in uso su piattaforma \msdos{}; sono disponibili sterminate raccolte di immagini in questo formato. \sez{Accuratezza della rappresentazione} Bisogna stabilire un criterio per cui possiamo calcolare quanto un colore sia (o non sia!) simile a un altro; considerando che il colore di un pixel può essere diviso in tre componenti (R,G,B), una scelta naturale potrebbe essere la somma delle differenze tra le singole componenti di due colori, cioè $$|R_1-R_2|+|G_1-G_2|+|B_1-B_2|;$$ ma ciò ci porta a considerare come errori identici quelli relativi ai due colori $R=4$, $G=4$, $B=4$ e $R=3$, $G=6$, $B=3$, rispetto al colore $R=3$, $G=3$, $B=3$ (in entrambi i casi, la ``distanza'' tra i due colori è 3). Questo caso ci fa sorgere il sospetto che la funzione che determina la ``distanza'' tra due colori non sia molto affidabile; infatti, è visivamente ovvio che il colore in cui l'errore è uniformemente diviso tra le componenti è più vicino al colore originale di quello in cui l'errore si accumula su una sola delle tre componenti. Bisogna quindi trovare una formula che permetta di rappresentare la nostra preferenza per il primo colore; dobbiamo quindi rendere più pesanti gli errori accumulati sulla singola componente$\ldots$ niente di meglio di una elevazione al quadrato! La formula diventa quindi: $$(R_1-R_2)^2+(G_1-G_2)^2+(B_1-B_2)^2.$$ Con questa formula, la distanza tra il primo colore e il colore originale è sempre 3, ma la distanza tra il secondo colore e il colore originale è salita a 9! Studiando un minimo la soluzione che abbiamo ottenuto e volendone dare una spiegazione geometrica, possiamo immaginare le tre componenti R,G,B, come disposte sui tre assi di un riferimento cartesiano, e a questo punto cercando anche sul più scalcinato libro di geometria, potremmo scoprire che quello che abbiamo scritto non è altro che la norma euclidea (esclusa la radice quadrata) che ci dà, all'interno di uno spazio tridimensionale, la distanza tra due punti. Potremmo pensare di aver risolto tutti i nostri problemi con la formula che abbiamo appena ricavato, e ciò è parzialmente vero; purtroppo, chi ci mette i bastoni tra le ruote (computazionali) stavolta è il nostro occhio$\ldots$ l'occhio, infatti, non è ugualmente sensibile alle variazioni delle tre componenti cromatiche, bensì è più sensibile a una variazione del verde (chi l'avrebbe mai detto?) che a una del rosso o del blu. Seguendo questa considerazione, per rendere precisa la nostra formula basterà una correzione da effettuarsi con un coefficiente moltiplicativo. La formula, quindi, si evolve ulteriormente: $$s_R*(R_1-R_2)2+s_G*(G_1-G_2)2+s_B*(B_1-B_2)^2,$$ ove $s_R$ rappresenta la sensibilità verso il rosso, e così via. A questo punto possiamo dichiararci soddisfatti dei risultati ottenuti. \sez{Considerazioni algoritmiche} Tutte le visualizzazioni che necessitano un grande numero di colori vengono ovviamente gestite con la modalità HAM. Il modo HAM/HAM8 disponibile sui computer \amiga{} è stato progettato sulla base di una intelligente considerazione: nella grafica ``true color'' (o pseudo), che è prevalentemente fotografica, capita molto raramente di avere brusche alternanze di colori molto differenti tra loro; ciò permette di supporre che sia possibile ottenere il colore di ogni pixel (al più con un errore trascurabile) a partire dal precedente cambiando al più una componente R,G, oppure B. Ciò permette di avere una codifica dell'immagine estremamente compatta pur preservando la massima parte dell'informazione-colore. Purtroppo, questo approccio non è privo di problemi; infatti, occorre determinare (compito computazionalmente oneroso) quale sia il colore più vicino al colore che si intende rappresentare, essendo non univoca (o banale) la modalità di scelta, anche in base a una palette precedentemente generata (compito computazionalmente ancor più oneroso). In particolare, la scelta di una palette specifica per ogni schermata non è praticabile per un programma di visualizzazione in tempo reale, in quanto questo tipo di selezione rende necessarie pesanti statistiche sui colori utilizzati e una grossa quantità di memoria per tenere la schermata (intera!); si è altrimenti costretti a scompattare/caricare più volte la schermata. In questo programma di visualizzazione si è perciò scelto di utilizzare una palette fissa; questa scelta non è eccessivamente restrittiva in quanto in un immagine HAM il tasso di utilizzo di colori in palette rispetto a quelli ottenibili con il cambiamento di una componente è normalmente inferiore al 15/20\%. Basta quindi scegliere una palette con una distribuzione abbastanza uniforme all'interno dello spazio R,G,B che si intende rappresentare. Un altro problema è dovuto al formato in cui vengono rappresentati i dati nei file grafici; infatti, l'\amiga{} è l'unico computer che faccia uso per tutte le sue modalità grafiche della modalità a bitplane, e ciò costringe a delle onerose conversioni dei dati in fase di plottaggio della schermata. Nella nostra implementazione il problema è stato risolto con l'ausilio di una routine per la conversione ``chunky-to-planar'' che permette di convertire interi pezzi di schermata in un sola chiamata. \sez{Note finali} Gli autori hanno comunicato che, per problemi di tempi realizzativi, il programma presentato ad \IPISA{} '94 non avrà tutte le caratteristiche descritte nell'articolo; in particolare sono al momento assenti le routine per i formati GIF e Targa (TGA) e la gestione dei modi grafici delle schermate. Gli autori hanno deciso ugualmente di presentare il loro lavoro ad \IPISA{} '94 (in versione beta), fiduciosi, mediante un contatto diretto con gli utilizzatori, di ricevere pareri e consigli, per poter così venire meglio incontro alle loro reali esigenze nella versione definitiva. \begin{thebibliography}{0} \bibitem[1]{} Foley, van Dam, Feiner and Hughes. \newblock {\em Computer Graphics: Principles and practice}. \newblock Addison Wesley, 1990. \bibitem[2]{} W.B.~Pennebaker, J.L.~Mitchell. \newblock {\em JPEG Still image data compression Standard}. \newblock Van Nostrand Reinhold, 1993. \bibitem[3]{} Compuserve. \newblock {\em The Graphic Interchange Format}. \newblock Documentazione distribuibile liberamente. \bibitem[4]{} Vigna et al.\newblock {\em PCHGLib12.lha}. \newblock Archivio distribuibile liberamente. \end{thebibliography} \finearticolo