Pull to refresh

Comments 150

> SmartDeblur 2.0 — все по-прежнему бесплатно :)
> Исходники и бинарники от предыдущей версии

Я так понимаю, что проект теперь с закрытым кодом? Жаль…
Да, пока что исходники закрыты, чтобы избежать случаев злоупотребления ими (с предыдущей версией было много ребилдов с изменением авторства, несмотря на лицензию GPL, попытки продавать и пр). Думаю, чуть позже их откроем.
Лучшее средство от плагиата — широкая известность и доступность. Возможно — в форме плагина для gimp или какого-либо популярного средства работы с изображениями (аналогично тому как RIOT доступен в виде модуля IrfanView).
Так и получается одни делают дело, а другие на этом пиарятся. Увы не все так просто :(
Любой, кто хоть раз воспользовался Save for Web на базе RIOT (хоть в gimp, хоть в irfanview) может не быть в курсе, что это сторонний модуль, только если он слепой. Так что принципиальной проблемы тут не вижу.
Было бы очень кстати, если бы это было плагигом для Gimp.
Плагин для гимпа и фотошопа тоже планируется — когда точно, сложно сказать.
А что с адобовской версией дешейкера? После того как они показали на Max 2011 результат его работы, ничего больше о нем не слышно.
Сложно сказать — их демки были на изображениях с искусственным искажением, чтобы продемонстрировать wow-эффект.
Может быть допиливают, может отложили пока.
Если 8BF, то rfanview скорее всего тоже подцепить сможет.
Автору огромное спасибо, будем ждать.
А какой у вас будет результат на изображение от Adobe?
Один из примеров есть в статье, после фразы «И в заключение, результат работы на изображении c конференции Adobe MAX 2011» — получилось вполне неплохо.
А другие примеры вы можете попробовать сами.
Прошу извинений. Не понял сразу. Думал, что это и есть итог самого Adobe.
А нет ли алгоритма, чтобы восстанавливать исходное по серии смазанных? Это может быть удобно, когда темно, снимаешь с рук, будет смаз, но можешь снять серию
Как вариант — можно снять серию с короткой выдержкой и повышенным ISO и потом совместить несколько несмазанных, но шумных изображений. Например с помощью RegiStax
Да это было бы неплохо. У меня в камере sony nex5 есть такая функция как съемка быстрой серии кадров (6-7 штук) и потом на основе первого и наложения сверху остальных программно устраняются шумы и смаз. Результат выходит просто фантастический (для тех кто знает какой снимок получится на таких iso с такой выдержкой с рук почти без освещения).
Люди правда пугаются когда фотоаппарат затвором щелкает как автомат
я сейчас тоже купил nex-6 и там это есть, но, кажется, за дополнительные деньги.

но хотелось бы такой софт иметь отдельно, а не в камере
За дополнительные деньги? Вряд ли. Это должно находиться в меню выбора режима съемки (наравне с авто, p, a, m, и т.д.) и называться что-то типа режим анти-размытия или устранения смаза и т.д.
Единственно минус — в этом случаем снимается только jpeg фото, но зато полного размера. В некоторых ситуациях — когда объектив без оптической стабилизации, помещение темное, вспышка не применима — это просто спасает.
Множество было случаев, когда на город спускается вечер — камеры начинают мазать, друзья убирают компактные мыльницы уже часов в 6 вечера, те у кого аппараты посерьезней, типа любительских зеркалок — могут дотянуть до 7-8 часов, а я просто перевожу режим на анти-смаз и спокойно снимаю до 3 часов ночи, при освещении типа одной 60Вт лампочки или уличного фанаря, на выходе получаю 30-40% вполне вменяемых кадров и на следующий день удивляю результатом ) Желательно конечно еще объектив иметь светлый — дырку придется открывать почти на полную.
Наткнулся на обзор nex-6 — действительно, этот функционал вынесли в магазин приложений (магазин приложения для камеры!!) и он теперь стоит 200 рублей >_<
Но это очень крутая функция, рекомендую.
Магазин приложения для камеры!!! (все еще не отошел от шока)
А можете показать результаты такой обработки серии кадров?
А можно увидеть результаты обратных преобразований из четких снимков размытые, и зная ядро снова получить исходные, будут ли снимки одинаковыми (в %)?
Если не добавлять шума и не терять точности — то результат будет практически идентичен исходному изображению.
А ведь смазанные изображения в разы лучше сжимаются JPEG, JPEG2000, нет ли потенциала в этом направлении?
Может быть потерь будет заметно меньше, чем выигрыша в объеме?
результат на последней паре фото просто впечатляет
Это может быть искусственное искажение — на них всегда отличный результат.
Но самое первое изображение точно реальное (натюрморт) — фоткал я сам. С птицой в лесу тоже реальное.
А в целом не на всех изображениях удается получить хороший результат, поэтому будем очень признательны за любой фидбек с примерами.
Сложность сильно зависит от угла объектива. Широкоугольные фото восстановить сложнее — ядро сильно видоизменяется от края до края кадра. Фотографии на длинном фокусе (пример от Adobe как раз такой) намного проще.
11 = 3 x 3.667

