Representación de subpíxeles para un rastreador de rayos


16

En la representación de fuentes, es común utilizar la representación de subpíxeles . La idea básica aquí es dividir el píxel en sus componentes RGB y luego calcular un valor para cada uno por separado. Como cada componente es más pequeño que el píxel completo, es posible un antialiasing de mayor calidad.

Obviamente, hay una manera análoga de hacer lo mismo para un rastreador de rayos. Realiza el filtrado de reconstrucción en cada subcanal por separado.

Me sorprendió que, sin embargo, realmente no pude encontrar referencias a los trazadores de rayos haciendo esto. Especialmente si ya está haciendo representación espectral, esto parece algo obvio. Hay un artículo de una revista de la que nunca he oído hablar, que parece estar relacionado. Pero, en general, la representación de subpíxeles simplemente no parece ser algo común. Mi pregunta: ¿por qué no ?


¿Se verán bien sus imágenes renderizadas en subpíxeles si se ven en pantallas con orientación vertical?
jamesdlin

como ingeniero, nunca estaría de acuerdo en implementar una ... idea tan rota. EXCEPTO si estoy seguro de que la pantalla está totalmente fija. como una aplicación para iPhone 5S. El uso de esta técnica genera imágenes rotas de pantallas que usan patrones invertidos o diferentes arreglos.
v.oddou

Respuestas:


14

Esto es perfectamente posible

Aunque la diferencia puede no ser especialmente notable, esperaría que el muestreo tuviera en cuenta la geometría exacta del píxel para dar una imagen un poco más precisa. Solo necesita compensar sus centros de píxeles por componente de color de acuerdo con la ubicación (promedio) de los subpíxeles de ese color. Tenga en cuenta que no todos los diseños de píxeles tienen una correspondencia uno a uno entre píxeles y subpíxeles.

Por ejemplo, penTile RGBG tiene el doble de subpíxeles verdes que rojo y azul, como muestra esta imagen de Wikipedia:

Cerrar imagen de geometría de píxeles RGBG

No conozco ninguna razón técnica que impida que esto se use para producir imágenes arbitrarias a todo color. De hecho, una escena colorida tendrá artefactos de color menos notables que el texto en negro sobre blanco, lo que hace que las diferencias de color sean más difíciles de camuflar.

Las fuentes se representan bajo demanda

La diferencia relevante entre renderizar una escena con trazado de rayos y renderizar fuentes es que las fuentes tienden a renderizarse a pedido y pueden tener en cuenta la pantalla que se está utilizando. En contraste con esto, una escena con trazado de rayos a menudo se presenta previamente y luego se muestra en muchos tipos diferentes de pantalla (con diferente geometría de píxeles). Por ejemplo, mostrar su imagen con trazado de rayos en una página web evitará adaptarla a un tipo de monitor específico.

Si estaba diseñando un programa de trazado de rayos en tiempo real y tenía acceso para verificar la geometría de píxeles del monitor, entonces podría trazar hasta el diseño de subpíxeles específico. Sin embargo, el trazado de rayos fuera de línea que produce una imagen fija solo se puede adaptar a un solo tipo de geometría de píxeles, lo que hará que la imagen se vea peor en cualquier otra geometría de píxeles. Podría solucionar este problema renderizando un conjunto de imágenes diferentes y eligiendo la apropiada cuando luego se muestre en un tipo particular de monitor.

Es poco probable que haya un beneficio a largo plazo

Por lo tanto, no hay ninguna razón por la que no pueda desarrollar la representación de subpíxeles para un trazador de rayos, pero significa tener en cuenta un aspecto del monitor que no siempre se conoce. Otra cosa a tener en cuenta es que desarrollará este software para un mercado cada vez más reducido. La representación de subpíxeles es útil para pantallas que tienen una resolución relativamente baja. A medida que más y más pantallas (incluso pantallas móviles) se acercan a una resolución tan alta que el ojo humano no puede detectar la diferencia que representa la representación de subpíxeles, es probable que su trabajo tenga más interés teórico que el uso práctico.


