olkin
Пользователи-
Количество публикаций
24 -
Зарегистрирован
-
Посещение
Репутация
0 НовичекО olkin
-
Звание
Бывалый
-
да я смотрю, что там нельзя будет разбить области видимости, точнее, прийдется разбивать на сегменты и сворачивать по их количеству, что впринципе и компенсирует выигранное время сижу читаю про потоки, так то всё готово, но дооолго
-
Фурье падает на mulSpectrums(tempA, tempB, tempA, 0); в чем может быть причина?
-
А я перекрутила Безье по Вашей ссылке, там всё хорошо) сам сплайн строится мгновенно, а вот скорость блюра зависит от длины кривой, количества точек аппроксимации, шага свертки... Ну и качество пропорционально времени выходит. Повторю на всякий: свертку сделать двухмерную, потом размножить картинку н раз (по длине третьей координаты), каждый раз увеличивая и кропая. И потом еще раз произвести свертку, но уже по финальных картинках?
-
Это самый рациональный способ? Если я правильно поняла, время рассчета задачи увеличивается катастрофически (по сплайну и так получается около 40 секунд, за что меня все время пинают)
-
Здравствуйте опять Сделала по сплайну, всё красиво, краевой исправила "на коленке" - дорисовала копимейкбордером и после применения свертки - кропнула)) задача теперь новая - добавить третью координату. То есть, фактически, при z>0 картинка "едет" на нас (увеличивается на каждом шаге свертки), в обратную - уменьшается. Вопрос опять таки в алгоритме. После каждого шага свертки увеличивить\уменьшать картинку? Или существует некий Vec4f?
-
Литература? С преобразований Фурье начинала, но для начала было слишком сложно разобраться, забросила. Может и правда, так как сейчас кривую надо параметризировать, пускать точку уже не по вектору, а по кривой
-
По поводу этого топика: http://www.compvision.ru/forum/index.php?showtopic=935 чей это код (первоисточник)? его можно использовать в программе, ко мне не прийдут специально обученные дяди с вопросом про лицензию?)
-
Размывает не хуже чем в фотошопе, я сравнивала Рамка только. Походу, потому что if(p.y+(float)i*v[1]>0 && p.y+(float)i*v[1]<src.rows && p.x+(float)i*v[0]>0 && p.x+(float)i*v[0]<src.cols) вектор упирается в край, и там тормозит. Только, чего оно черным стало - фиг знает ну да да. но леньки ж)
-
Тестила на белой картинке с черный контуром квадрата в центре - оно наглядней всего. Верхний и правый края стали черно-белым градиентом четко по ширине вектора. Ну может и мой косяк, код-то не дословно слизан copyMakeBorder - читала где-то, спасибо за подсказку, я тоже ленивый чел Хех, мне до распаралеливания еще..)
-
Делюсь впечатлениями) Во первых, лучше никому не знать, какого года, оказывается, у меня была установлена версия OpenCV)) и насколько в 2.4.2 всё сразу легче пошло. Во вторых, огромное спасибо за код. Собственно, вот этот фрагмент if(p.y+(float)i*v[1]>0 && p.y+(float)i*v[1]<src.rows && p.x+(float)i*v[0]>0 && p.x+(float)i*v[0]<src.cols) { sum+=k*src.at<Vec3f>(p.y+(float)i*v[1],p.x+(float)i*v[0]); и есть то изящное решение, на котором я стопорилась, у меня реализация выглядела несколько иначе, и в этом был основной косяк. Ну и, конечно, в той версии, немножко В общем, за это огромнейшее спасибо, вопрос шоколадки остался в силе. Сейчас дорабатываю всякие мелочи, в частности, там по краям рамка шириной в вектор не размывается, на Вашех скрине не видно, так как фон черный. ...А строит картинку оно у меня секунд 40, кстати. Но дело еще может быть в слабом рабочем ноуте. На очереди сплайны, сгладить ломанную и пустить свертку уже по кривой
-
Ыаыаы у меня старая версия, не читает Ваши заголовочные) обновляю
-
Сейчас гляну.. Но если Вы каким-то образом будете в Киеве - с меня уже большая шоколадка
-
первый - мой текущий вариант, второй - через классический фильтр
-
Да и так изображение строит секунд 10, сдвигая достаточно слабо. К тому же, съедает часть цветов, всё не могу добиться идентично к фотошоповскому эффекту