Это в какой вселенной??? Пишите уж тогда «3.(6)»
Это в любых операциях с плавающей точкой, там почти всегда идет округление :)
А какие это двоишники тут минусуют? Речь не просто о результатах каких то выкладок. Речь именно о двух множителях! Хабр, мля! )))
Интересно и не один не смог обосновать свою позицию! Только бы насрать втихаря. Айтишники и так-то не особо интегрированы в социум. А тут вообще законченных социапатов выращивают.
Зато грамматике сколько внимания уделяют!
Думаю, тут все просто.
Пример со множителями рассматривался в контексте приближенных вычислений, а в них процессор не оперирует дробями, только float представлением числа.
Поэтому с точки зрения компьютера выражение «11 = 3 x 3.667» недалеко от истины. Ну разве что шестерок поболее будет и в конце появятся «шумовые» цифры, вызванный особенностями нормализованного представления чисел с плавающей запятой — но для объяснения принципа это не так важно.
C точки зрения компьютераи задача о квадратуре круга решаема с любой заданной точностью. Но это плевок в сторону математики. И как я понял, на Хабре к математике такое отношение в порядке вещей. Зато не дай бог выкинуть мягкий знак из инфинитива. Издержки российского образования?
А программа Ваша паршиво работает. Ну то есть может на синтетических примерах (типа Адобовского Motion Blur) она и выдаёт что-то удобоваримое. Но на реальных кадрах… И не очень понятен механизм «удаления смаза». Зачем такой локальный гипер-контраст? Он никак не скомпенсирует смаз.
И проще, имхо, не перебором вычислять трассу, а предоставить это пользователю. Пусть выделит точечный источник света, который как раз и примет форму трассы. Или какой-то характерный краевой объект. Доверять всё автомату — бессмысленно.
И проще, имхо, не перебором вычислять трассу, а предоставить это пользователю. Пусть выделит точечный источник света, который как раз и примет форму трассы. Или какой-то характерный краевой объект. Доверять всё автомату — бессмысленно.

Невооруженным глазом видны только простейшие траектории.
К примеру, сможете на этом примере выделить такой точечный источник света и определить траекторию смаза?

image
Получив при этом такую траекторию?


Также не совсем понял про «локальный гиперконтраст» — где он?
И на каких кадрах вы пробовали и получили плохой результат — можете ими поделиться?
Я слабо себе представляю как можно получить такую трассу! Выдержка на минуту и алкоголик с абсинентным синдром в роли фотографа?

На первых двух вообще мимо кассы, хотя там явный смаз. На последней более-менее удобоваримое что-то получилось. Но для примера сделал третий вариант, это тупо Smart Sharp на максимум с радиусом в 2 пикс. То есть направление работы алгоритма вполне явно. Да, и ещё — Вы про «локальный гиперконтраст» спрашивали. Так вот выкрученный шарп (нерезкое маскирование) им и является. Разве не видно тучи ореолов и каймы на деталях изображения?



Кстати, со второй картинкой у меня получилось так:

