Rendering subpixel per un Ray Tracer

Nel rendering dei caratteri, è comune utilizzare il rendering subpixel . L'idea di base qui è quella di suddividere il pixel nei suoi componenti RGB e quindi calcolare un valore per ciascuno separatamente. Poiché ogni componente è più piccolo dell'intero pixel, è possibile un antialiasing di qualità superiore.

Esiste un modo ovviamente analogo di fare lo stesso per un ray tracciante. Esegui il filtro di ricostruzione su ciascun canale secondario separatamente.

Sono rimasto sorpreso dal fatto che, tuttavia, non sono riuscito a trovare un riferimento ai ray tracer che lo facevano. Soprattutto se stai già eseguendo il rendering spettrale, questa sembra una cosa ovvia da fare. C'è questo articolo di un diario di cui non ho mai sentito parlare e che sembra essere collegato. Ma nel complesso, il rendering subpixel non sembra essere una cosa comune da fare. La mia domanda: perché no ?

Questo è perfettamente possibile

Anche se la differenza potrebbe non essere particolarmente evidente, mi aspetto che il campionamento tenga conto dell'esatta geometria dei pixel per dare un'immagine leggermente più accurata. Devi solo compensare i tuoi pixel center per componente di colore in base alla posizione (media) dei sottopixel di quel colore. Si noti che non tutti i layout di pixel hanno una corrispondenza uno a uno tra pixel e sottopixel.

Ad esempio, penTile RGBG ha il doppio dei sottopixel verdi rispetto al rosso e al blu, come mostra questa immagine di Wikipedia:

Non sono a conoscenza di alcun motivo tecnico che impedisca che questo venga utilizzato per produrre immagini arbitrarie a colori. In effetti una scena colorata avrà artefatti cromatici meno evidenti rispetto al testo nero su bianco, il che rende le differenze cromatiche più difficili da camuffare.

I caratteri sono resi su richiesta

La differenza rilevante tra il rendering di una scena raytracing e il rendering dei caratteri è che i caratteri tendono a essere renderizzati su richiesta e possono tenere conto dello schermo utilizzato. In contrasto con questo, una scena raytracing viene spesso prerenderizzata e quindi visualizzata su molti diversi tipi di schermo (con diversa geometria dei pixel). Ad esempio, la visualizzazione dell'immagine raytracing su una pagina Web impedisce di adattarla a un tipo di monitor specifico.

Se stavi progettando un programma di raytracing in tempo reale e avessi accesso per controllare la geometria dei pixel del monitor, allora potresti raytrace per il layout specifico sub pixel. Tuttavia, il raytracing offline che produce un'immagine fissa può essere personalizzato solo per un singolo tipo di geometria dei pixel, il che renderà l'immagine peggiore su qualsiasi altra geometria dei pixel. È possibile aggirare questo problema eseguendo il rendering di una serie di immagini diverse e scegliendo quella appropriata quando verrà successivamente visualizzata su un particolare tipo di monitor.

È improbabile che ci sia un beneficio a lungo termine

Quindi non vi è alcun motivo per cui non sia possibile sviluppare il rendering dei pixel secondari per un raytracer, ma significa tenere conto di un aspetto del monitor che non è sempre noto. Un'altra cosa da tenere a mente è che svilupperai questo software per un mercato in contrazione. Il rendering dei pixel secondari è utile per schermi con una risoluzione relativamente bassa. Poiché sempre più schermi (anche schermi mobili) si stanno avvicinando a una risoluzione così alta che l'occhio umano non è in grado di rilevare la differenza fatta dal rendering dei pixel secondari, è probabile che il tuo lavoro sia più di interesse teorico che pratico.

Certo, puoi usare il rendering subpixel per immagini arbitrarie. Tuttavia, il rendering subpixel è in realtà una tecnica di elaborazione di immagini 2D generica - non ha nulla a che fare con il ray tracing in particolare. Potresti anche usarlo con qualsiasi altro metodo di rendering 3D, o anche con un semplice disegno 2D, una fotografia o persino un video.

Pertanto, direi che il "rendering subpixel per il ray tracing" sta realmente combinando due distinti domini problematici che sono meglio trattati separatamente. L'unica connessione rilevante è che, se stai ray tracing la scena in tempo reale e sai che l'immagine risultante verrà disegnata sullo schermo usando il rendering subpixel, puoi usare queste informazioni per ottimizzare la densità dei pixel (e l'aspetto rapporto) dell'immagine intermedia (ad es. utilizzando una densità di pixel orizzontale 3x per un tipico schermo LCD RGB).

Una potenziale fonte di confusione potrebbe essere che, sul sistema informatico attuale, il rendering subpixel è comunemente usato solo per il testo ed è tipicamente integrato nel codice di rendering dei caratteri. Le ragioni principali di ciò sono probabilmente storiche, ma è anche il luogo in cui si trovano generalmente i maggiori profitti (in termini di miglioramento visivo e leggibilità).

Inoltre, a causa del modo in cui il testo tende a consistere in forme vettoriali semplici e ripetitive, l'integrazione del rendering subpixel nel renderer dei caratteri offre alcune opportunità di ottimizzazione aggiuntive rispetto al semplice rendering del testo in un buffer ad alta risoluzione e quindi alla successiva elaborazione.

Detto questo, mi aspetto pienamente che alla fine, man mano che la tecnologia matura, passeremo a un sistema in cui il rendering subpixel viene semplicemente eseguito in modo trasparente dalla GPU o, eventualmente, dallo schermo stesso.

(Ciò richiederà molto probabilmente applicazioni che vogliono sfruttare appieno questa funzione per gestire pixel fisici più piccoli e non necessariamente della stessa forma dei "pixel logici". Ma, di nuovo, ci stiamo già muovendo direzione con schermi ad alto DPI.)