Convertire HEIF in WebP

Le piattaforme di pubblicazione convalidano gli upload contro una lista, e HEIF raramente è sopra. Sembra arbitrario finché non si considera cosa la piattaforma deve fare dopo: generare un’anteprima, produrre tre taglie responsive e mostrare un’anteprima nell’editor. Non può fare in modo affidabile nessuna di queste con un formato il cui supporto dei browser è parziale, quindi la cosa più sicura che può fare è rifiutare il file.

La conseguenza è che la conversione è compito dell’utente invece che della piattaforma, e farla prima dell’upload è meglio che dopo. Si controllano le dimensioni e la qualità; il ricodificatore automatico della piattaforma, se ne ha uno, sta lavorando da qualunque cosa gli sia stata data.

Google ha pubblicato WebP nel 2010 e ora è standardizzato come RFC 9649. Ciò che lo rende il default per questo lavoro non è l’ingegnosità della compressione ma la copertura: è uno dei pochi formati immagine su questo sito il cui supporto dei browser è registrato come completo invece che moderno o parziale, quindi un singolo file funziona per ogni visitatore senza un fallback.

Porta anche le due cose di cui un formato di distribuzione ha bisogno e JPEG manca — un canale alpha e compressione migliore alla stessa qualità visibile. Per una pagina che deve caricarsi su un telefono su una connessione lenta, quelle sono le due leve che contano, e WebP le ha entrambe senza chiedere a nessuno di negoziare content type.

La qualità parte da 82 su una scala da 1 a 100. Per fotografie su una pagina web è un buon punto in cui stare: il dettaglio sopravvive alla taglia che il browser mostrerà davvero, e il file è una frazione di ciò che una copia senza perdita costerebbe. Scendere nei sessanta compra byte veri e comincia a mostrarsi attorno ai bordi e nelle aree piatte.

Si ricordi che questa è la seconda compressione che l’immagine ha subito. La fotocamera l’aveva compressa in HEIF, e questa comprime ciò che ne è uscito. Un passaggio in più a 82 non è qualcosa che un visitatore noterà, ma è un motivo per convertire dall’HEIF originale ogni volta invece di riconvertire un WebP più tardi.

WebP non può descrivere un’immagine più grande di 16.383 pixel per lato. È una proprietà del formato, non di questo convertitore, e nessuna impostazione lo aggira. Una foto da dodici o quarantotto megapixel è ben sotto in entrambe le direzioni, quindi per le immagini normali il limite non si presenta mai.

Quello che si presenta è una panoramica. Le modalità panoramica del telefono cuciono un’immagine molto larga e bassa, e quelle superano di routine i sedicimila pixel in larghezza. Per una di quelle, si fissi una larghezza massima prima di convertire — cosa che quasi certamente si voleva fare comunque, dato che nessuna pagina web mostra un’immagine a quella larghezza.

Il campo di larghezza massima è il controllo più prezioso in questa pagina per un uso sul web. Ridurre una foto da 4.032 pixel a 1.600 taglia i dati che l’encoder riceve a circa un sesto prima che la compressione cominci, e 1.600 è già generoso per un’immagine di contenuto in un layout desktop.

Servire una fotografia a piena risoluzione e lasciare che il browser la riduca è l’errore di peso di pagina più comune: il visitatore paga per ognuno di quei pixel e ne vede forse un quinto. Se servono parecchie taglie per un set responsive, si converta il HEIF parecchie volte a larghezze diverse invece di ridimensionare il WebP dopo.

Entrambi i formati hanno un canale alpha, quindi un’immagine con sfondo pulito arriva com’era e può stare su una sezione colorata della pagina senza una scatola bianca attorno.

Entrambi i formati supportano anche l’animazione, e quella parte non attraversa. Il decodificatore prende l’immagine primaria dal contenitore HEIF e l’encoder scrive un singolo fotogramma, quindi un HEIF multi-immagine diventa un’unica immagine. Se la sorgente è davvero una sequenza che si vuole mantenere in movimento, questa non è la coppia giusta.

Il WebP scritto qui non contiene EXIF né XMP. Nulla è stato filtrato; la conversione decodifica l’immagine in pixel grezzi e la ricodifica, e i metadati non hanno un percorso che attraversi quel passaggio.

Su una pagina sulla pubblicazione, questa è la cosa più utile. Una foto scattata con un telefono è di norma marcata con latitudine e longitudine accurate all’indirizzo di una via, e un annuncio su un marketplace o un post su un blog che le porta pubblica dove vive il fotografo. Diverse piattaforme grandi le rimuovono all’upload e diverse no; convertire prima significa non doversi fidare di quale delle due si sta affrontando.

AVIF comprime la stessa immagine più piccola alla stessa qualità visibile, e il suo supporto dei browser è più nuovo di quello di WebP invece che universale. Questo è tutto il confronto, e si decide da solo in base a come il sito serve le immagini.

Se si carica un file e viene servito a tutti, WebP è la risposta — nessuna negoziazione, nessun fallback, nulla da testare. Se il proprio strato di distribuzione può offrire AVIF ai browser che lo annunciano e WebP al resto, allora AVIF vale il passaggio in più e c’è una pagina separata per quella conversione. Scegliere AVIF come formato unico perché è più nuovo è il modo in cui un visitatore si ritrova un’immagine rotta.

Sia il decodificatore HEIF che l’encoder WebP girano dentro la scheda del browser, sul processore dell’utente. Non c’è upload, coda o account, e il file non esiste mai sul server di nessuno — il che, per scatti di prodotto non pubblicati e fotografie di persone che non hanno acconsentito a nulla, è la differenza che conta.

Il livello gratuito accetta fino a 100 MB per file, a cui nessuna foto da telefono si avvicina. Un’intera cartella si converte in un solo passaggio con una riga di avanzamento ciascuna, e una volta che due file sono pronti compare un pulsante «tutto come ZIP», quindi preparare trenta immagini per una galleria è un download solo invece di trenta.

Si conservi il HEIF. È la copia di qualità più alta che si ha, è la più piccola che si ha, e ogni futura taglia o formato di cui si ha bisogno dovrebbe essere fatto da quello invece che dal WebP pubblicato.

Non c’è nemmeno modo di tornare indietro: questo sito sa leggere HEIF e non sa scriverlo, perché l’encoder che servirebbe è sotto una licenza che un sito statico non può soddisfare. Quindi il WebP è un derivato e il HEIF è l’originale, e vale la pena archiviarli così invece di cancellare quello che non può essere ricreato, anche se WebP definisce una modalità senza perdita che non è quella che questa coppia scrive.