Comments 25
Всегда думал что «фотошоповское» свечение — лишь гауссовское размытие с выбранным наложением без сохранения информации о цвете.
Там есть 2 режима. Один гаусом, называется soft (мягкий), а второй — точный
Решил проверить.
Причем банальный гаусс на фоне отличается от мягкого свечения, не могли бы вы вкратце описать и принцип «мягкого?» Или это тот же самое, лишь с допущениями?
Причем банальный гаусс на фоне отличается от мягкого свечения, не могли бы вы вкратце описать и принцип «мягкого?» Или это тот же самое, лишь с допущениями?
Поиграл с мягким. Похоже на то, что мягкий свет нужно делать в 2 раза больше чем гаус + потом размытие по гаусу нужно нормализовать уровнями. Во всяком случае у меня получилось очень похоже:
правая нижняя Н — по гауссу.
Результаты могут немного отличаться, потому что гауссовское размытие смазало белые пиксели с красными. В случае если мы будем смазывать только красные пикели — такого не будет (может даже нормализация не будет нужна). Так что я думаю мягкий свет — это все таки гауссовское размытие + нормализация.
правая нижняя Н — по гауссу.
Результаты могут немного отличаться, потому что гауссовское размытие смазало белые пиксели с красными. В случае если мы будем смазывать только красные пикели — такого не будет (может даже нормализация не будет нужна). Так что я думаю мягкий свет — это все таки гауссовское размытие + нормализация.
Есть предположение, что и в мягком используется размытие, только с другим режимом наложения, скорее всего по формуле soft light. Уж больно сильные различия между режимами.
Подскажите, что за программа изображена на скриншоте?
Это узловой редактор в Blender3D. Но он работает не только с 3D-сценами, но и с обычными изображениями и видео. Кстати, вот пример чуть более сложного свечения через блюр.
А тут не получится применить свёртку через быстрое преобразование фурье?
Буду рад если подскажите как. Я в матане слабоват, в плане применения его как инструмента программирования. Навсякий случай погуглил, но так и не понял как свертка мне поможет.
Так же подумал, когда дочитал до микрооптимизаций и эвристик.
Это не операция свёртки, поэтому в частотном домене не получится сделать.
Поглядите в сторону distance transform и приближенных вычислений. Там все можно очень быстро за один проход реализовать.
Я может глупость скажу, но может банальный обход в ширину спас бы отца русской демократии?
Складываем все существующие точки в очередь, достаем по одной, закрашиваем еще не обработанных соседей и кладем их обратно в очередь (тоже только еще не тронутых ранее, конечно).
Один проход по всем пикселям (ну два, если учесть начальный сбор существующих пикселей), быстрее некуда.
Складываем все существующие точки в очередь, достаем по одной, закрашиваем еще не обработанных соседей и кладем их обратно в очередь (тоже только еще не тронутых ранее, конечно).
Один проход по всем пикселям (ну два, если учесть начальный сбор существующих пикселей), быстрее некуда.
Неверное решение, из-за метрики. Как этот целочисленный алгоритм получит расстояние sqrt(5) для сдвига на 2 пикселя вправо и 1 вниз от границы изображения? А если мы пришли в ту же точку из другой точки границы за 3 хода влево — ходов столько же, а расстояние должно быть другое.
Это значит, что если мы покрасили пиксель раньше, не факт, что он в евклидовой метрике ближе к изображению. Значит, при заходе на пиксель придётся сравнивать расстояния и иногда перекрашивать уже покрашенный (и добавлять в очередь), т.е. не один проход делать.
Это значит, что если мы покрасили пиксель раньше, не факт, что он в евклидовой метрике ближе к изображению. Значит, при заходе на пиксель придётся сравнивать расстояния и иногда перекрашивать уже покрашенный (и добавлять в очередь), т.е. не один проход делать.
Тогда надо брать квадрат расстояния, и обходить по модифицированному алгоритму Дейкстры (т.н. «Дейкстра с хипом»).
UPD:
Оценка времени — O(|E| log |V|), то есть O(hw (log h + log w)), где h и w — размеры изображения.
Оценка времени алгоритма автора: O(hw + td (l + d)), где h и w — размеры изображения, d — дистанция glow, t — число изолированных контуров, l — средняя длина контура.
Алгоритм автора эффективен, когда t << hw/d2, но проигрывает при t >> hw (log h + log w) / d2. Самый страшный случай — решетка из изолированных точек.
Оценка времени — O(|E| log |V|), то есть O(hw (log h + log w)), где h и w — размеры изображения.
Оценка времени алгоритма автора: O(hw + td (l + d)), где h и w — размеры изображения, d — дистанция glow, t — число изолированных контуров, l — средняя длина контура.
Алгоритм автора эффективен, когда t << hw/d2, но проигрывает при t >> hw (log h + log w) / d2. Самый страшный случай — решетка из изолированных точек.
<зануда>Ужасный шрифт. Пожалуйста, не используйте его больше.</зануда>
Преобразованные таким образом картинки используют для рисования типа-векторных картинок в игрушках.
Вот статья:
www.valvesoftware.com/publications/2007/SIGGRAPH2007_AlphaTestedMagnification.pdf
Вот статья:
www.valvesoftware.com/publications/2007/SIGGRAPH2007_AlphaTestedMagnification.pdf
Если у нас glow на 100 пикселей, то нам надо для каждого пикселя изображения проверить 100*100 соседних пикселей.
Если реализовать через разделяемый матричный фильтр, то достаточно двух проходов по массиву с общим чтением в 200 пикселей на каждый пиксель, а не 10000.
www.songho.ca/dsp/convolution/convolution.html#separable_convolution
Sign up to leave a comment.
Честный glow и скорость