Да, кстати, прошу прощения, что попытался всех под одну гребёнку собрать. Не обратил внимания, что было и достаточно плюсов. Так что не всем тут плевать на математику в контексте «чисел с плавающей запятой».
Дык давайте тогда будем считать пи = 4. Ну ладно 3 (компьютеры ведь обычно округляют как антье). И на любые упреки — «а вот так работают математические сопроцессоры».
А ещё компьютеры не умеют генерировать действительно случайных чисел. И поэтому теорию вероятностей -> «фф топку»!
При искусство вообще молчу…
Дурдом какой-то…
Учитывается ли, что при съёмке камера может не только сдвинуться, но и повернуться вокруг оси, и в разных частях снимка ядро будет разным?
Нет, предполагается, что траектория смаза одинакова по всему изображению. Если это не так — то можно попробовать обрабатывать частями
Ну вот поэтому у вас и получаются хорошие результаты только на искусственно смазанных изображениях.
Реальные камеры болтаются в 6 степенях свободы, и учитывать нужно как минимум 5 (если речь не о макро). У вас же в ядре всего две координаты.
Просто оставлю здесь эту картинку:

PS. Ну всё равно круто, чё.
Не совсем так — доминирующие причины смаза вызваны только тремя степенями свободы, это вращение вокруг трех осей. Другие три степени свободы, а именно смещение вдоль осей практически не вызывают смаз. Это нужно на полметра сместить фотик во время экспозиции, чтобы эффект проявился.
Поэтому остается поворот вокруг трех осей, где достаточно смещение на доли градуса чтобы появился заметный смаз. Из них повороты по двум осям (две правые фиолетовые стрелки) производят смаз, который успешно компенсируется.
И только смаз вызванный вращением вдоль оптической оси (левая фиолетовая стрелка) не может быть проанализирован текущим алгоритмом.
Так что не все так плохо
Ну тогда Вам до кучи по поводу «синтезированных примеров». Алгоритм будет работать только на снимках с одним доминирующим планом. Поскольку «смаз» по разному проявится на ПП и ЗП. Т.е. для заднего плана величина смаза (при той же трассе) будет гораздо больше. В общем получается достаточно узкоспециальное применение.
Как раз в случае смазов вращения передний и задний план будут смазаны одинаково, с точки зрения линейных размеров их проекции.

Так-то да, 1 градус поворота смажет передний план на 0.1 м, а задний на 1 м, но проекция будет смазана в обоих случаях на одинаковую величину.

p.s. А вот в случае смаза из-за «стрейфов» — да, там будут уже разные смазы проекций переднего и заднего плана.
Если смаз вызван движением фотоаппарата, то все изображение смазано примерно одинаково. Если же причина смаза движение отдельных объектов, то да — будут сложности. Впрочем, можно обрабатывать такие кадры частями.
Алгоритм поможет «вылечить» смаз создаваемый вращением сенсора относительно оси съёмки (в этом случае области близкие к оси вращения будут слабо смазаны, в отличие от переферии)?
Упс. Уже спросили.
Попробовал на фотографии с не большим нерановмерным смазом. При небольших kernel size да, «четче» становится, плюс артефакты лезут. Чем больше kernel size, тем становится хуже и фотография превращается в такое:

