Convertire BMP in AVIF

Un file AVIF è, nella sua struttura, un fotogramma fermo di AV1 dentro un contenitore specificato dall’Alleanza for Open Media nel 2019. Eredita il lavoro di compressione di un codec video moderno, e per questo batte WebP e JPG su materiale fotografico alla stessa qualità visibile.

Eredita anche il costo. Il registro elenca la lentezza di codifica come problema noto del formato, e la pipeline qui concorda: la decodifica è il collo di bottiglia per le fotografie in ogni altra conversione, e in questa è la codifica. Un bitmap da dodici megapixel — 4000 per 3000 pixel, 36 MB come BMP — richiede tempo sufficiente perché la barra di avanzamento faccia qualcosa di concreto invece di rassicurare. Questa asimmetria vale la pena interiorizzarla, perché inverte l’intuizione abituale: il bitmap è il file enorme e facile da leggere, l’AVIF è il file minuscolo e costoso da scrivere.

AVIF contiene dodici bit per canale e descrive spazi colore ampi. Quelle due capacità sono la maggior parte del motivo per cui il formato esiste, e sono la ragione per cui è il formato di consegna per la fotografia HDR.

Un BMP contiene otto bit per canale in RGB puro. Nello spazio colore più ampio nella sorgente non c’è niente, niente gamma dinamica extra, niente profilo colore — il registro non elenca alcun contenitore di metadati per BMP. Così il margine dell’AVIF resta vuoto, e l’unico beneficio che si raccoglie da questa conversione è la compressione. È un beneficio reale; vale la pena sapere che è l’unico, perché molto di ciò che si scrive su AVIF riguarda le capacità che un bitmap non può raggiungere. Un formato non aggiunge informazione: può solo descrivere ciò che è arrivato, e ciò che è arrivato qui è RGB a otto bit da un formato che Microsoft ha pubblicato nel 1987.

Viene eseguita come WebAssembly dentro la scheda del browser, sul processore della macchina che avete. Non c’è un server che fa il lavoro, ed è il motivo per cui niente viene caricato e anche il motivo per cui un lotto di bitmap grandi è qualcosa che si avvia e a cui si torna.

La forma pratica è questa: un’immagine di medie dimensioni è un’attesa, e una cartella di quaranta uscite di scanner è un caffè. Se è inaccettabile e il pubblico è ampio comunque, WebP è a una pagina di distanza e codifica in una frazione del tempo per un file che di solito è entro un margine modesto dall’AVIF. Niente di tutto ciò è un difetto della conversione — la stessa codifica su un server richiederebbe lavoro comparabile, pagato dal processore di qualcun altro e con il vostro file che dovrebbe viaggiare per raggiungerlo. Il tempo è il prezzo onesto dell’immagine che non lascia la macchina.

Il registro classifica AVIF come supportato dai browser moderni, e la parola "moderni" lavora sul serio accanto all’"all" che dà a WebP e JPG. I browser desktop e mobile attuali leggono AVIF; dispositivi più vecchi, alcuni browser in-app e una buona parte del software di posta elettronica no.

Il che ne fa un formato da servire piuttosto che da inviare. Come allegato o file consegnato a qualcun altro è una scelta sbagliata, e il fatto che si apra sulla vostra macchina dice poco di quella altrui. La stessa cautela vale per gli strumenti di grafica e fotoritocco: il supporto è arrivato a singhiozzo, e un AVIF che un browser mostra perfettamente può essere un file che un collega non riesce a posizionare in un documento.

Il meccanismo che rende la lacuna di supporto sopravvivibile è l’elemento picture: più sorgenti elencate in ordine, ciascuna con il suo tipo, e il browser prende la prima che capisce. Mettete l’AVIF prima, un WebP dopo e un JPG per ultimo, e ogni visitatore riceve il file più piccolo che il suo browser sa effettivamente decodificare senza codice di rilevamento in esecuzione.

