Комментарии 27
1. В такой статье обойтись без упоминания https://en.m.wikipedia.org/wiki/Central_limit_theorem ? Повторная свертка прямоугольников (бегущее среднее) очень быстро сходится к гауссиану.
Когда ошибка 10^-6, картинки показывать не нужно, они одинаковые
Глянул на годы выхода публикаций. Для меня это просто шок-контент ;-) Я был уверен, что все это придумано и описано лет на 50 раньше. Мы у себя в программе используем подобные трюки где-то с 1989г, когда у нас встал вопрос о скорости вычислений. Нам тогда и в голову не приходило, что в этом может быть какая-то новизна.. Единственное существенное отличие - у нас в сигналах присутствует много Nan-значений, которые приходится обрабатывать особо. Из-за них алгоритмы получаются совсем не такими красивыми, как у классиков :-( Ну и еще у нас временные ряды, то есть задачка во всех случаях исключительно одномерная.
Нет тут особой новизны. У меня тоже лет 20 назад были примерно такие же результаты как в статье( для feature detection DOG и похожих ) но на заметно более слабых компьютерах. Точные цифры не помню, надо посмотреть реализацию и замеры для точных цифр, но было быстрее чем open cv раз в пять Тут важно правильно заботиться о попадании в кеш
Тут важно правильно заботиться о попадании в кеш
Я тогда такого слова вообще не знал ;-)
Хотя, в начале 1990-х уже как бы появился 486 (с кэшем L1), но мы жили и работали в горной экспедиции, куда новая техника подъезжала с опозданием лет эдак на 10. Да и в институте (куда я вернулся после распада СССР) в 90-е было не сильно лучше. Приходилось выкручиваться на старом железе за счет алгоритмов. Так как как раз в это время наблюдения массово переводились на минутный опрос, и мегабайтные ряды у нас стали нормой.
Я уже про 20 лет назад говорю. Это пентиум 4 и дальше. А кеши появились уже у некоторых 80386 , это где то 1986 год
пока проверял, когда появились контроллеры кэша для 386го и как кэш был устроен, истекло время редактирования.
Вот про микросхему 82385, контроллер совмещнного кэша программ-данных для intel 80386 https://theretroweb.com/chips/3095
К ней требовались еще микросхемы быстрой статической памяти для хранения кэшируемых данных.
Первые экземпляры = 1987 год.
в таблице производительность в наносекундах на элемент или в миллисекундах на все изображение? явно не сказано, а кажется сомнительным что фильтр гаусса с сигмой 10 для FP32 изображения 1024х1024 можно посчитать на x86 процессоре за 81.3 нс
На точку конечно. 4 мегабайта данных только прочитать из памяти нужно порядка миллисекунды или сотен микросекунд (10-89 гигабайт в секунду)
1024x1024 уже в памяти - когда я жму на применить фильтр к картинке например в Гимп на ползунки X/Y фильтр применяется на всю картинку почти мгновенно, тут скорее всего время без загрузки картинки 1024х1024 и в примере чб(поидее это 1024х1024х2хsizeof(...) байт ) и еще процессор i9 в тесте написано по крайней мере (мне просто стало интересно я запустил Гимп создал чб 1024х1024(32FP) накалякал чтото там чтоб был чб и применил фильтр, плюс в Гимп может модный фильтр, тут пишут что способ Stack Blur разновидност Гаусса быстрее)
я представляю сколько работает фильтр гаусса в разных условиях, коммент больше направлен на улучшение описания. А то в таблице единица измерения указана не полностью, т.к. видимо это не просто время, это время на один элемент(пиксел) изображения.
единица измерения "почти мгновенно" улыбнула
допустим 1024 на 1024 на 2 канала частота 4 ГГц доступ к памяти 3МГЦ, допустим выборка окна 4 на 4 где 4 на 4 в лучшем случае на 2 канала в 1 регистр тогда за такт выполнится 1 к операций поидее ну допустим при 4 ГГЦ это 4 тысячи, 65536 / 4000 (просто предположил)
тут как чего не допускай, но за 81 наносекунду не может быть обработано 1048576 элементов (это 1024*1024), т.к. это около 77 фемто секунд на элемент получится (если арифметика меня не подвела или я ее) 81e-9 / (1024*1024). это ж процессор на терра герцах работать должен, какой бы он i9 ни был, но это пока рановато
у нас предположим 1 момент все изображение 1024х1024 - а следующий момент у нас маска выборка по изображению 256 на 256 элементов по 4 на 4 чтото такое. я тоже могу ошибаться просто почемуто подумал что так легче обсчитать если учесть что влезает в регистр маска(отталкивался от словосочетания частота дискретизации. )
Вы правы, наносекунды получатся, если оценивать время на пиксель изображения. В Таблице 2 приведено время обработки всего изображения, поэтому правильная единица измерения - миллисекунды. Спасибо, исправили в статье.
А со скоростью вычисления свертки с помощью преобразования Фурье вы свои свои алгоритмы не сравнивали?
Да, это сравнение мы тоже делали. Оно есть в статье, а здесь мы напишем про него в следующей части нашего материала. Спойлер: оказалось не быстрее.
Позвольте уточнить, а Вы гамма-коррекцию для изображений делали? Для float32 всё прекрасно, но в случае восьми бит на пиксель либо гамма коррекции нет и фильтр размывает физически некорректно, либо восемь бит с гамма-коррекцией теряют цвета и нужно повышать точность (например, до шестнадцати бит)
Главный подвох в том, что количество фотонов от пикселя яркостью в 127 и 255 отличается совсем не в два раза, а примерно в четыре. Если быть точным, в (255/127)^2.1 раз
Фильтр Гаусса на стероидах: секреты ускорения вычислений