Convertire ICO in AVIF

AVIF non è un formato immagine che si dà il caso comprime bene; è il percorso intra-frame del codec video AV1 con un contenitore attorno. Tutto ciò in cui è brato ne discende. AV1 è stato costruito per predire il contenuto di un blocco dai suoi vicini e per scartare il dettaglio residuo che un occhio in movimento non coglie, che è una strategia straordinariamente efficace su fotografie e grana pellicolare.

Un’icona non ha nessuna delle due. È un piccolo numero di regioni piatte con bordi netti e poche dozzine di pixel antialias lungo ogni lato. Non c’è trama da modellare, nessun gradiente da prevedere e poco residuo da scartare — quindi il meccanismo che fa vincere AVIF su una fotografia non ha quasi nulla da fare, mentre i suoi costi fissi restano.

Su un’icona di prova di 8.471 byte con quattro voci, convertita alla qualità predefinita di 82, i risultati sono stati: 1.737 byte come PNG, 1.894 come GIF, 3.054 come WebP, 3.624 come AVIF e 4.005 come JPEG. L’ordine è quasi esattamente l’inverso di quello che lo stesso test su una fotografia darebbe.

Non è una differenza marginale. L’AVIF è più del doppio del PNG ed è lossy. Per una cartella di duecento icone, migrarle in AVIF aggiunge circa 380 kilobyte a ciò che il sito distribuisce invece di togliere qualcosa. Si tolgano le icone dalla migrazione e si lascino come PNG.

La trasparenza è conservata: sull’icona di prova il pixel angolare dell’AVIF risultante legge 0,0,0,0. Non è scontato per ogni formato efficiente — il percorso GIF sul sito rende lo stesso angolo nero opaco — quindi se il marchio è un ritaglio e il formato deve essere AVIF, almeno questa parte funziona.

Funziona codificando l’alpha come un secondo piano accanto al colore, di fatto una seconda piccola immagine dentro il contenitore. Su una fotografia quel sovraccarico si perde nel rumore. Su un’icona da 256 pixel, dove l’intero file è pochi kilobyte, è una quota visibile del totale e parte del motivo per cui il numero sopra è quello che è.

L’encoder AVIF è il modulo WebAssembly più grande che questo sito distribuisce e il più lento da eseguire, perché codificare un AVIF fermo significa eseguire una ricerca intra-frame AV1. Per un file è una pausa. Per una cartella di duecento icone convertita in un colpo è un’attesa vera, ed è il processore dell’utente che lavora invece di un server.

Vale la pena pesarlo rispetto al risultato in byte invece che separatamente. Spendere tempo reale di encoding, a ogni build, per rendere ciascuna icona il doppio è uno scambio sbagliato in entrambe le direzioni insieme.

Un ICO contiene lo stesso marchio a più taglie e un AVIF contiene un’immagine sola, quindi qualcosa deve scegliere. Il decodificatore di icone del browser lo fa, e restituisce la voce più grande — verificato costruendo un file con disegni da 16, 32, 48 e 256 pixel in quattro colori diversi e convertendolo con la directory scritta in tre ordini diversi.

Il tetto è 256 pixel, fissato dal formato ICO invece che da AVIF, che arriva a 65.536. Quindi l’input dell’encoder è sempre un’immagine piccola, che è la condizione in cui ogni formato efficiente rende peggio rispetto a PNG.

AVIF può memorizzare dodici bit per canale e un gamut ampio, che è uno dei suoi vantaggi reali rispetto a WebP e JPEG per fotografia e materiale ad alta gamma dinamica. Un file icona memorizza otto bit per canale in un gamut standard e lo ha sempre fatto.

Quindi questa capacità è disponibile e inutilizzata. Non costa nulla direttamente, ma è un riassunto onesto della coppia: quasi tutto ciò in cui AVIF è migliore è qualcosa che un’icona non ha. L’unica proprietà che porta qui e conta — l’alpha — è una che PNG aveva già.

Ogni browser principale corrente decodifica AVIF, e lo fa da diversi anni. È abbastanza perché la maggior parte dei siti lo serva direttamente. È più nuovo di WebP, quindi la coda di client che non lo leggono è più lunga, e la risposta abituale è un elemento picture con una sorgente di fallback invece di una sostituzione netta.

Si noti cosa significa per un’icona: ora si distribuiscono due file invece di uno, e il fallback è il PNG che era più piccolo in partenza. La complessità è reale e il risparmio è negativo.

Una regola unica è attraente perché toglie una decisione da ogni build futura, e le regole uniche sui formati immagine di solito sono giuste. Questo è il caso in cui una non lo è. Si suddivida la regola per contenuto invece che per directory: fotografie e schermate in AVIF, opere piatte e icone in PNG, e si scriva il motivo accanto alla regola così la prossima persona non la «aggiusta».

Se la pipeline davvero non può esprimere due regole — alcune trasformazioni CDN non possono — allora convertire le icone è un costo difendibile dell’uniformità. Si sappia che è un costo, e si sappia quanto grande circa: un paio di kilobyte per icona, nella direzione sbagliata.

Si lasci cadere la cartella. Ogni file è decodificato e codificato per conto suo e i risultati tornano come ZIP, con un’impostazione di qualità per tutto il lotto. Ci si aspetti che richieda sensibilmente più tempo dello stesso lotto in PNG o WebP, per il motivo di cui sopra.

Le dimensioni non saranno uniformi a meno che il set sorgente non lo fosse. Collezioni di icone mescolano file che portano una voce da 256 pixel con file che si fermano a 32, e poiché i costi fissi dell’encoder pesano di più quanto più l’immagine è piccola, i membri da 32 pixel del set sono dove AVIF si comporta peggio in assoluto.

Due cose vale la pena guardare, e nessuna delle due richiede tempo. La prima è il conteggio dei byte di entrambi i file fianco a fianco, perché quello è il numero per cui la migrazione è stata intrapresa ed è quello che più probabilmente sarà ipotizzato invece che misurato. La seconda è il marchio stesso alla taglia a cui sarà effettivamente mostrato — non ingrandito, dove gli artefatti lossy sembrano allarmanti e nessuno li vedrà mai, e non come miniatura, dove tutto sembra a posto.

Si conservi comunque il file icona originale. È l’unica cosa che conserva ancora le piccole voci disegnate a mano, è pochi kilobyte, ed è ciò che un browser continuerà a richiedere dalla radice del sito indipendentemente da ciò che il build produce, anche se la build produce un AVIF fianco a fianco. Un’icona eliminata dalla root è un errore che solo il test su un browser reale rivela.