Convertire WebM in WebP

Un’immagine destinata a una pagina web viene giudicata con criteri diversi da una destinata a un documento. Nessuno la aprirà in un visualizzatore: sarà una delle venti cose che un browser scarica mentre qualcuno decide se restare. Il suo peso in kilobyte è un costo reale pagato da ogni visitatore, e il suo formato deve essere uno che il CMS, il processo di build e il browser accettano senza gestioni speciali.

È tutto l’argomento a favore del WebP sul JPG in questo contesto. Stesso risultato visibile, circa il trenta per cento di byte in meno, e supporto universale nei browser attuali. Su una griglia di dodici miniature di tutorial è un terzo del peso delle immagini tolto senza cambiamento visibile e senza markup di riserva — il tipo di ottimizzazione che sopravvive al contatto con un progetto reale.

WebP e WebM nascono dallo stesso lavoro. Google li ha rilasciati entrambi intorno al 2010 come risposte libere da royalty a formati gravati da brevetti, e la compressione dell’immagine fissa di WebP è cresciuta dalla codifica intra-frame di VP8, il codec video su cui è costruito WebM. Estrarre un fotogramma da un WebM e scriverlo come WebP somiglia più a una parentela di famiglia che a una traduzione.

Questo non rende la conversione senza perdita, e vale la pena dirlo perché nessuno se lo aspetti. Il fotogramma viene decodificato ai pixel e ricodificato da zero, a una qualità fissa di 82. Ciò che compra la parentela è che il tipo di dettaglio che il codec video conservava è lo stesso tipo che il codificatore d’immagine sa conservare bene, per cui i fermo-immagine WebP da video reggono meglio di quanto i numeri da soli suggeriscano.

La cosa più utile da fare con questa conversione è anche la più ovvia una volta vista: prendere un fotogramma dal WebM e usarlo come `poster` di quel video. Un browser mostra il poster finché la riproduzione non comincia, quindi la prima immagine che le persone vedono è un fermo-immagine reale del video invece di un rettangolo nero o una foto stock scollegata.

Prendetelo da circa un secondo dentro il video, non da zero. Il primissimo fotogramma di una registrazione è spesso una dissolvenza, uno stato vuoto o una pagina ancora in caricamento, ed è anche il fotogramma che il video dipingerà nell’istante in cui parte — quindi un poster preso un momento dopo dà allo spettatore qualcosa da guardare senza produrre un salto visibile all’avvio. Il secondo zero regala il fotogramma meno interessante del file e un poster che duplica quello.

Il fotogramma esce alle dimensioni in pixel del video stesso, senza scalatura. Una registrazione a 1080p produce un WebP di 1920 per 1080; una cattura in 4K uno di 3840 per 2160. È deliberato — un fotogramma ha una risoluzione reale e il compito di questa conversione è consegnarlo intatto invece di indovinare una dimensione di visualizzazione.

Il ridimensionamento appartiene a un passo successivo della catena. Qualunque cosa generi il vostro `srcset` reattivo, la pipeline immagini del vostro CMS o il vostro processo di build sa già quali larghezze servono al layout, e farà un lavoro migliore partendo da una sorgente a piena risoluzione piuttosto che da una già ridotta. Prendete qui la versione più grande e onesta e lasciate che sia chi conosce il layout a fare le piccole.

L’immagine dentro un WebM è stata codificata per il movimento. Un codec video spende i suoi bit dove le cose si muovono e risparmia dove restano ferme, assumendo che nessun singolo fotogramma verrà fissato a lungo. Fermarne uno significa fare esattamente ciò che il codec presumeva che nessuno avrebbe fatto.

L’effetto pratico su una miniatura è piccolo, perché una miniatura viene mostrata a una frazione della sua dimensione nativa e il ridimensionamento verso il basso nasconde bene la morbidezza. Conta quando il fermo-immagine viene usato grande — un’immagine hero, un’illustrazione a piena larghezza — dove un fotogramma preso durante una panoramica o uno scorrimento sembrerà visibilmente sfocato accanto al resto della pagina. La soluzione è l’istante: trovate un momento in cui l’immagine è ferma, e prendetelo da lì.

I browser non sono più il problema; la coda lunga sta altrove. Alcuni client di posta non renderizzano il WebP, quindi una miniatura per una newsletter dovrebbe essere un JPG. Diverse applicazioni desktop più vecchie, flussi di stampa e alcuni moduli di invio ancora rifiutano il formato. Windows e macOS lo mostrano entrambi in anteprima ormai, cosa non vera fino a pochi anni fa e origine di gran parte dei consigli superati che circolano.

Dentro un browser è sicuro trattare il WebP come universale, ed è ciò che lo rende la scelta pragmatica rispetto all’AVIF. Se la destinazione è qualcosa di diverso da una pagina web — un’email, un documento, una stampante, un modulo — prendete il JPG e non pensateci più.

Una libreria di tutorial ha bisogno di una miniatura ciascuno, e questo significa una conversione per video, non una per fotogramma. Convertite, annotate l’istante che ha funzionato, passate al file successivo. L’intero ciclo dura pochi secondi perché nulla viene caricato fra un tentativo e l’altro e non c’è coda.

Vale la pena scegliere gli istanti deliberatamente invece di accettare zero per tutti. Una griglia di miniature che mostrano tutte un editor vuoto o un indicatore di caricamento non dice a un visitatore quale video sia quale, ed è esattamente ciò che produce prendere il fotogramma predefinito da ogni file.

Le registrazioni che hanno bisogno di fotogrammi poster sono di solito quelle non ancora rilasciate: una demo di prodotto, il percorso di una funzione, un modulo di un corso. Caricare l’intero video su un convertitore perché restituisca una miniatura da 60 KB è molta esposizione per un lavoro molto piccolo.

Decodifica e codifica avvengono entrambe nella scheda, usando codec che il browser possiede già per riprodurre WebM. Nulla che porti il video viene inviato, non c’è account e non c’è limite giornaliero — il che significa anche che convertirne trenta è la stessa operazione trenta volte, non un motivo per aggiornare qualcosa.