Se nel primo articolo abbiamo parlato di architettura e file, adesso entriamo nella parte che fa la differenza tra “l’immagine è brutta” e “l’immagine è quello che volevo”. Ed è qui che scopri una cosa fastidiosa: la qualità di un’immagine generata non è un bottone, è una danza tra quattro parametri che si influenzano a vicenda.
La lezione che ho imparato dal design di Private Vision è che non puoi nascondere questa complessità all’utente, puoi solo renderla meno spaventosa. E per farlo devi prima capire cosa significa ogni singolo parametro.
Il formato: perché i multipli di 64?
Cominciamo dalla cosa più semplice che nasconde un’intera architettura sotto: la risoluzione dell’immagine.
SDXL è addestrato principalmente su immagini 1024×1024. Ma puoi generare anche a 768×768, 512×512, o a 1024×576 (panoramica), o 576×1024 (verticale). La vincola è una sola, entrambe le dimensioni devono essere multipli di 64.
Perché 64? Perché la rete neurale usa convoluzioni, filtri che riducono progressivamente la risoluzione. Se parti da 1024 e applichi convoluzioni, ottieni 512, poi 256, poi 128, poi 64. Se avessi iniziato da 513 (un numero random dispari), a metà strada avresti numeri che non si dividono più, e la rete inizierebbe a comportarsi male, non errori evidenti, solo degradazione silenziosa della qualità.
Quindi nella configurazione di Private Vision ho lasciato che l’utente scegliesse il formato, ma solo da una lista di opzioni “sicure”:
DIMENSIONI_SUPPORTATE = [
(512, 512),
(768, 768),
(1024, 1024),
(1024, 576),
(576, 1024),
(1280, 960), # se hai memoria extra
]Questo non è un limite del software, è un vincolo della geometria del modello. Accettarlo piuttosto che cercarlo di aggirare è la differenza tra un’applicazione che funziona e un’applicazione che funziona in silenzio male.
La regola empirica per la memoria: ogni dimensione extra costa memoria. Se hai una GPU da 8GB come me, 1024×1024 è il massimo ragionevole. Se scendi a 768×768, generi un po’ più veloce. Se sei su una GPU da 24GB, puoi permetterti 1280×1024 e non pensi più al problema.
Step: il compromesso velocità-qualità
Gli “step” sono il numero di iterazioni che il modello fa per trasformare il rumore in immagine finale. Immagina di levigare una roccia con la carta vetrata, ogni passata la leviga un po’ di più. Con una passata sola rimane ruvida. Con cento passate è perfetta, ma hai perso tre giorni.
SDXL di base preferisce 20-50 step per un buon risultato. A 20 step la generazione è veloce (3-5 secondi su GPU decente). A 50 step è più raffinata ma impiega 8-12 secondi. Oltre i 50, i diminishing return diventano visibili, ottieni il 5% di miglioramento per il 40% di tempo in più.
Ma questa è una finzione che funziona solo se non sai che esistono checkpoint speciali. Turbo, Lightning, LCM, che sono stati addestrati specificamente per ottenere risultati decenti in 4-8 step. Sono come la versione economica del viaggio: meno dettagli, ma 10 volte più veloce.
Il colpo insidioso è qui: se usi i parametri di default su un checkpoint specializzato, i risultati diventano peggiori. In config.py, ho dovuto decidere:
DEFAULT_STEPS = 30 # per checkpoint SDXL standard
DEFAULT_GUIDANCE_SCALE = 7.5 # per checkpoint SDXL standardMa nel commento ho messo una nota nera: “Se usi un checkpoint Turbo/Lightning, cambia questi a 5-8 step e guidance scale 2-3”. Non è un’automazione, l’utente deve sapere cosa sta facendo. E qui scopri il primo insegnamento sul design… non è tuo compito decidere al posto dell’utente. È tuo compito permettergli di decidere bene.
Guidance Scale: quanto il modello deve seguire il prompt
Immagina di dare istruzioni a un disegnatore. Se dici “disegna una montagna”, lui ha libertà interpretativa, magari la fa classica, magari stilizzata, magari strana. Se dici “disegna una montagna, ESATTAMENTE come spiego”, lui non respira, non si muove, disegna alla lettera.
La Guidance Scale è questa intensità di obbedienza.
- Scale 0: il modello ignora il prompt. Genera immagini casuali.
- Scale 7-10: il sweetspot, segue il prompt abbastanza da riconoscerlo, ma ha libertà creativa.
- Scale 15+: il modello ubbidisce troppo, e cominciano gli artefatti, distorsioni, texture strane, effetti allucinogeni indesiderati.
Il valore di default che ho scelto (7.5) è il compromesso più sicuro. Ma diversi checkpoint hanno preferenze diverse, uno potrebbe amare 5, un altro potrebbe avere bisogno di 10 per dare il meglio. La tentazione, quando disegni l’interfaccia, è di nascondere questo parametro. “L’utente non vuole saperne di Guidance Scale, vuole un’immagine bella.” Ma la realtà è che se un’immagine esce brutta, la prima cosa che prova l’utente esperto è toccare questo slider. Quindi lo esponi, lo spieghi in una tooltip, e gli permetti di sperimentare.
Sampler: le strade diverse verso lo stesso risultato
Qui entriamo in un territorio dove anche io devo ammettere che la matematica che ci sta dietro è complessa. Ma il concetto è semplice, il sampler decide come il rumore viene rimosso passo dopo passo.
Immagina di dover andare da A a B. Puoi prendere l’autostrada, la strada secondaria, la mulattiera. Tutte ti portano là, ma hanno tempi diversi e vedute diverse.
I sampler comuni sono:
- DPM++ 2M — il più lento ma spesso il più bello.
- Euler — veloce, buon compromesso.
- DDIM — il classico, affidabile ma spesso meno interessante.
- Ho dato a Private Vision l’opzione di sceglierli, ma di default ho messo il più affidabile per SDXL. Aggiungere opzioni raramente è sbagliato, è renderle spiegate il vero sfida.
Nella UI, accanto a ogni sampler c’è una breve descrizione. Non “DPM++”, ma “DPM++ — più lento, dettagli migliori”. Non perfetto, ma mille volte meglio che lasciare l’utente a cercare su internet.
Seed: il controllo del caos
L’ultimo parametro nasconde un principio profondo, il determinismo nel caos.
Ogni volta che generi un’immagine, il modello inizia con numeri casuali. Se non specifichi il seed, ogni generazione è diversa. Ma se specifichi un seed (un numero qualunque), lo stai dicendo al generatore: “Partiamo da questo punto casuale, non da uno random”. Stesso seed + stessi parametri = stessa immagine, sempre.
Questo risolve un problema pratico, se generi un’immagine che ti piace al 90% e vuoi solo cambiare il prompt lievemente, puoi usare lo stesso seed e ottenere variazioni coerenti della stessa “base casuale”.
Il frontend di Private Vision mostra il seed usato accanto all’immagine, e permette di “ri-generare” una vecchia immagine usando gli stessi numeri. È una feature che non tira il sasso più lontano del campo, ma che semplifica il 20% di quello che l’utente fa 80% del tempo.
Il principio nascosto: opzioni sì, ma con guardrail
La tentazione del programmatore è sempre la stess,: aggiungere più slider, più controllo, più potenza. La tentazione del designer è l’opposta, nascondere tutto dietro un bottone “Genera”.
La verità è nel mezzo. Private Vision non è un’interfaccia full-featured come ComfyUI (dove hai decine di parametri esotici). Ma non è nemmeno un bottone unico. È una struttura di tre livelli:
- I default: clicchi “Genera” e succede qualcosa di sensato.
- Le opzioni comuni (risoluzione, step, guidance): spostate in primo piano, spiegate.
- Le opzioni avanzate (sampler, seed): dietro un tab “Avanzate”, non nascoste, ma non imponenti.
Quando la UI rimane semplice anche quando il sistema sottostante è complesso, hai vinto. E qui la complessità vera non è aggiungere slider, è decidere quali parametri mostrare e perché.
Se l’articolo ti è piaciuto restiamo in contattosu linkedin a: https://www.linkedin.com/in/andreatonin/
| Editorial Manager at Pills for Nerds | CTO & Technology Consultant |
Technology professional, editor and lifelong nerd with over 30 years of experience in the digital and innovation sectors. I work as a CTO and technology consultant, designing complex and scalable software ecosystems, and I am also active in IT education and professional training. Alongside my technology career, I serve as Editorial Manager and contributor at Pills for Nerds, online publication covering video games, game development, emerging technologies, artificial intelligence, digital culture and industry events. In my editorial role, I coordinate content planning and contribute articles, interviews, event reports and in-depth features. You can learn more about my consulting work at lucedigitale.com and connect with me on LinkedIn

















