Согласен с охотниками на тему «не хотим привыкать!» к GPS в лесу. Сам с детства по лесам бегаю, ориентируюсь по солнцу, компасу и т.п. Ни разу сильно не блудил, но после покупки туристического GPS столкнулся с проблемой ложной уверенности. Вламываешься в лес, не запоминая дороги и без компаса, а потом наступает паника, когда видишь, что навигатор сдохнет через полчаса, а батареек нет запасных.
Такой подход хорош, когда в разных частях изображения находятся объекты с разной средней интенсивностью и важно учитывать их локальные гистограммы для того, чтобы их сохранить после бинаризации. Но в Вашем случае объект, который нужно сохранить только один, а все остальное лишь блики и шум. Можете выложить результат с Otsu и без?
Да, тестировал. Коллизии на больших базах будут всегда, но их количество можно минимизировать (добавив проверки, естественно, увеличив время выполнения). Т.к. мне нужно также получить координаты найденного объекта на изображении, ищется гомография, если дескрипторы заматчились, по гомографии получаем ограничивающий 4х-угольник найденного объекта на исходном изображении, легко проверяем углы на допустимые значения (60-120 градусов для моей задачи). В стандартных примерах opencv все это есть (углы придется только самому посчитать). Проблема с временем выполнения решается подходом в статье.
Наверное имелись в виду каскады Хаара (Виолы, Джонс), а не вейвлеты, это разные вещи. Каскады бы здорово ускорили детектирование, но их обучение мучительно и долго (2-3 дня на топовом Xeon).
Я знаю это. Просто боюсь что-либо пропустить/не так понять при чтении на английском. Надежда умирает последней) К сожалению по этой теме очень мало глубокой литературы на русском.
Использую похожий метод. Вычисляются дескрипторы (SURF) и сопоставляются по базе. Водяной знак нисколько не влияет на результат, больше того при поиске объекта (немного другая задача) даже непрозрачное перекрытие части объекта позволит найти объект. Процент перекрытия зависит от количества оставшихся ключевых точек на видимой области. Удавалось найти даже объект на 80% площади закрытый другим
Прошу прощения. Конечно я имел в виду перевод. И все же, на мой взгляд, потоки и волокна звучат традиционнее нитей и фибр. Но это моё мнение, никому не навязываю.
Нити? Последний раз я видел эту терминологию в известном трактате Терренса Чана, где он еще сокеты гнёздами называл. Я не имею желания придраться, просто хочется узнать, почему именно нити, а не потоки?
Мне повезло урвать почти неюзанную (32 цикла заряда-разряда) в ломбарде. Хоть модель и 10 года, разница чувствуется (параллельно использую с Dell 7520). Так что тут от финансов зависит — если подвернулся вкусный вариант, то можно взять и более древнюю модель, если хватает на новый, да еще и на хлеб с икрой остаётся, то лучше брать ретину и ссд. ИМХО модели 2-3х летней давности тоже очень хороши.
Пользую только мыши Logitech. Сейчас M705, на полке M555b с даблкликом (на гарантию заморачиваться не стал, ибо грызун честно отслужил свой срок). Самое прекрасное у этих моделей — это инерционное кольцо. Крайне удобно с ним работать с лопатами кода, кто еще не пробовал — советую. В качестве плюсов еще у M705 — это почти год работы на 2х батарейках, в отличие от Magic mouse, в которой меняю раз в месяц.
Самый большой контур это и есть наша цифра, выбросим всё, что лежит за его пределами с помощью наложения маски
Данный этап можно опустить и сразу обрезать большой контур по краям
# Otsu's thresholding after Gaussian filtering
blur = cv2.GaussianBlur(img,(5,5),0)
ret3,th3 = cv2.threshold(blur,0,255,cv2.THRESH_BINARY+cv2.THRESH_OTSU)
Кстати, а качество/скорость распознавания цифр не будет выше, если использовать Tesseract API?
#include
#include
std::fstream& GotoLine(std::fstream& file, unsigned int num){
file.seekg(std::ios::beg);
for(int i=0; i < num — 1; ++i){
file.ignore(std::numeric_limits::max(),'\n');
}
return file;
}
Вопрос в том: будет ли он быстрее простого считывания файла построчно?