Тьфу, не туда комментарий отправил.
А можете прислать оригинал? Похоже на багу в финальной деконволюции.
Спасибо, проблема, похоже, действительно в оригинале, а точнее в RAW-конвертере, которым делался оригинал.
небольшое пожелание. сделайте, пожалуйста, в вашеё чудесной программе галочку: «я понимаю что делаю, снять ограничение», которая будет снимать ограничение по размеру изображения. пусть программа съест несколько гигабайт памяти, не страшно. зато обработает большую картинку :)
Дело не в этом — галочку добавить просто. По факту Windows устанавливает лимит памяти на процесс примерно 1.4-1.5 гигабайта для 32-битных приложений. Для размера 1200 пикселей текущее потребление примерно 1-1.2 гигабайта. Чуть больше уже вызывает crash, хотя у меня ОС 64 битная и физической памяти 12 гиг.
Нужно либо создавать отдельную версию и компилировать под 64 бита, либо же значительно оптимизировать потребление памяти — что-то из этого будет позже сделано.
Если в приложении нет завязки на 32битные int для всяких адресных дел и подобного, то можно воспользоваться флагом LARGEADDRESSAWARE, который скажет ОС выделять больше памяти. И ссылка на обсуждение использования данного флага blog.lexa.ru/2013/02/21/q_3gb_switch.html
Пробежался по ссылке, как я понял, при использовании /LARGEADDRESSAWARE увеличился лимит всего лишь с 1.1 до 1.2 гигабайта.
Но попробую так — спасибо.
Там похоже наблюдалась фрагментация, так как далее в комментариях обсуждаются варианты, как посмотреть, как реально используется виртуальная память. У автора требуются очень большие аллокации (до 600+Мб), а их в фрагментированном даже 4гб адресном пространстве можно не найти.
Как уже было отмечено, виртуальное адресное пространство фрагментировано.
Нужно использовать несколько аллокаций.
Первый раз получить, скажем, 1GB, а дальше уже кусками не больше 500МБ. Если блок не выделяется, разбить пополам и т.д.
Сложновато получается, и выигрыш минимален.
А насколько реализуем вариант — скормить часть картинки для вычисления ядра(или сделать для этого авто-кроп от целого изображения), а потом использовать уже не только оперативную память, а еще и файл дампа для просчета большого изображения?
ПО, которое собирает панорамы да и фотошоп используют дампы на жестком диске и спокойоно переваривают, пусть не быстро, зато без ограничений.
Нет, в режиме /3GB — доступен ~гигабайт с копейками в нижней половине 4Gb (остальное — DLL-ки всякие).
И еще доступны 2Gb если 32-бинарник (помеченный этим флагом) запущен в 64-битной ОС и, соответственно, 1GB если он запущен в 32-битной ОС, которую загрузили в режиме /3GB.

Т.е. в хорошем случае (вас запускают в 64-битной оси) — будет втрое больше, чем без этого флага.
Некоторые снимки очень похожи на заблуренные пост-фактум.
Все снимки, кроме может быть адобовского, реальные смазанные.
(заглядывая в ближайшее будущее) не удаляйте неудачные фотки со своих фотоаппаратов! скоро всех их можно будет легко исправить
Скорее бы уже этот алгоритм добавили в фотоаппараты, чтобы они сами убирали смазы на длинных выдержках.
Съемка с рук в любых условиях даже на бюджетной оптике, о чем еще можно мечтать?
Так это же немного разное? Софтверную стабилизацию уже можно применять когда hardware не справилось.

Какая камера сможет снимать без смаза с рук на выдержке больше 1/10 сек? Обычно такие кадры уходят в помойку, но с реализацией как в топике эти кадры можно восстановить.

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

Интересно другое, почему ведущие производители фото-техники еще не применили алгоритм Blind Deconvolution? Наверно и с гироскопами тоже были испытания. Может результат работы алгоритма не подошел для массового использования в фотоаппаратах?

PS Попробовать бы использовать гироскоп телефона для оценки ядра искажений.
Все производители фототехники уже давно это компенсируют аппаратно. Через стабилизаторы в камере или объективы.
А откуда тогда эти фотки со смазами? В фотошопе нарисовали? Проблема надумана?

Про широкоугольный объектив отличное предложение, вы бы еще предложили не снимать в темных помещения или пользоваться вспышкой.
Это был ответ на вот эту Вашу фразу:
Интересно другое, почему ведущие производители фото-техники еще не применили алгоритм Blind Deconvolution? Наверно и с гироскопами тоже были испытания.

Фотки со смазами? Часть в фотошопе рисуют для презентаций. Да и стабилизаторы помогают максимум на 2 ступени.

Вы спросили:
Какая камера сможет снимать без смаза с рук на выдержке больше 1/10 сек

А я ответил — любая с широкоугольным объективом (при прочих равных). Вспышка не поможет при достаточно ярком заднем плане. Да и светлое пространство не панацея, когда например, нужна большая ГРИП.
Интересно другое, почему ведущие производители фото-техники еще не применили алгоритм Blind Deconvolution?

