Convertire GIF in BMP

Questi due formati hanno quasi la stessa età — 1987 e 1990 — e risolvono lo stesso problema in direzioni opposte. Una GIF memorizza un indice in una tavolozza di al massimo 256 voci, che è un byte per pixel prima che LZW la comprima ulteriormente. La bitmap scritta qui memorizza una tripla completa di blu, verde e rosso per ogni pixel, non compressa.

Quindi la crescita non è di un fattore ma di due moltiplicati fra loro. Tre byte dove la GIF ne usava uno, e nessuno del risparmio LZW che aveva reso la GIF piccola in primo luogo. Una GIF da 40 KB diventa abitualmente una bitmap dieci volte più grande, e su grafica piatta con lunghe sequenze di colore identico — il materiale che la GIF comprime meglio — il rapporto è anche peggiore.

L’aritmetica è breve e non contiene stime. Si moltiplica la larghezza per tre per ottenere i byte di una riga, si arrotonda al multiplo di quattro superiore, si moltiplica per l’altezza, e si aggiungono 54 byte di header. Una GIF da 480 per 270 dà 1.440 byte per riga, nessun arrotondamento necessario, 388.800 byte di pixel e 388.854 totali.

Niente della sorgente cambia quel numero. La stessa bitmap da 480 per 270 esce da una fotografia pesantemente ditherata e da un rettangolo rosso pieno, perché il formato memorizza ogni pixel letteralmente in entrambi i casi. Questa prevedibilità è il motivo per cui l’hardware chiede bitmap: un firmware che ne legge una può allocare il suo buffer dall’header da solo.

Due convenzioni nella bitmap scritta qui sembrano errori e non lo sono. Le righe sono memorizzate dal basso dell’immagine verso l’alto, e i canali all’interno di ogni pixel sono ordinati blu, verde, rosso anziché il contrario. Entrambe sono nella specifica originale ed entrambe sono ciò che un lettore di file BMP si aspetta di trovare.

La terza è il riempimento. Ogni riga è riempita fino a un multiplo di quattro byte, quindi un’immagine larga 101 pixel scrive 303 byte di pixel seguiti da un byte di niente, 304 byte per riga. Un codice che legge una bitmap assumendo larghezza per tre per riga produce un’immagine che si storta diagonalmente, che è il singolo errore più comune in un lettore BMP scritto a mano.

BMP contiene un’unica immagine. Non ha alcun concetto di sequenza, ritardo o loop, quindi una GIF animata che arriva qui diventa il fotogramma su cui si apre e il resto viene scartato — il registro lo dichiara come avvertenza sulla coppia anziché lasciarlo scoprire.

Per le destinazioni che chiedono bitmap questo è raramente un problema, perché un dispositivo che vuole un BMP vuole per definizione un’immagine statica. Vale la pena verificare che il primo fotogramma sia quello desiderato: molte GIF si aprono su un fotogramma vuoto o una schermata titolo prima che il contenuto cominci.

È un’aspettativa ragionevole che un’immagine con solo 256 colori distinti produca un file piccolo, e per un formato a tavolozza lo sarebbe. La specifica bitmap permette persino esattamente quello — un BMP a 8 bit con una tabella di colori, che si mapperebbe su una GIF quasi perfettamente.

Questo convertitore non ne scrive uno. Ogni bitmap che produce è a 24 bit, quindi una GIF che usa sei colori costa gli stessi byte di una fotografia delle stesse dimensioni. Se il dispositivo che si sta alimentando richiede specificamente una bitmap a 8 bit con tavolozza anziché accettare un BMP, questo file non basterà, e vale la pena accertarsene prima della conversione anziché dopo che il dispositivo l’ha rifiutata.

Una GIF può designare una voce della tavolozza come trasparente. La bitmap scritta qui non ha un canale alfa — 24 bit, tre canali, niente che avanzi — quindi quei pixel devono ricevere un valore prima della codifica.

L’opzione Colore di sfondo decide quale sia quel valore, e il predefinito è il bianco. Sceglierlo di proposito conta sull’hardware: un’icona destinata a un display con interfaccia nera andrebbe appiattita su nero, non su bianco e poi invertita dopo. Dove un sistema si aspetta un chroma key, si imposta l’opzione su quel colore esatto anziché confidare in un passaggio successivo che lo trovi.

Non c’è un cursore di qualità su questa conversione e non potrebbe esserci: non compressa significa non compressa, e non c’è nulla da scambiare. L’unica leva è la larghezza massima, che ridimensiona l’immagine prima che i pixel vengano scritti e quindi cambia la dimensione del file in modo quadratico.

Dimezzare la larghezza riduce la bitmap a un quarto. Di solito è la mossa giusta quando la destinazione è un display piccolo comunque — un pannello largo 128 pixel non guadagna nulla da una sorgente da 640, e ridimensionare qui anziché nel firmware significa che il dispositivo non deve neppure tenere il buffer più grande.

Ogni conversione raster qui rimuove i metadati lungo la strada, senza eccezioni, e su questa coppia la regola ha pochissimo da fare. Una GIF non ha blocco EXIF, nessun modello di fotocamera, nessuna coordinata GPS; il massimo che porta di solito è un’estensione di commento e un’estensione di applicazione lasciata da qualunque cosa l’abbia scritta.

Il formato bitmap non ha dove mettere nulla di tutto ciò in ogni caso. Il suo header descrive dimensioni, profondità di bit e poco altro, quindi ciò che esce sono pixel e geometria. Se la GIF proveniva da un registratore di schermo che aveva impresso il proprio nome in un blocco di commento, quel nome non viaggia.

La GIF viene decodificata dal supporto immagine del browser e l’header della bitmap e le righe di pixel vengono scritti in JavaScript nella stessa scheda. Non c’è un server nel percorso, nessun caricamento, nessun account, e il file sparisce quando la scheda si chiude.

Questo conta più di quanto sembri per questa coppia, perché ciò che la gente converte in BMP è spesso materiale interno: una grafica del pannello di controllo, un’etichetta di prodotto, la schermata iniziale di uno strumento. Niente di tutto ciò ha bisogno di passare per l’infrastruttura di qualcun altro per diventare una bitmap.