ПрограммированиеФорумГрафика

Пару вопросов о Bloom (3 стр)

Страницы: 1 2 3
#30
4:46, 19 июня 2019

}:+()___ [Smile]
а, я понял, что ты имеешь в виду. здесь особенность может быть в том, что нет стандартизованного соотношения srgb-яркости пикселя с реальной яркостью, которая зависит от яркости подсветки. в результате если ты надеешься, что блум для света, попавшего в LDR диапазон, произойдёт автоматически внутри глаза, то это вовсе не всегда будет так, если у юзера просто установлены низкие настройки яркости на мониторе. поэтому, мне кажется, здесь важнее получить консистентную картинку, даже если блум считается дважды, чем надеяться на подобные особенности монитора.

это как если картину рисуешь маслом, например, то по факту она вообще не светится без стороннего освещения, как по-твоему тогда контролировать яркость блума на ней? да никак, просто изображается, как бы глаз воспринял эту сцену при определённой экспозиции, и всё равно, что изображённый блум будет складываться с реальным блумом. картина маслом — конечно, тот ещё аналог при разговоре о pbr, но суть ясна.

#31
5:33, 19 июня 2019

Suslik
> это вовсе не всегда будет так, если у юзера просто установлены низкие настройки яркости на мониторе
Вот как раз блум в глазе абсолютно линейный, ему пофигу на яркость.

> это как если картину рисуешь маслом, например, то по факту она вообще не светится без стороннего освещения, как по-твоему тогда контролировать яркость блума на ней?
Если взять правильную норму (с насыщением ошибки от одного пикселя), то, вроде, оптимальное решение не будет сильно зависеть от конкретного значения порога обрезания.

Но, вообще, блур картинки низкой интенсивности слабо заметен, поэтому в первом приближении, действительно, можно блурить все целиком. Интересно будет попробовать четко сформулировать задачу оптимизации и честно ее решить, возможно получится самый ТруЪ PBR блум.

#32
5:45, 19 июня 2019

}:+()___ [Smile]
> Вот как раз блум в глазе абсолютно линейный, ему пофигу на яркость.
имеется в виду, что если в кадре яркий источник света (но в пределах LDR яркости), то ожидается видеть вокруг него блум даже если у монитора очень низкая яркость. в твоём же подходе ты полагаешься только на естественный блум в глазу, который из-за низкой яркости монитора будет еле заметен.

}:+()___ [Smile]
> Но, вообще, блур картинки низкой интенсивности слабо заметен, поэтому в первом
> приближении, действительно, можно блурить все целиком. Интересно будет
> попробовать четко сформулировать задачу оптимизации и честно ее решить,
> возможно получится самый ТруЪ PBR блум.
для этого необходимо знать не только кривую преобразования линейной яркости в srgb, но и преобразование srgb в яркость пиксела на экране (с учётом яркости монитора) и преобразование яркости монитора в воспринимаемую яркость глазом, которая ещё и зависит от текущей экспозиции глаза. если первая ступень преобразования ещё имеет какой-то смысл, вторую реализовать уже очень трудно технически, а третью — просто невозможно, потому что она опирается на субъективное биологическое состояние. поэтому все забивают и притворяются, что в самом глазу при обзоре монитора блума нет (то есть изображение на экране имеет достаточно низкую интенсивность).

#33
10:10, 19 июня 2019

А вообще дядя Суслик неправ :) он делает много интересных вещей, а скриншоты от Ашота сюда не выкладывает ))) а потом пишет, что баловался и заново писать не собирается...

#34
10:31, 19 июня 2019

Daniil Petrov
> А вообще дядя Суслик неправ :) он делает много интересных вещей, а скриншоты от
> Ашота сюда не выкладывает ))) а потом пишет, что баловался и заново писать не
> собирается...
https://www.youtube.com/watch?v=MQ8EC5aw-mA&feature=youtu.be&t=6

#35
10:41, 19 июня 2019

Misanthrope
https://youtu.be/DZHXRy-FTuM?t=4186

#36
10:57, 19 июня 2019

Daniil Petrov
на самом деле там весь интерес в том, как считать свёртку изображения с очень широким ядром. то есть как посчитать, например, блюр радиусом 500 пикселей используя 20 чтений из текстуры на пиксель или вроде того.

#37
11:01, 19 июня 2019

Suslik
> то есть как посчитать, например, блюр радиусом 500 пикселей используя 20 чтений из текстуры
деды даунсемплили, но cегодня видимо это уже не православный метод ))

#38
11:07, 19 июня 2019

Misanthrope
> деды даунсемплили
Ты слабых людей не обижай :) они даунов называют «солнечными детьми» ))) загорели видать от радиации...

#39
11:10, 19 июня 2019

Misanthrope
> деды даунсемплили, но cегодня видимо это уже не православный метод ))
так-то да, но если всё считать даунсемпленное, то результирующий блум будет иметь форму размазанной кляксы. более правильно для этого использовать importance sampling и каждую выборку делать из мип-уровня, соответствующего плотности распределения семплов. это не я придумал, если что, сами можете поискать в гугле по запросу "bloom mipmap" / "a-trous wavelet transform bloom" или вроде того.

#40
11:45, 19 июня 2019

Suslik
о, я что-то похожее делал, но для DOF

даже не знал, что оно название имеет как importance sampling
Как-то само в голову пришло

#41
15:29, 19 июня 2019

Suslik
> в твоём же подходе ты полагаешься только на естественный блум в глазу, который из-за низкой яркости монитора будет еле заметен.
При яркостно-независимой норме ошибок (например, количество неправильных пикселей) оптимальный результат не меняется при одновременном масштабировании яркости картинки и порога монитора.

> преобразование srgb в яркость пиксела на экране (с учётом яркости монитора)
Это, вообще-то, стандартизовано. Тех, у кого криво настроенный монитор не учитываем.

> преобразование яркости монитора в воспринимаемую яркость глазом
На это можно забить при соответствующем выборе нормы.

В общем, вот четкая математическая постановка.
Дано поле яркостей \(I\), надо найти такой корректор к нему \(\Delta I\), чтобы выполнялось \(0\leq I+\Delta I\leq I_\max\) и норма ошибки \(E=\hat B\Delta I\) была минимальной (\(\hat B\) — оператор размытия в глазу). Норму ошибок лучше выбрать яркостно-независимой (количество неправильных пикселей = мера множества \(\{x|E(x)\neq0\}\)).

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

> как посчитать, например, блюр радиусом 500 пикселей
Гауссов блюр большого радиуса считается через даунсемпл + блюр + апсемпл.
Даун/апсемпл надо делать не тупым усреднением четырех пикселей, а с подходящим ядром (для 8-бит точности достаточно [1 5 10 10 5 1]). Центральный блюр тоже желательно делать с правильно рассчитанными коэффициентами.

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

#42
20:45, 27 июня 2019

hdr bloom без выделения ярких участков норм заработал.
Правда я не парился с ядром, взял гауса, потом смешал по хитрой формуле.

Страницы: 1 2 3
ПрограммированиеФорумГрафика

Тема в архиве.