Много чего еще не применили в фотоаппаратах. Например съемка серией с последующим объединением для уменьшения шумов, улучшения разрешения и экспозиции только-только начали внедрять. Хотя идея давно витает в воздухе.
Уже лет 10 не удаляю ни одного оригинала. Правда, идея была несколько другой — что у фотографий есть не только художественное, но и информационное значение.
Может вы введение какие-нибудь ключи запуска, снимающие ограничение на размер файла? Гигабайты памяти – не страшны.
Да, планируется.
Сейчас основная загвоздка в скорости — преобразование Фурье. На среднем изображении оно вызывается несколько тысяч раз. В текущей версии используется OpenCV, которые не позволяет делать FFT в несколько потоков.
Распараллеливание на уровне кода «в лоб» приведет к разы большему потреблению памяти.
Это все решаемо, но требует время.
Попробуйте fftw3: я вообще не понимаю, зачем вам в этой задаче opencv, если все алгоритмы — свои.

А еще для небольших изображений (или кусков изображений) можно GPU использовать: скажем, выдрать кусочек изображения 1000х1000, подобрать для него ядро, потом выдрать другой кусочек — подобрать ядро для него. По идее, так можно будет и смазы из-за вращения определять и ликвидировать.
FFTW я как раз использовал в предыдущей версии SmartDeblur, который доступен вместе с исходниками.
На OpenCV (от него используется только преобразование Фурье) пришлось перейти из-за закрытия исходников.
Упс. Не учел, что новые исходники у Вас закрытые.
Но для CUDA и MKL это не помеха, правда MKL денег стоит.
Черт, у вас исходники закрыты!
Печально. Я надеялся, что смогу вашу утилиту собрать, поковыряться…
Как вариант — могу предложить у Фергуса скачать матлабовские исходники и поиграться с ними.
В SmartDeblur другие алгоритмы, но для экспериментов сорцы Фергуса будут в самый раз, т.к. они достаточно простые для понимания и изучения.
А если при наличии GPU это преобразование фурье на него выгружать? Nvidia говорит, что быстрее получится, да и в CUDA соответствующая библиотека есть, так что писать свой код для GPU не придется.

Ну и да, +1 к использованию fftw3 раз лицензия позволяет его использование. Кроме того его API позволяет перейти и на Intel MKL простой подстановкой, что может еще поднять производительность, если есть возможность использовать MKL.
Не так давно надо было решить практическую задачу — фото документов улучшить (уникальные документы, были плохо сфотографированы), вертел-крутил эти фото при помощи вашей программы, но, увы, не смог улучшить. Попробую вторую версию, напишу о результатах!
В общем, то, что можно было разглядеть, стало чётче, что разглядеть было нельзя, так и нельзя, а жаль, чудес не бывает всё-таки :)
Спасибо! Буду пробовать.
Что получится, выложу результаты
Надеюсь ООО «Бунге СНГ» занесло как следует? ;)

А если по делу, то возможно ли такое же с видео? Судя по видео на YouTube с включённой борьбой с «шевелёнкой» у них получаются видео от которых можно получить морскую болезнь. Или есть специализированные средства и ваши методы для видео не подойдут?
Не сразу понял про «Бунге СНГ» — что дома было, то и сфоткал )
Насчет видео — думаю, применить можно. Выдернуть все кадры, по одному обработать и склеить обратно в видео.
Но не пробовал
Улучшится ли качество, если для каждого цветового канала подбирать ядро независимо?
Качество улучшится если вместо преобразования в чб учитывать все три канала вместе.
Но не думаю, что это даст существенного улучшения качества
А в чем смысл этого? Входное изображение все равно 8-битное.
Так тем более

Внутренняя обработка если я верно понимаю идёт во float, в линейном пространстве?

А экспорт импорт — через сраные 8 бит
Перед обработкой делается гамма-коррекция, далее все в double.
Так повторюсь — тем более

Вы при обработке воюете за каждый бит, а при загрузке огрубляете изображение до неприличного. Современные камеры дают 13 стопов сигнал шум, в идеале может 14 стопов.

