Субпиксельный рендеринг для Ray Tracer

При рендеринге шрифтов обычно используют субпиксельный рендеринг . Основная идея здесь состоит в том, чтобы разбить пиксель на его компоненты RGB и затем вычислить значение для каждого отдельно. Поскольку каждый компонент меньше, чем весь пиксель, возможно более высокое качество сглаживания.

Существует очевидный аналогичный способ сделать то же самое для трассировщика лучей. Вы делаете фильтрацию реконструкции на каждом подканале отдельно.

Я был удивлен, что, однако, я не смог найти ссылку на трассировщики лучей, делающие это. Особенно, если вы уже делаете спектральный рендеринг, это кажется очевидной вещью. Есть такая статья из журнала, о которой я никогда не слышал, которая, кажется, имеет отношение. Но в целом субпиксельный рендеринг просто не кажется обычным делом. Мой вопрос: почему бы и нет ?

Это вполне возможно

Хотя разница может быть не особенно заметной, я ожидаю, что выборка с учетом точной геометрии пикселя даст немного более точное изображение. Вам просто нужно сместить центры пикселей для каждого компонента цвета в соответствии с (средним) расположением субпикселя (-ов) этого цвета. Обратите внимание, что не все макеты пикселей имеют однозначное соответствие между пикселями и подпикселями.

Например, penTile RGBG имеет в два раза больше зеленых подпикселей, чем красный и синий, как показано на этом изображении из Википедии:

Я не знаю ни одной технической причины, которая помешала бы этому использовать для получения произвольных полноцветных изображений. На самом деле цветная сцена будет иметь менее заметные цветовые артефакты, чем черный на белом тексте, что затрудняет маскировку цветовых различий.

Шрифты предоставляются по запросу

Соответствующее различие между рендерингом сцены с трассировкой лучей и шрифтами рендеринга заключается в том, что шрифты, как правило, отображаются по требованию и могут учитывать используемый экран. В отличие от этого, трассированная лучом сцена часто воспроизводится и затем отображается на многих экранах различных типов (с разной геометрией пикселей). Например, отображение вашего изображения с трассировкой лучей на веб-странице не позволит адаптировать его к монитору определенного типа.

Если вы разрабатывали программу трассировки лучей в реальном времени, и у вас был доступ к проверке геометрии пикселя монитора, то вы могли бы проследить трассировку лучей до конкретной схемы подпикселей. Тем не менее, в автономном режиме трассировки лучей , который производит неподвижное изображение может быть адаптирована только для одного типа геометрии пикселей, который затем сделает изображение хуже любой другой геометрии пикселей. Вы можете обойти это, визуализируя набор различных изображений и выбирая подходящее, когда оно позже будет отображаться на мониторе определенного типа.

Там вряд ли будет долгосрочная выгода

Таким образом, нет причины, по которой вы не могли бы разработать субпиксельный рендеринг для raytracer, но это означает, что необходимо учитывать аспект монитора, который не всегда известен. Еще одна вещь, которую нужно иметь в виду, это то, что вы будете разрабатывать это программное обеспечение для сокращающегося рынка. Субпиксельный рендеринг полезен для экранов с относительно низким разрешением. Поскольку все больше и больше экранов (даже мобильных экранов) приближаются к такому высокому разрешению, что человеческий глаз не может обнаружить разницу, получаемую при субпиксельном рендеринге, ваша работа, скорее всего, будет представлять больше теоретический интерес, чем практическое использование.

Конечно, вы можете использовать субпиксельный рендеринг для произвольных изображений. Однако субпиксельный рендеринг - это действительно общая технология обработки 2D-изображений - она ​​не имеет ничего общего с трассировкой лучей. Вы также можете использовать его с любым другим методом 3D-рендеринга или даже с простым 2D-рисунком, фотографией или даже видео.

Таким образом, я бы сказал, что «субпиксельный рендеринг для трассировки лучей» действительно объединяет две отдельные проблемные области, которые лучше всего рассматривать отдельно. Единственное уместное соединение заключается в том, что, если вы отслеживаете лучи сцены в реальном времени и знаете, что полученное изображение будет отображаться на экране с использованием субпиксельного рендеринга, вы можете использовать эту информацию для оптимизации плотности пикселей (и аспекта коэффициент) промежуточного изображения (например, с использованием 3-кратной горизонтальной плотности пикселей для типичного экрана RGB LCD).

Потенциальный источник путаницы может заключаться в том, что в современной компьютерной системе субпиксельный рендеринг обычно используется только для текста и обычно интегрируется в код рендеринга шрифта. Главные причины этого, возможно, исторические, но именно там, как правило, самые большие выгоды (с точки зрения визуального улучшения и читабельности).

Кроме того, благодаря тому, что текст состоит из простых и повторяющихся векторных фигур, интеграция субпиксельного рендеринга в средство визуализации шрифтов предлагает некоторые дополнительные возможности оптимизации по сравнению с простым рендерингом текста в буфер с высоким разрешением и последующей его обработкой.

Тем не менее, я полностью ожидаю, что со временем, по мере развития технологий, мы перейдем к системе, в которой субпиксельный рендеринг просто выполняется прозрачно с помощью графического процессора или, возможно, самого экрана.

(Скорее всего, это потребует приложений, которые хотят в полной мере использовать эту функцию, чтобы иметь дело с физическими пикселями, которые меньше, и не обязательно имеют ту же форму, что и «логические пиксели». Но опять же, мы уже движемся в этом направление с экранами с высоким разрешением.)