Комментарии 44
Попал наркоман в ад. Идет он и видит конопляное поле. Решил он курнуть и начал
рвать коноплю. Подходит черт:
- Зачем ты ее рвешь? Вон, уже скошенные поля есть! Идет мужик, и точно — конопля
скошена, в стоги уложена. Взялся было ее сушить, подходит черт: - Зачем, дорогой, сушишь? Вон амбары с сушеной коноплей! Идет мужик дальше — амбары полны сушеной конопли! Решил он расфасовать ее по боксам. Подходит черт:
- Зачем фасуешь? Вон амбары, полные готовых боксов! Идет — и точно, стоят
амбары, конопля аккуратно расфасованна, боксы в штабеля сложены. Начал было
забивать. Подходит черт: - Слушай, зачем забиваешь? Вон склады с косяками! Идет — склады полны, косяки
аккуратно забиты, уложены. Взял мужик косяк, глядь — а спичек нет. Подходит
черт, спрашивает мужик у него: - Черт, а черт, дай спички — прикурить!
- Э, — отвечает черт, — если бы тут были спички, то это был бы РАЙ!
Что-то тут не так…
А почему это удивляет? Судя по всему, автор на каждой итерации загружает изображение в память видеокарты, считает там что-то простое, затем выгружает обратно.
[red] = fista_gpu(gpuArray(corrupted_red),obj1_gpu,obj2_gpu,0.000001,3,100);
red=gather(red);
Первая команда выдает матрицу размещенную в памяти GPU полностью отработав алгоритм и занимает по времени 0.5-1 сек.
Вторая команда переносит матрицу из памяти GPU в обычную и работает она 4-5 сек. Возможно дело в Matlab, возможно я что-то не так использую, однако утверждение что я загружаю в память GPU картинку на каждой итерации голословно.
Да, моя ошибка — я ни разу не пользовался ускорением GPU на матлабе, потому неверно понял код.
Поиск в интернете же говорит о том, что GPU код в матлабе выполняется асинхронно, и вызов функции gather
не только переносит данные из GPU, но и ожидает завершения выполнения операций на GPU. Так что 15 секунд — это и есть честное время работы.
Простите за занудство, но не используют в русском оборот "размер проблемы". Точнее, используют, но с совсем другим смыслом.
По моему Лену всегда в бмп использовали?
У меня другой вопрос, почему Лену Сёдерберг не используют в полный рост? :)
Потому что "та самая" Лена — 512*512. Исторически.
Но можно же 512х512 и другой участок взять
На самом деле это одна из главных составляющих задачи: у вас ведь может быть не только шум на изображении, но и погрешность в ядре свёртки, и надо как минимум убедиться, что алгоритм устойчив (а то чуть неточно задали ядро — и получили мусор вместо изображения)
> Добавляя на каждом шаге разницу между результатом двух предыдущих итераций, мы увеличиваем сходимость алгоритма до квадратичной
Было бы здорово объяснить почему
В оригинальной постановке задачи (|| y — Ax ||_2) если || x ||_2 = sum_i ((x_i)^2), то вся задача это просто МНК который выливается в решение очень сильно разреженной СЛАУ. Я не большой специалист, но мне кажется что что-нибудь из семейства сопряженных градиентов на GPU должно было показать себя очень хорошо по части производительности.
Хотелось бы увидеть обоснование второго «улучшенного» функционала. Если со слагаемым (||alpha * ( x — x_k) ||^2) все более менее ясно (просим чтобы текущее решение было поближе к предыдущему), то с термом -A^t*A все совсем не понятно (откуда он взялся, зачем нужен и т.д.)
И да,
>Задача значительно проще
Вот это вот совсем не очевидно. Было бы здорово рассказать чем проще
Такая СЛАУ влёт решается через преобразование Фурье, если А — просто свёртка.
Собственно еще одна причина думать что с оригинальным функционалом что-то не так
Если Вы имеете ввиду обратную фильтрацию то это не совсем так. Такое решение будет чувствительно к числу обусловленности матрицы свертки. Данный же алгоритм обладает стабильностью за счет дополнительного слагаемого.
Ну так речь шла именно о СЛАУ. Кстати, дополнительное слагаемое в виде квадратичного стабилизатора вполне себе можно учесть (в приближённом виде), если обращать свёртку как:
IFFT(FFT(I) / (FFT(K) + C)),
где C — константа. Здесь, правда, есть требование, чтобы FFT(K) было вещественным и положительным — не любое ядро размытия подойдёт.
Но, понятное дело, с Total Variation такое уже не прокатит, и нужно применять полноценный итерационный метод минимизации.
А так много что используют, к примеру,размытие по гауссу
а для восстановления после размытия и смаза одинаковый алгоритм (я про вообще, а не только ISTA) подходит?
Я всё понимаю, интересный алгоритм, исследовательский проект и всё такое, но почему код так ужасно написан? Каждый раз, когда я вижу код на матлабе, то в 99% случаев он написан ужасно. Матлаб к этому располагает, но вы даже отступы не потрудились расставить. Почему?! Отступы в редакторе матлаба автоматические! Вы специально их убрали что-ли? Весь код на гитхабе такой.
Вы же оформили эту статью, почему нельзя оформить код?
Потом вы устроитесь на работу и начнёте писать вот такой вот код без пробелов, без отступов, без внятных имён переменных, а ваши коллеги должны будут его читать, понимать и поддерживать!
Еще один алгоритм для восстановления смазанных изображений