По хорошему, нужно попробовать импорт прямо линейных данных с raw файла, например с помощью dcraw или libraw, и посмотреть даст ли это эффект.
RAW особого эффекта не даст, мы пробовали на 16 битных TIFF. Основная загвоздка — несовершенство алгоритмов, т.к. далеко не все реальные фотографии получается восстановить.
Я всё равно не понимаю, зачем делать хуже если можно хорошо. Кстати, какая гамма идёт по стандарту, 2.2? А если у меня sRGB? А если AdobeRGB? А если часть файлов так а часть эдак?

Ох, ну уговорить у меня вас не получилось, ну ладно, что я могу поделать. Делайте как делайте :-)
Скажем так — поддержка RAW и 16-битного формата в перспективе нужна, это очевидно, но сейчас у нас есть более приоритетные задачи по улучшению качества и алгоритмов.
Пока мы еще не уперлись в то, что нам не хватает 8-битного пространства. Тем более что большинство фоток, 8-битные JPEG.
И да, программа хорошая, позволяет действительно немного поправить небольшие ошибки автофокуса.
Кстати, какие форматы сейчас поддерживают 16 бит? Эти 16 бит линейные, или с гамма-коррекцией? И есть ли для них бесплатные библиотеки записи и чтения?
16 бит в основном с гаммой, а 32 бит — уже линейные (но бывает, конечно, и хоккей на траве и балет на льду).

Я не самый большой специалист по библиотекам, и вот гугл подсказывет есть libtiff.

В конце-концов, если уж совсем лень, есть формат PBM, который примитивен, и конвертер в него или из него — это задача для студента первого курса. Если бы при импорте/экспорте можно было бы выбирать галочкой с гаммой это или линейные значения, то меня вполне устроила такая бы функциональность.
А что же с шумом? В вашей модели он пока не учитывается?
Учитывается.
В статье описывается один из вариантов Blind Deconvolution с достаточно сильными упрощениями для того, чтобы подход был понятен широкому кругу читателей. Те, кто интересуется деталями — можно посмотреть оригинальную статью, а также последние наработки в этой области, хотя бы с конференции SIGGRAPH
Эх, а я мечтаю о консольном режиме.
Так будет удобно пользоваться откуда угодно, при этом не открывая исходники. Ну и вообще это более профессионально :)
Применять фильтры, не глядя на исходник и результат — профессионально? О_О
Нет, консольный интерфейс это профессионально. А сравнивать все равно можно при желании, кроме того так можно использовать для пакетной обработки или практически из любых языков программирования.
а можно разрешить редактировать ядро вручную? Так для экспериментов, ну и чисто визуально кажется, что в ядре есть лишние случайные ветвления.
Об этом я думал еще для первого SmartDeblur, пока руки не дошли — включим в последующие релизы
Получаются весьма интересные результаты если в кадре есть движущийся объект (кот) и выбрать область с ним
с рыжими неконтрастными котами при плохом освещении ему справится тяжело. Но вообще результат ожидаемый: коты стали немного четче, а всё остальное oversharp с характерной полосатостью «вдоль» траектории движения котов. Трудно сделать: надо что бы части тела кота двигались с одинаковой скоростью, надо что бы освещение было нормальное, надо что бы кот занимал значительную часть снимка, что бы выделять только его, без окружающей обстановки и т.п.



думаю интересный результат получится когда что-то большое будет двигаться в кадре, например машина.
Попробовал ради интереса, фото из серии неудачная проводка. Номер стал более читаемый.


Это всё тупо от перешарпа. Смаз тут никак не устраняется.
Пожалуй. Причем если выделять отдельные области, например тот же номер — результат становится ещё хуже.
Не совсем — шарпом такого добиться не получится. Траектория частично восстановилась и номер стал более читаемым.
Изображение сложное по двум причинам:
1. Очень неравномерный смаз. В центре его нету, а по краям достигает максимума
2. Траектория смаза около 80 пикселей. Текущие ограничения не позволят восстановить ее целиком (размер kernel должен быть примерно в два раза больше длины траектории смаза)
Странно, что отдельные детали машины смазаны сильно по-разному. Подфарник и колесо почти нормальные, а номер размыт очень сильно. Как так может быть? Что-то я не представляю. Широкоугольная камера?
Весьма похоже на Zoom Blur — там тоже в центре четко, а по краям размыто
К сожалению не могу сказать что выделывал фотограф, сам был в тот момент за рулем. Но насколько знаю никакой постобработки тут нет.
Классический Zoom Blur как раз и делается без пост обработки — вращается зум и в это время нажимается на спуск с достаточно длинной выдержкой.
Тот, с которым аппарат и был куплен, то есть стандартный середнячок.
Прогресс не стоит на месте, скоро и такое замутят:
Скрытый текст
image
Зашёл в комменты в поисках этой картинки :-)

