Pull to refresh

Comments 14

От неадаптивного (тупо тональной кривой) не сохраняющего локальный контраст tone mapping — пользы чуть меньше чем нисколько.
У локальных алгоритмов тоже свои проблемы есть, при неаккуратном обращении вылезают различные артефакты, вроде гало. Видел статью про тон мэппинг в god of war, там пришлось скопировать настраиваемые алгоритмы из адобовского лайтрума, которые очень хорошо работают, и все равно были артефакты, ради которых пришлось делать специальные источники освещения, влияющие на тонмэппинг (https://bartwronski.com/2016/08/29/localized-tonemapping/).

Да и зрительная система человека проводит слишком мудреную работу при наблюдении реальной сцены, идеально ее смоделировать очень сложно. И к тому же, очень часто тон мэппинг относится вообще к ответственности художника по освещению, потому что разная коррекция ведет к разному ощущению от сцен. Это я все к тому, что при отсутствии ясной художественной цели обычный глобальный тон мэппинг вполне подойдет, разве что среднюю яркость по сцене учесть бы надо, ну и вообще если уж работать в hdr, то яркость источников неплохо было бы привязать к реальным физическим параметрам, хотя бы примерным, а не к магическим константам вроде 1, 5 или 15
У локальных алгоритмов тоже свои проблемы есть

«Волга впадает в Каспийское море»

P.S. наши реализации адаптивного мапинга работают без видимых артефактов в 1080р 30 fps (на выходе, входной fps 100) видео, поэтому я считаю, что имею некоторое представление о предмете.
Немного не понял про 100 и 30 фпс, если честно. Это перекодирование видео из 100 фпс в 30, реалтайм обработка генерируемого на ходу видеопотока, которая ест по 3 кадра или еще что-то?
Вы так много понаписали, что поставили меня в ложное положение — я-то подумал было, что вы знаете хотя бы азы HDR и мне не нужно будет растолковывать хотя бы это.
Ну зачем же сразу так грубо, как будто я вас тут обидеть хочу. Где здесь связь между hdr и fps? Если речь о видео потоке, то причем тут вообще фпс. Если про реалтайм рендер, то обычно как-то принято в милли/микросекундах давать время работы, но 23 миллисекунды на тонмэп это крайне щедрый бюджет получается. Отсюда и вопрос, что конкретно вы имеете ввиду.
Спаибо, за статью, взял шейдер к себе. Немоглибы вы ссылки про реализацию адаптивного hdr?
P/S/
Почему то не найду хорошей статьи, возможно я плохо ищу, в любом случае спасибо! Жаль что мало))

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

При создании текстуры можно передать параметр GL_SRGB, и тогда обратная гамма-коррекция будет делаться автоматически.

Нет, тогда будет применяться прямая коррекция при записи в неё и обратная при чтении. Этот формат надо использовать для текстур материалов, но не для рендер таргетов. Чтобы сделать гамму верной, надо в последнем шейдере пайплайна возвести цвет в правильную степень.

Этот формат надо использовать для текстур материалов, но не для рендер таргетов.

Да, я про текстуры материалов и писал. Похоже, получилось не совсем понятно. Идея:


  1. Для текстуры указывается формат SRGB
  2. openGL при чтении из этой текстуры сделает обратное преобразование и возвратит уже линейные значения яркости
  3. Мы на основе этих значений в линейном пространстве как-то рассчитываем освещение
  4. Рисуем сцену в floating point фреймбуфер, потому что значения могут быть большими.
  5. Читаем значения из floating point буфера, ужимаем их в интервал от 0 до 1, вручную делаем гамма-коррекцию (после гамма-коррекции мы всё равно останемся в интервале от 0 до 1) и пишем результат в обычный фреймбуфер.
Чтобы сделать гамму верной, надо в последнем шейдере пайплайна возвести цвет в правильную степень.


Либо так, либо
glEnable(GL_FRAMEBUFFER_SRGB)
для последнего фреймбуфера.
Хорошая статья, только опечатка
из диапазана [0.0..0.1],
Sign up to leave a comment.

Articles