Convertire BMP in WebP

Un bitmap da 1920 per 1080 è 6,2 MB, ed è 6,2 MB che si tratti di una fotografia o di un banner piatto, perché il formato scrive tre byte per pixel e non ne comprime nessuno. Mettetelo su una pagina ed è la pagina: tutto il resto — l’HTML, il CSS, i font, gli script — è un errore di arrotondamento accanto ad esso.

WebP è stato progettato esattamente per questa posizione in una pagina. Spende bit dove c’è dettaglio e niente dove non c’è, il che è il motivo per cui la stessa immagine arriva in decine o centinaia di kilobyte invece. La conversione non è un’ottimizzazione al margine; è la differenza tra una pagina che carica su un telefono e una che non lo fa. È anche la differenza tra una misurazione di largest-contentful-paint che passa e una che non può, poiché su una pagina con un’immagine in cima è l’immagine ciò che la misurazione sta cronometrando.

WebP può essere senza perdite — il formato porta entrambe le modalità, e questo è uno dei motivi per cui esiste. Il codificatore su questa pagina scrive la variante con perdita, a qualità 82 per predefinito, perché è ciò che un’immagine pubblicata dovrebbe essere.

Vale la pena essere chiari su questo, perché significa che la conversione non è reversibile. Se ciò che volevate davvero era una copia esatta del bitmap in un contenitore più piccolo, questa è la pagina sbagliata e il PNG è quella giusta. Se l’immagine va su un sito web, con perdita è la risposta corretta e il numero di qualità è l’unica cosa a cui pensare — e 82 è abbastanza alto che la maggior parte delle persone non distingue il risultato dalla sorgente a dimensione normale. Il posto dove spendere attenzione non è la manopola ma le dimensioni, che è due sezioni sotto e conta considerevolmente di più.

WebP porta un canale alfa, e ne porta uno anche in modalità con perdita — il che è insolito, ed è la singola ragione più forte per sceglierlo rispetto a JPG per questa sorgente. Niente in questa conversione appiattisce l’immagine o vi chiede un colore di sfondo, perché niente deve farlo.

La maggior parte dei file BMP è a 24 bit e non ha alfa da conservare, quindi per loro il punto è irrilevante. Ma le varianti a 32 bit ne portano uno, e un logo o un elemento di interfaccia esportato da uno strumento Windows più vecchio è esattamente il tipo di file che ce l’ha. Inviato a JPG, quella trasparenza diventa bianca — e su questo sito, senza nemmeno la scelta di quale bianco. Inviato a WebP, resta trasparenza, a 256 livelli anziché l’unico valore acceso-o-spento che la GIF vi darebbe, quindi un bordo anti-aliased sfuma ancora correttamente contro qualunque cosa la pagina metta dietro.

Questo è un limite rigido del formato piuttosto che un limite di questo convertitore, ed è l’unica cosa che può rendere la conversione impossibile invece che solo con perdita. Nessuna dimensione di un WebP può superare 16.383 pixel.

Le immagini ordinarie sono molto lontane da ciò — una fotografia da 4000 per 3000 ha un sacco di margine. Ciò che lo raggiunge sono le cose che arrivano come BMP: un grande documento scannerizzato ad alta risoluzione, un panorama cucito insieme, un’uscita da uno strumento scientifico che produce una striscia molto larga. Se il vostro bitmap è uno di quelli, riducete prima la larghezza o usate PNG, il cui tetto è oltre due miliardi di pixel per lato e quindi teorico. Vale la pena verificare le dimensioni prima di convertire un lotto, perché un singolo file che non può diventare un WebP è un esito molto più confusionario di uno che esce più grande del previsto.

WebP è uscito da Google nel 2010 e ha speso il suo primo decennio con un asterisco accanto. Questo è finito: è in ogni browser attuale, è specificato in RFC 9649, e gli strumenti di grafica e contenuto lo leggono come una cosa ovvia.