По теме — интересная программа, надо будет попробовать. Художественные фото с её помощью, конечно, не сделаешь, но вот что-то, снятое «для истории», или, как в комменте выше, с камеры наблюдения — вполне.
Сильно зависит от фото — какие-то удается восстановить даже до приемлемого художественного уровня, какие-то не удается даже улучишть.
На страничке с примерами приведены как раз восстановления близкие к идеальным.
по фотам впечатление, будто они не сняты размытыми, а искусственно сдублирован слой, чуть смещен в сторону и все это затем заблюрено — четко видно двоение элементов снимка. При реальной съемке — рука дрогнула, фокус не туда навелся, у меня так не выходило.
У меня такое тоже часто получается.
Пример механизма следующий — нажимаем на спуск, затвор открывается и некоторое время экспонирует матрицу, получается первый видимый отпечаток объекта, потом палец отпускается фотоаппарат движется оставляя след на снимке, далее фотик останавливается (затвор еще открыт), объект некоторое время экспонируется еще раз уже в новом месте матрицы, далее затвор закрывается.
В итоге получаем двоение снимка со небольшим шлейфом-смазом между двумя этими двумя положениями.
По фотографии с ветками видно, что 2D пространство мало для таких операций, так как ядро искажения разное для всех планов, и без карты глубины (или стереофото, из которого можно получить карту глубины), которая позволит получить ядро искажения для всех планов, и передного, и заднего, и промежуточных здесь никуда.
То есть на этом снимке правая часть ветки хорошо восстановилась, а всё что ближе имеет другое ядро искажения, поэтому и двоится.
Ядро искажения зависит от глубины только для расфокусировки (или же когда фотик движется параллельно, типа съемка из поезда, но это крайне редко). В примере с ветками есть небольшое различие в ядре для левого и правого края фотографии по другим причинам. Но в целом она восстановлена вполне неплохо
Крайне интересно.
Еще и потому, что обещанный фильтр отсутствует в CS6, насколько я понял.

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

Как пример могу отправить несколько тестовых фото вам (если интересно)
Да, очень интересно — отправляйте!
Интересно, а если заблурить такой скан, распознается ли ядро правильно? Или вернет все к изначальному, размазанно-поцарапанному изображению?
Алгоритм разблюрит, найдет царапины и решит, что устранил размытость и нашел четкие объекты :)
«Чёткие царапины» должны сильно помешать. И дать резкий пик в «нуле», т.е в оригинальном изображении.
А мы столько лет поносили Голливуд, а они знали…
При запуске версии 1.27 под мак сообщается, что есть обновление. Но фактически его нет?
Это побочный эффект того, что код от версии 1.27 общий для всех ОС — по идее нужно было еще передавать тип платформы.
В целом да — обновление показывает, но версия пока только для Windows. Впрочем, скоро ожидается и под другие платформы.
Мы выпустили версию SmartDeblur 2.1.

Основные изменения:
— Поддержка больших изображений (до 36MP на 64-битной ОС и до 15MP на 32-битной)
— Возможность редактирования полученного kernel (траектории смаза)
— Увеличение скорости за счет оптимизаций и использования Intel IPP в качестве FFT
— Улучшение интерфейса

Подробнее здесь: habrahabr.ru/post/180393/
UFO just landed and posted this here

@YUVladimir , скажите, как происходят дела с вашим творением по состоянию на сегодня?

Вроде, и нейронные сети появились, не пробовали к ним прикрутить?
Софт для потребителя, на мой взгляд, очень востребованный - у каждого первого есть сегодня фотоаппарат а то и не один. И на мой взгляд, для среднего потребителя это довольно востребованный софт на рынке.

Sign up to leave a comment.

Articles