Images 2.6 è più veloce. Ma il tempo che conta è quello delle correzioni

OpenAI annuncia Images 2.6 e mette sul tavolo un numero che funziona benissimo in una presentazione: generazione delle immagini più rapida del 50%. È un dato dichiarato dal produttore, non il risultato di un benchmark indipendente. E soprattutto non risponde alla domanda che interessa chi deve mettere una grafica in produzione: quanto tempo serve per arrivare a un risultato corretto, ripetibile e modificabile?

La novità interessante non è soltanto la velocità. OpenAI introduce due varianti API, GPT-Image-2.6 Flare e Sunburst, porta l’editing con markup nell’API, aggiunge esportazione SVG e un parametro di complexity. Sono leve che permettono di costruire una pipeline meno dipendente da un unico prompt. Ma una leva di controllo non è automaticamente una garanzia di qualità.

La metrica sbagliata: secondi per immagine

Supponiamo di confrontare due configurazioni. La prima restituisce una bozza in sei secondi, ma richiede cinque rigenerazioni e due interventi manuali. La seconda impiega più tempo per ogni generazione, ma consegna una composizione utilizzabile al secondo tentativo. Se misuriamo soltanto il tempo della singola richiesta, la prima vince. Se misuriamo il tempo fino all’approvazione, potrebbe perdere nettamente.

Per valutare Images 2.6 in un progetto reale, distinguerei almeno quattro indicatori: latenza per richiesta, percentuale di asset accettati senza correzioni, fedeltà alle istruzioni e stabilità degli elementi che non devono cambiare tra revisioni. A questi si aggiunge il costo complessivo per asset approvato, non il solo prezzo della chiamata API. Sono metriche di progetto, non numeri forniti da OpenAI.

Flare e Sunburst non sono una classifica

Secondo l’annuncio ufficiale, Flare privilegia l’iterazione rapida e può generare immagini in appena sei secondi con qualità low. Sunburst punta invece a maggiore dettaglio e coerenza delle immagini tra modifiche, specialmente con qualità medium o high. Queste descrizioni suggeriscono due ruoli differenti nella stessa lavorazione: esplorazione e rifinitura. Non dimostrano che una variante sia sempre migliore dell’altra.

Un test sensato usa gli stessi brief, un insieme di seed o casi equivalenti, criteri di accettazione definiti prima e più tentativi. Si registrano tempo totale, interventi correttivi e difetti ricorrenti: testo errato, proporzioni incoerenti, dettagli di prodotto modificati, composizione non conforme. Il confronto va fatto sul risultato finale, non sul render più spettacolare selezionato per la demo.

Complexity e qualità sono due controlli diversi

OpenAI distingue esplicitamente il parametro complexity dalla qualità dell’immagine: il primo governa quanto lavoro di pianificazione viene dedicato alla richiesta; la seconda riguarda dettaglio e fedeltà visiva. Per modifiche semplici il produttore raccomanda complexity low, mentre scene con numerosi vincoli possono richiedere medium o high. La conseguenza pratica è che un valore massimo impostato ovunque non costituisce una strategia di ottimizzazione.

Una pipeline seria dovrebbe scegliere la configurazione in base alla fase: anteprima, correzione locale, esportazione finale. E dovrebbe conservare prompt, parametri, asset di partenza e versione del modello, così da poter spiegare perché una grafica è cambiata. Senza tracciabilità, il tempo guadagnato in generazione rischia di essere perso nel debugging visivo.

SVG e markup: più controllo, più responsabilità

L’esportazione SVG apre una possibilità utile per interfacce, siti e materiali stampati. Ma il fatto che un file sia vettoriale non garantisce che sia leggero, semanticamente organizzato o compatibile con un design system. Un SVG destinato al web va comunque controllato: dimensioni, viewBox, complessità dei tracciati, testo, accessibilità, sicurezza dei contenuti e resa responsive.

Allo stesso modo, il markup per indicare le zone da modificare rende più precisa la richiesta, ma la verifica deve includere anche ciò che avrebbe dovuto restare invariato. Correggere un dettaglio di un prodotto e alterarne un altro non è un successo di editing. È una regressione. Per chi sviluppa software, il concetto dovrebbe essere familiare: ogni modifica richiede un test del comportamento atteso e uno di non regressione.

E le GIF?

Images 2.6 aggiunge la generazione di GIF animate. Per la comunicazione visiva è una funzione interessante, ma la valutazione non può fermarsi al movimento. Una sequenza deve mantenere coerenti soggetto, sfondo, illuminazione e proporzioni, e deve evitare salti percettibili tra i fotogrammi. Per l’uso web contano inoltre peso, durata e accessibilità; in alcuni contesti un video compresso o un’animazione CSS possono essere alternative più appropriate.

Il modello genera. Il sistema decide se il risultato è pronto

La direzione di Images 2.6 è significativa: meno generazione come evento isolato, più controlli per inserirla in processi ripetibili. Ma la responsabilità del risultato rimane nella pipeline che costruisci intorno al modello. Se un’immagine deve rispettare un brand, entrare in un catalogo o diventare un componente UI, servono criteri di accettazione, controlli sulle revisioni e un modo per rifare il lavoro senza affidarsi alla memoria di chi ha scritto il prompt.

Il benchmark che conta non è quanto velocemente compare la prima immagine. È quante immagini corrette riesci a consegnare, con quante correzioni, a quale costo e con quale capacità di spiegare il risultato. Tutto il resto è una demo.