Il che significa convertire lo stesso bitmap due volte, ed è il motivo per cui il lotto su questa pagina spesso viene eseguito insieme a quello WebP. Conviene farlo in quest’ordine invece di convertire l’AVIF dal WebP: ogni codificatore con perdita prende le proprie decisioni su cosa scartare, e impilare due di essi produce un file che porta entrambi i set di perdite senza risparmiare nulla. Codificate sempre ciascun formato di consegna dal bitmap stesso.

AVIF porta un canale alfa, e niente su questo percorso appiattisce l’immagine o chiede un colore di sfondo, quindi un bitmap a 32 bit con zone trasparenti le conserva. I file a 24 bit che costituiscono la maggior parte di ciò che arriva qui non ne hanno da conservare.

Il controllo qualità ha come valore predefinito 82, lo stesso numero che ogni destinazione con perdita di questo sito offre, e vale la pena ricordare che la scala appartiene al codificatore più che all’immagine. Ottantadue in AVIF e ottantadue in JPG non sono la stessa quantità di perdita né la stessa dimensione del file, quindi confrontare due formati significa confrontare le uscite, non le impostazioni. AVIF tende anche a fallire in modo diverso: laddove JPG si rompe in blocchi e in aloni attorno ai bordi, AVIF smussa le texture fini, che è meno ovviamente sbagliato e più facile non notare finché l’immagine non è accanto all’originale.

Quando il pubblico include dispositivi vecchi. Quando l’immagine è abbastanza piccola che la differenza sono pochi kilobyte. Quando il materiale è grafica piatta con bordi netti, dove il vantaggio di AVIF si assottiglia e può invertirsi. E quando si stanno convertendo centinaia di file e il tempo di codifica è il vincolo che conta davvero.

AVIF si guadagna il suo costo su immagini fotografiche grandi servite a un pubblico moderno tramite un elemento picture. È un caso specifico invece che un default, e una pagina che vi dicesse il contrario vi venderebbe il formato più recente invece di descriverlo. La prova che chiude la questione costa un minuto: convertite un bitmap rappresentativo in entrambi, mettete i due conteggi di byte l’uno accanto all’altro, e decidete se la differenza giustifica una seconda codifica di ogni file e un fallback nel markup. A volte lo fa palesemente; spesso palesemente no.

È l’unica regolazione che migliora insieme la dimensione del file e il tempo di codifica, ed è proporzionale al conteggio dei pixel più che alla larghezza — dimezzare la larghezza di un bitmap toglie tre quarti dei pixel che il codificatore deve pensare.

Impostate la larghezza massima alla più larga in cui l’immagine verrà mai visualizzata, raddoppiata per gli schermi ad alta densità. Una scansione da 4000 per 3000 ridotta a 2000 per 1500 è ancora più grande di quasi ogni posto in cui apparirà, e la codifica AVIF finisce in circa un quarto del tempo.

Lasciate cadere l’intera cartella e ogni file viene convertito a turno sulla vostra macchina, conserva il suo nome con l’estensione cambiata, e l’insieme torna come un unico ZIP. Il tetto è 100 MB per file, che corrisponde a circa 33 megapixel di bitmap non compresso.

Pianificate il lotto attorno alla codifica piuttosto che attorno al download. I file vengono elaborati uno dopo l’altro, quindi il tempo è circa la somma delle singole codifiche, e le immagini più grandi lo dominano — un singolo bitmap da 33 megapixel può richiedere più tempo di trenta piccoli. Estrarre i file palesemente troppo grandi e ridimensionarli prima vale più di qualsiasi altra modifica che potete fare a un lotto qui, ed è l’unica che migliora sia le uscite sia l’attesa.

AVIF è un formato di consegna e questa conversione è con perdita. Ciò che esce è dimensionato e codificato per il posto in cui andrà, e non c’è un percorso di ritorno da esso ai pixel che il bitmap conteneva.

Se il BMP è la vostra unica copia, tenetelo o convertitelo prima in PNG — quella direzione è esatta e costa una frazione dello spazio su disco. Poi producete l’AVIF dal master ogni volta che la destinazione cambia, invece di convertire un file di consegna in un altro file di consegna e impilare le perdite di un codificatore su quelle di un altro.