Lezione 04

Il training: la scena è il modello

Perché il 3DGS «si addestra»: analysis-by-synthesis, gradienti attraverso il renderer, densificazione.

Il problema inverso

Nel 3DGS non hai geometria misurata: hai fotografie calibrate $\{I_k, \pi_k\}$ e una nuvola sparsa di inizializzazione. La domanda si rovescia: trova la scena $\Theta$ tale che, renderizzata dalle camere note, riproduca le foto:

$$\Theta^* = \arg\min_\Theta \sum_k \mathcal{L}\big(R(\Theta;\pi_k),\, I_k\big), \qquad \mathcal{L} = (1-\lambda)\,\mathcal{L}_1 + \lambda\,(1-\text{D-SSIM})$$

I parametri $\Theta = \{\mu_i, s_i, q_i, \alpha_i, c_i\}_{i=1..N}$ sono latenti: dalle foto non puoi misurare la covarianza di una gaussiana o i suoi coefficienti SH. Puoi solo stimarli — e siccome il renderer (lezione 03) è differenziabile, la stima è discesa del gradiente: il gradiente della loss fotometrica risale dai pixel fino a ogni singola gaussiana. Per la posizione, ad esempio:

$$\frac{\partial \mathcal L}{\partial \mu_i} = \sum_{p}\; \underbrace{\frac{\partial \mathcal L}{\partial R(p)}}_{\text{residuo}} \cdot \underbrace{c_i\, w_i(p)\,\frac{(p-\mu_i')}{\sigma_i^2}}_{\text{dal kernel gaussiano}}$$

È fitting statistico in piena regola: le foto sono i dati di training, la generalizzazione è la novel view synthesis (si misura su viste held-out), l'overfitting sono i floaters — gaussiane che spiegano perfettamente le viste di training da posizioni 3D sbagliate.

Provalo: 2D Gaussian Splatting nel browser

Qui sotto c'è un vero ottimizzatore, scritto in JavaScript: un'immagine target 96×96 viene ricostruita da gaussiane 2D isotrope i cui parametri $(\mu_i, \sigma_i, c_i)$ partono quasi a caso e vengono aggiornati con Adam sui gradienti analitici della MSE. Premi addestra e guardalo convergere; premi densifica quando la loss ristagna.

target $T$

render $R(\Theta)$

loss (scala log)

mostra le gaussiane (cerchi a 1σ)

Fig. 1 — interattiva. Rendering additivo per semplicità ($R(p)=\sum_i c_i\,e^{-\|p-\mu_i\|^2/2\sigma_i^2}$) invece del compositing con trasmittanza della lezione 03 — la meccanica del gradiente è identica. Nota come le gaussiane migrano, si allargano e si stringono per spiegare l'immagine: nessuna è stata «misurata», sono tutte stimate.

Densificazione = ricerca d'architettura

Il bottone densifica replica l'adaptive density control del 3DGS: ogni ~100 iterazioni l'ottimizzatore cambia il numero di parametri — clona o divide le gaussiane dove il gradiente posizionale accumulato è alto (il residuo «chiede» capacità lì), pota quelle trasparenti. In termini di representation learning è model selection greedy contestuale all'ottimizzazione, parente stretto del matching pursuit: aggiungi atomi al dizionario dove il residuo è grande. (La riformulazione elegante è 3DGS-MCMC: densificazione e pruning come mosse di sampling.)

La differenza, in tabella

	Splatting tradizionale (EWA, ~2001)	3DGS (2023)
Natura	tecnica di rendering (resampling)	rappresentazione appresa (problema inverso)
Input	geometria misurata (scanner + normali)	foto calibrate + init sparsa
Parametri	derivati dai dati (densità, normali)	latenti, ottimizzati end-to-end
Colore	fisso per punto	SH view-dependent, appreso
# primitive	= numero di campioni	dinamico (densify/prune)
Qualità misurata da	anti-aliasing, continuità	loss fotometrica su viste held-out
Modi di fallimento	buchi, blur	floaters (overfitting), speculari
Nel nostro repo	producer `splat` (stub)	producer `gsplat` (test sulla box GPU)

Predizione per il nostro test — il modello sarà forte dentro l'envelope dei viewpoint di training (lungo la traiettoria registrata: il nostro caso d'uso!) e degraderà fuori: con 300 pose su ~0.9 m di cammino, le novel view lontane dal path mostreranno floaters. Non è un bug: è varianza da dataset piccolo. Anche per questo l'init dalla nostra nuvola conta: il paesaggio è non-convesso e il gradiente è locale — partire vicino al bacino giusto è metà del lavoro.