Pull to refresh

Comments 40

На чём реализовывали алгоритм?
Если это не секретные разработки, интересно посмотреть и опробывать исходники в действии на других картинках. Хочется код в всеобщее обозрение.
Проблема в том, что реализация входит в состав большой программы, используются методы и классы из других файлов. Поэтому просто опубликовать файл с методом не получится, нужно это всё вычленить, убрать лишнее и т.п. Возможно, позже сделаю. Хотя метод не сложный, мне кажется, просто описания достаточно.
Хотя бы псевдокод в топике.
Читать имеет смысл начинать с метода void SomeCode();
Который символизирует вызов из внешнего кода.
Отличная статья, побольше бы таких. Спасибо.

Как уже сказали выше, было бы неплохо, если бы была возможность попробовать «вживую».
Может быть получится сделать набор статей с реальными примерами алгоритмов при обработке изображений, лично мне эта тема очень интересна.
Прочитал — интересно, этот материал нам на лекциях рассказывали в университете. Добавил в избранное. Я вообще предлагаю создать отдельный блог по обработке изображений, ибо количество статей на эту тему странным образом увеличивается. Вот в ближайшее время планирую публикацию поста о распознавании на изображениях специфических объектов, и поместил бы его в новый блог.
Спасибо! Однако я сам пытался создать такой блог — не получилось, было написано что хабр коллапсирует от новых блогов. Рад что это у вас получилось. Будем наполнять эксклюзивной инфой новый блог.
Ну ещё бы у него не получилось :]
Перенёс топик в новый блог.
Вопрос: почему я не могу перенести свой старый пост об обработке изображений в этот блог? Там его просто нет в списке.
Предположение — может быть, вы забыли подключиться к новому блогу?
Мы всего-навсего заменяем яркость в точке средней по какой-то окрестности — то есть банально уменьшаем разрешение. Вообще не учитываем при подсчёте среднего расстояние от точки в слагаемом, до центра (ну то есть точки, для которой считаем). Как вы думаете, что произойдёт с тонкой красной линией?
Да, правильное замечание. Вместо взятия среднего арифметического для сглаживания изображений (и подавления шума) часто используется взвешенное среднее с коэффициентами Гаусса, в нём как раз учитывается расстояние. Однако среднее арифметическое тоже даёт неплохие результаты, а доказательство состоятельности и несмещенности для такой оценки есть в любом учебнике по матстатистике (в отличие от взвешенного среднего, здесь ещё нужно доказать, что его можно использовать).
Позволю себе не согласиться с вами относительно того, что сглаживание изображения эквивалентно уменьшению разрешения.
Про красную линию — во-первых, забыл сказать, что работаем с черно-белыми (полутоновыми) изображениями, во-вторых — она даст полупрозрачный красный след ширины 2r. Если использовать взвешенное среднее — даст след ширины 2r, который в центре будет ярче, к краям бледнее — поэтому обычно предпочитают взвешенное сглаживание.
Для полноты информации добавил примечание про сглаживание Гаусса.
Это здорово, что есть упоминание о том, что мы знаем, что ищем.
Однако что делать, если задача — найти особенности, формфактор которых неизвестен и вообще неизвестно, присутствуют ли они на снимке? Я правильно понимаю, что метод сложноприменим в этом случае?
Да, для такого случая есть другие методы, например, метод пятна. Если появится время и настроение, расскажу о нём тоже, но в ближайшее время вряд ли получится.
Промотивирую ка я вас на написание.
Не преуменьшая ценности вашего описания, хотелось бы озвучить, что на практике подобный алгоритм реализуется двумя операциями:

1. Сначала применяется фильтр Blur (размытие), который, по факту, производит усреднение пикселей с окружающими в каждой точке. Особенно часто потребность в нем возникает при сигнале с камер в условиях недостаточного освещения (шумы CMOS).

2. Применяется пороговый фильтр, отсекающий пиксели с малой яркостью (фон) от пикселей с большой яркостью (объект).
Спасибо за дополнение! У меня в коде именно так и получилось, само по себе в процессе рефакторинга.
Вы забыли о операции преобразования исходного изображения в полутоновое
а можно тоже самое, но на более реальных примерах… наклоненный квардратик больно идеализированная штука
Да-да! Можно зебру, пожалуйста? ;)
Посмотрите на аэроснимки местности в ИК-диапазоне, например, на этом сайте (нашёл сейчас через Гугл). Там можно заметить множество объектов, которые в среднем светлее или темнее фона. Размеры их тоже известны, если знаем, что ищем — поскольку высота съёмки тоже известна, и можно вычислить, сколько метров в одном пикселе. Метод применим для поиска всех таких объектов. Да, ещё, правда, нужно, чтобы объекты не стояли слишком близко друг к другу, иначе не удастся найти зону интереса для отдельного объекта.

Например, можно искать дома или ёжиков
Сколько пикселей в метре можно вычислить зная разрешение изображения, а высота съемки как правило неизвестна, более того, любая инфа о устройстве дистанционного зондирования Земли — для служебного пользования. На этих снимках данным методом сложно что-то найти. И вообще согласно нашему законодательству эти снимки относятся к секретным, слишком уж высоко разрешение, если это территория РФ.
Возможно, высота и неизвестна. Практически с этими устройствами и снимками не работал, просто в тех источниках, которые читал, было написано, что для съёмки самолёт пролетает на заданной высоте — далее через угол и высоту вычисляем размеры основания пирамиды, которую видит камера, ну и физические ширину/высоту изображения делим на число пикселей по ширине/высоте. Возможно, реально делают совсем по-другому, не знаю.
Да, все верно. Простите мой столь резкий комментарий, был приступ ночной паранойи.
Вспоминается курс Computer Vision, который я год назад прослушал. Отличная статья, походу, понятнее чем нам тогда объясняли.
Добавить на картинку градиент — и описанный метод уже не прокатит. Думал, что будет что-то интереснее, чем blur+treshold ((
Такие методы в чистом виде редко используются. Почти всегда существует некоторая предварительная обработка изображения, определяемая решаемой задачей. В том числе существуют методы борьбы с градиентом. Так что статья не бесполезная. Это база.
А по какому принципу подбирается радиус сглаживания? Можно ли его подобрать автоматически? Что сделает алгоритм, если шум заметно больше разницы яркостей? Не загладятся ли у квадрата при этом углы? Если да — как их потом восстановить (если заранее неизвестно, что это квадрат)?
Радиус сглаживания зависит от качества изображения, которое определяется соотношением сигнал/шум. Подбирается эмпирически. Здравый смысл подсказывает, что за 50 лет должны были появиться какие-то работы по поводу автоматического выбора радиуса, но специально не искал и случайно не встречал.
При возрастании шума на квадрате появляются «дырки», а на фоне — «пятна». В предельном случае будет равномерная пятнистая каша по всей зоне интереса. По поводу восстановления искаженной шумом проекции кое-какие мысли есть, но по-моему, это неверный путь — в тяжелых случаях нужны другие, более надежные методы.
Во-первых, эта статья страшно напомнила мне мою: habrahabr.ru/blogs/algorithm/112079/ :) Похожие картинки, похожая структура поста :)

Во-вторых, алгоритм из моей статьи можно совместить с описанным вами, чтобы находить оптимальный порог.
Действительно, очень похоже. Спасибо за ссылку на статью.
Про второе, я бы сказал, описанные два метода — два разных способа находить порог, в зависимости от имеющейся информации. Не уверен, что их можно скомбинировать во что-то полезное, хотя подумать стоит.
Sign up to leave a comment.

Articles