3
Jugando al abogado del diablo, si es posible hacer renderizado de subpíxeles en color (¡soy un escéptico!), Parece que podría ser útil en situaciones de realidad virtual, donde luchan por tener una resolución suficiente. ¿Quizás también en teléfonos o mesas (¿no retina?)?
Alan Wolfe

1
@AlanWolfe sí, pero también es 3 veces más caro de renderizar
joojaa

Sí, claro, eso es cierto. Sin embargo, hay algunas situaciones en las que eso no es un problema. Por ejemplo, conozco un par de algoritmos en los que no es necesario disparar rayos por cada píxel en cada cuadro. Parece que esto también podría jugar en gráficos rasterizados por cierto. Una vez más, no estoy convencido de que la representación de subpíxeles de color sea real, pero ya sabes, ¡SI! : P
Alan Wolfe

@AlanWolfe No entiendo tus dudas. Todas las imágenes ya están renderizadas con subpíxeles, pero los colores están desalineados entre un tercio y medio píxel. No puedo ver cómo corregir esa desalineación no produciría una imagen de mayor calidad. ¿Tiene alguna inquietud específica (que podría ser una buena pregunta ...)?
trichoplax

3
@joojaa No hay razón para que sea 3 veces más caro renderizar. No necesitarías disparar 3 veces la cantidad de rayos; simplemente aplicaría 3 pesos diferentes al acumular los rayos en el framebuffer. Efectivamente, está utilizando un núcleo antialiasing diferente para cada canal de color.
Nathan Reed

9

Claro, puede usar la representación de subpíxeles para imágenes arbitrarias. Sin embargo, la representación de subpíxeles es realmente una técnica genérica de procesamiento de imágenes 2D: no tiene nada que ver específicamente con el trazado de rayos. También podría usarlo con cualquier otro método de renderizado 3D, o incluso con un simple dibujo 2D, fotografía o incluso video.

Por lo tanto, diría que la "representación de subpíxeles para el trazado de rayos" realmente combina dos dominios de problemas distintos que se tratan mejor por separado. La única conexión relevante es que, si está trazando un rayo en la escena en tiempo real y sabe que la imagen resultante se dibujará en la pantalla usando la representación de subpíxeles, puede usar esta información para optimizar la densidad de píxeles (y el aspecto relación) de la imagen intermedia (por ejemplo, usando una densidad de píxeles horizontal de 3x para una pantalla LCD RGB típica).


Una posible fuente de confusión puede ser que, en el sistema informático actual, la representación de subpíxeles se usa comúnmente solo para texto, y generalmente se integra en el código de representación de fuente. Las principales razones para esto son posiblemente históricas, pero también es donde generalmente se encuentran los mayores beneficios (en términos de mejora visual y legibilidad).

Además, debido a la forma en que el texto tiende a consistir en formas vectoriales simples y repetitivas, la integración de la representación de subpíxeles en el renderizador de fuentes ofrece algunas oportunidades de optimización adicionales con solo representar el texto en un búfer de alta resolución y luego procesarlo posteriormente.

Dicho esto, espero que con el tiempo, a medida que la tecnología madure, nos trasladaremos a un sistema en el que la GPU, o posiblemente la pantalla en sí, realice la representación de subpíxeles de forma transparente.

(Esto probablemente requerirá aplicaciones que quieran hacer un uso completo de esta función para manejar píxeles físicos que son más pequeños y no necesariamente la misma forma que los "píxeles lógicos". Pero, de nuevo, ya nos estamos moviendo en eso dirección con pantallas de alta DPI.)


Tervetuloa! Sí, su punto es válido, diría que el sistema o el hardware tiene que hacer esto, ya que solo el sistema puede ser consciente en el futuro de la orientación de la pantalla y la organización de los colores en la pantalla. Preferiblemente, la pantalla misma haría esto.
joojaa
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.