Il che cambia su cosa verte la decisione su questa pagina. Non è più se il pubblico può vedere l’immagine — è solo se con perdita è accettabile per questa immagine particolare. È una domanda molto più facile, e per qualsiasi cosa pubblicata la risposta è di solito sì. Il registro dà a WebP lo stesso valore di supporto del browser che dà a JPG e PNG: tutti. AVIF, l’alternativa più recente, è ancora marcato come moderno, e quella singola parola è la differenza pratica tra i due quando si sceglie cosa spedire senza un fallback.

L’errore più comune in questa direzione è convertire un bitmap alle sue dimensioni originali e metterlo in una colonna da 600 pixel. Il browser poi scarica svariate volte i dati che può mostrare e scarta il resto, e nessuna impostazione del codec lo recupera.

Impostate la larghezza massima alla più larga in cui l’immagine verrà mai resa, raddoppiata se deve restare nitida su uno schermo ad alta densità. Il ridimensionamento avviene nello stesso passaggio di canvas di tutto il resto qui, quindi l’immagine viene scalata una volta invece di due, e il risparmio è proporzionale al conteggio dei pixel piuttosto che alla larghezza — dimezzare la larghezza toglie tre quarti dei dati.

Una gran parte dei file BMP sono catture dello schermo, e i codificatori con perdita trattano il testo male — i bordi duri del testo sono esattamente il contenuto ad alta frequenza che sono costruiti per scartare. Questo è un argomento forte contro JPG per questo materiale e uno più debole contro WebP, che gestisce i bordi netti meglio alla stessa impostazione ma non li rende gratuiti.

Per uno screenshot che deve essere leggibile, la classifica onesta è PNG prima, poi WebP a una qualità alzata, poi JPG molto più indietro. Il PNG sarà spesso il file più piccolo anche, dato che le regioni piatte e i bordi netti sono ciò che la compressione senza perdite sa fare meglio e ciò che la compressione con perdita fa peggio — quindi su questo materiale il compromesso abituale non si applica nemmeno. Per una fotografia, WebP a 82 senza regolazioni è la risposta giusta e la classifica non conta.

Il registro non elenca alcun contenitore di metadati per BMP: niente EXIF, niente XMP, nessun profilo ICC incorporato. WebP può portare tutti e tre, e non c’è niente nella sorgente da riempirli.

Per un’immagine web è per lo più comodo — il file è piccolo quanto i pixel permettono e non porta nulla che identifichi da dove è venuto. Conta se il bitmap proveniva da una pipeline con gestione del colore e ci si aspettava fosse interpretato in uno spazio particolare, perché il WebP sarà letto come sRGB e niente su questo percorso dice altrimenti.

Lasciate cadere la cartella. Ogni bitmap è decodificato e ricodificato a turno sulla vostra macchina, mantiene il suo nome file con l’estensione cambiata, e l’intero insieme torna come un unico ZIP. Non c’è coda, non c’è account e non c’è limite giornaliero, e il tetto per file è 100 MB.

Farlo in locale conta qui più della velocità. Immagini per un sito non ancora lanciato, fotografie di prodotti sotto embargo, screenshot di uno strumento interno — tutto ciò verrebbe altrimenti consegnato a terzi in cambio di un passaggio di compressione che si esegue in proprio.

Ogni file convertito mantiene il suo nome originale con l’estensione cambiata, che è ciò che rende utilizzabile un lotto ma è anche dove il lavoro non è finito. Ogni riferimento al vecchio file — in un template, in un foglio di stile, in una voce di contenuto, in un manifest — punta ancora a un nome che finisce in .bmp, e un’immagine mancante è un fallimento più visibile di una grande.

L’altra metà è ricordarsi di rimuovere i bitmap da qualunque cosa venga distribuita. Una build che copia interamente una directory di risorse spedirà entrambe le copie, il che significa che il repository cresce, la distribuzione cresce, e i megabyte che questa conversione doveva rimuovere stanno ancora venendo trasferiti da qualche parte. Convertite, aggiornate i riferimenti, eliminate gli originali dal progetto, e tenete i bitmap fuori da esso se sono gli unici master che avete.