Renderização de subpixel para um Ray Tracer

Na renderização de fontes, é comum usar a renderização de subpixel . A idéia básica aqui é dividir o pixel em seus componentes RGB e depois calcular um valor para cada um separadamente. Como cada componente é menor que o pixel inteiro, é possível um antialiasing de maior qualidade.

Existe uma maneira obviamente análoga de fazer o mesmo para um traçador de raios. Você faz a reconstrução da filtragem em cada subcanal separadamente.

Fiquei surpreso que, no entanto, eu realmente não conseguia encontrar referência a traçadores de raios fazendo isso. Especialmente se você já está fazendo uma renderização espectral, isso parece óbvio. Há este artigo de um diário que eu nunca ouvi falar e que parece estar relacionado. Mas, em geral, a renderização de subpixel não parece ser uma coisa comum a se fazer. Minha pergunta: por que não ?

Isso é perfeitamente possível

Embora a diferença possa não ser especialmente perceptível, eu esperaria que a amostragem levando em consideração a geometria exata do pixel para fornecer uma imagem um pouco mais precisa. Você só precisa deslocar seus centros de pixel por componente de cor de acordo com a localização (média) dos subpixel (s) dessa cor. Observe que nem todos os layouts de pixels têm uma correspondência de um para um entre pixels e subpixels.

Por exemplo, o penTile RGBG possui o dobro de subpixels verdes que vermelho e azul, como mostra esta imagem da Wikipedia:

Não conheço nenhum motivo técnico que impeça que isso seja usado para produzir imagens arbitrárias em cores. De fato, uma cena colorida terá artefatos de cores menos perceptíveis que o preto no texto branco, o que dificulta a camuflagem das diferenças de cores.

As fontes são renderizadas sob demanda

A diferença relevante entre renderizar uma cena traçada por raios e renderizar fontes é que as fontes tendem a ser renderizadas sob demanda e podem levar em consideração a tela que está sendo usada. Em contraste com isso, uma cena traçada por raios é frequentemente pré-renderizada e exibida em muitos tipos diferentes de tela (com geometria de pixel diferente). Por exemplo, exibir sua imagem rastreada por raios em uma página da Web impedirá adaptá-la a um tipo de monitor específico.

Se você estava projetando um programa de rastreamento de raios em tempo real e teve acesso para verificar a geometria de pixels do monitor, poderia traçar um raio para o layout específico de sub pixels. No entanto, o traçado de raios offline que produz uma imagem estática só pode ser adaptado a um único tipo de geometria de pixels, o que tornará a imagem pior em qualquer outra geometria de pixels. Você pode contornar isso renderizando um conjunto de imagens diferentes e escolhendo a apropriada quando mais tarde for exibida em um tipo específico de monitor.

É improvável que haja um benefício a longo prazo

Portanto, não há motivo para você não desenvolver a renderização de subpixels para um raytracer, mas isso significa levar em consideração um aspecto do monitor que nem sempre é conhecido. Outra coisa a ter em mente é que você estará desenvolvendo este software para um mercado em retração. A renderização de subpixels é útil para telas com resolução relativamente baixa. À medida que mais e mais telas (até telas móveis) se aproximam de uma resolução tão alta que o olho humano não consegue detectar a diferença feita pela renderização sub pixel, é provável que seu trabalho seja mais de interesse teórico do que de uso prático.

Claro, você pode usar a renderização de subpixel para imagens arbitrárias. No entanto, a renderização de subpixel é realmente uma técnica genérica de processamento de imagem 2D - não tem nada a ver especificamente com o traçado de raios. Você também pode usá-lo com qualquer outro método de renderização em 3D, ou mesmo com um simples desenho em 2D, fotografia ou até vídeo.

Assim, eu diria que "a renderização de subpixel para rastreamento de raios" está realmente confluindo dois domínios de problemas distintos que são melhor tratados separadamente. A única conexão relevante é que, se você estiver traçando os raios da cena em tempo real e souber que a imagem resultante será desenhada na tela usando a renderização de subpixel, você pode usar essas informações para otimizar a densidade de pixels (e o aspecto relação) da imagem intermediária (por exemplo, usando densidade de pixels horizontal de 3x para uma tela LCD RGB típica).

Uma fonte potencial de confusão pode ser que, no sistema de computador atual, a renderização de subpixel seja comumente usada apenas para texto e normalmente seja integrada ao código de renderização da fonte. As principais razões para isso são sem dúvida históricas, mas também é onde estão os maiores retornos (em termos de melhoria visual e legibilidade).

Além disso, devido à maneira como o texto tende a consistir em formas vetoriais simples e repetitivas, a integração da renderização subpixel no renderizador de fontes oferece algumas oportunidades de otimização extras, além de renderizar o texto em um buffer de alta resolução e depois processá-lo.

Dito isso, espero plenamente que, com o amadurecimento da tecnologia, mudaremos para um sistema em que a renderização de subpixel é simplesmente feita de forma transparente pela GPU, ou possivelmente pela própria tela.

(Isso provavelmente exigirá que os aplicativos que desejam fazer uso completo desse recurso lidem com pixels físicos menores e não necessariamente da mesma forma que os "pixels lógicos". Mas, novamente, já estamos nos movendo nesse sentido. direção com telas de alto DPI.)