Nuzhny

0) Первым делом я бы посмотрел пример, как OpenCV использует tesseract для поиска и распознавания текста: вот. На время разработки я бы пока отставил C# в сторону, надо использовать С++ и заниматься алгоритмами. Потом уже рабочий вариант переписать на С# проблем не составит.

Есть ArrayFire, который на CPU работать умеет. Но насколько быстрый там у него алгоритм? Или он использует что-то стороннее для CPU - я тоже не знаю.

Да ладно, всегда можно загрузить систему на 100% какой-нибудь задачей.

Думаю, что отбрасываются. Это же легко проверить, просто посмотрев на видео: оно идёт рывками или всё больше запаздывает?

С детектором движения всё намного сложнее. Вон в последней коллекции PETS2017 надо детектировать катера на воде. А там волны! Я говорю не о детекторе движения, а о детекторе объектов, не обязательно его делать на видео, можно на изображении. Если использовать суперпиксели, то можно делать детектор с шагом в суперпиксель. И размер объекта подбирать кратным суперпикселям. А обычно рамку сдвигают по одному пикселю, что очень медленно. В качестве примера прикрепил статью по поиску автомобилей на снимке. Возьмём другой пример: сегментацию на небо, здания, зелень, дорога. Типичная задача для камер, установленных в машине (навигация, приложения типа iOnRoad, всевозможная помощь водителю). Можно проводить сегментацию как в вашем примере, деля кадр на куски разного размера и формы. А дальше что? Как узнать, к чему относится тот или иной сегмент? Как обучить ту же нейросеть классифицировать сегменты по указанным выше типам? Я не знаю. Чаще всего нейросети подают кадр целиком и она классифицирует, можно сказать, попиксельно. Что накладно. А можно научить классифицировать суперпиксели. Это снизит размерность задачи в разы с одной стороны. А с другой повысится точность за счёт того, что границы суперпикселей часто совпадают с границами областей. Вот и применение, вот и постобработка. jiang2015.pdf

Нет, у вас это не суперпиксели, а какие-то регионы. Суперпиксели можно сравнить с обычными квадратиками, используемыми, например, в jpeg или mpeg кодеках. Разделили кадр на блоки 8х8 пикселей и ищут их движение, изменения и т.д. С суперпикселями похоже, но это уже не квадраты, а регионы произвольной формы, имеющие границы по градиентам изображения. Но они по прежнему имеют упорядоченную структуру, можно отслеживать их перемещение, кодировать их. Скажем, понятно, как с ними работать. Например: Да, маленькие объекты не всегда правильно сегментируются, не всегда точно они повторяют границы (надо просто уменьшить размер суперпикселя). Но мы всегда можем быть уверены, что объект сегментировался примерно правильно. Если по размерам пешеход занимает примерно 2х4 суперпикселя, то, даже если он визуально сливается с фоном (стоит в тени, такое повсеместно встречается), можно спокойно перебирать блоки 2х4 суперпикселя и распознавать в них пешехода. Он не сольётся с фоном в единый сегмент, как при том же flood fill или других методах сегментации.

Мне кажется, что одним из самых продуманных и математически обоснованных методов сегментации являются суперпиксели. Они локализованы, достаточно структурированы и, самое главное, достаточно понятно, что с ними делать дальше. Можно трекать их на видео, можно с уверенностью сказать, что какой-нибудь большой ошибки в сегментации не будет (как тот же flood fill с большим порогом). Прекрасно сокращают размерность по сравнению с обычными пикселями и не приносят лишней сложности. Вот.

Проблема с быстродействием примитивов типа Собеля или Гаусса в целом успешно решается индустрией без участия конечных программистов предметной области. Есть уже бесплатные Intel IPP, появляется OpenVX. Мне под Интел из базовых вещей самому ничего оптимизировать уже и не надо. Всё есть. AMD выпустила Ryzen? Пусть выпускает и OpenVX под него. Есть ArrayFire и другие библиотеки. Кто в том же OpenCV пишет код на CUDA? Добровольцы? Нет, в основном сама Nvidia и пишет. OpenCL? Intel, AMD. Производители железа сами заботятся о быстродействии, сами оптимизируют алгоритмы, раздают свои библиотеки, пишут на ассемблере (интрисиках) библиотечный код. Им же продавать железо надо. Qualcomm делает свою библиотеку компьютерного зрения под свою платформу. Я лучше сосредоточусь на задаче в прикладной области. Сейчас зачастую даже С++ и OpenCL - это слишком низкий уровень для разработки алгоритмов. Хватает того же Питона с головой. Таковы времена.

Я сравниваю не столько x86 и ARM, сколько x86 и GPU (а это CUDA или OpenCL). Разница в быстродействии между последними Теграми и core i7 может вдруг оказаться не в пользу последнего. Такова реальность. Ну и оптимизация: при написании алгоритмов под видеокарты приходится оптимизировать алгоритм практически под каждую архитектуру. С процессорами аналогично: размер кэша, архитектура, поддержка всяких инструкций. Зачастую приходится иметь несколько копий библиотеки, оптимизированных под различные архитектуры что CPU, что GPU. P.S. Агнера Фога читал, немного в оптимизации разбираюсь. Глюков много. 1. Курсор постоянно мигает при движении со стрелочки на крести. 2. Тултипы прорисовываются плохо. 3. Интерфейс постоянно тормозит и замирает. 4. При размытии или детекции объектов у меня часть изображения (полоска внизу) не перерисовывается. 5. В меню пункт "Закрыть" ничего не делает. 6. На диск сохраняются временные файлы, которые не удаляются. Я открыл картинку на много мегапикселей, потыкал мышью в него и получил несколько гигабайт на диске. Ну и всякое другое. Для того, чтобы пользоваться было комфортно, я бы добавил двойную буферизацию и многопоточность. Простой MS Paint работает намного быстрее! Тестировать и тестировать.

Зря вы так про ARM. Те же Nvidia Tegra активно используются в беспилотниках и других автономных устройствах и вполне успешно обрабатывают в реальном времени большие потоки данных. Кроме того, все последние заказчики, которые у меня были хотели работу программ либо на Линукс серверах, либо на телефонах (Андроид и iOS). То есть места ассемблеру практически нет. Какие это были приложения: - видеоаналитика для охранных систем (в том числе на поворотных камерах и камер с беспилотников); - распознавание документов, визиток, кретидок; - распознавание лиц; - улучшение качества изображений.

О, спасибо! Похоже, что MOT challenge как раз то, что нужно. Попробую интегрироваться.

Понемногу развивается Multitarget-tracker. Добавляются разные параметры и алгоритмы как трекинга, так и вычитания фона. И встаёт вопрос о создании полноценных тестов именно для детектора движения, как целого. Такие хорошие тесты есть у bgslibrary для сегментации, есть для одиночного трекинга - VOT Challenge. На них удобно ориентироваться и проверять свои алгоритмы. А есть что-нибудь для детекторов движения? Я так понимаю, что нужен датасет из видео и аннотация в виде треков объектов на каждом из них. И код для тестирования. Можно для начала было бы написать к тем же PETS скрипт на Питоне, который будет запускать Multitarget-tracker. Тот в свою очередь сохранять свои треки, а скрипт сравнивать, анализировать и делать отчёт. Но меня как-то ломает этим заниматься. Кто-нибудь знает готовые решения?

Чем-то похоже на билатеральный фильтр

OpenCV Viz - это обёртка над VTK. Его и используют.

Склейка - это что-то типа ICP (пример из OpenCV)? Или какие алгоритмы имеются ввиду?

Nec - это японцы что ли? Или что-то другое? У меня на слуху всё больше Cognitec, разработки которого используют чуть ли не все российские системы распознавания. Хотя у Vocord, вроде, своё что-то, которое даже в Мегафейсе побеждало. Кто есть ещё в лидерах?

MVE - не то? Ещё много хорошего про Theia слышал, но там точно GEOTiff нет. Не, ортофотоплан так просто не сделаешь: там и плоскость не одна (горы, высокие здания, карьеры), высота разная, при большой протяжённости ещё разные ошибки нарастают. Там всё достаточно сложно на практике выходит

Глянул на камеры imaginsource, например: https://www.theimagingsource.com/products/industrial-cameras/gige-color/dfk33gp006/ Максимум 15 fps?!! Да любой быстрый объект уже исчезнет за это время из кадра. При распознавании автономеров при 30 fps автомобиль с номером часто попадает в кадр лишь однажды! Извини, конечно, но у того же Hikvision (качественный китай) есть камеры с лучшими характеристиками. Мне показалось, что эти камеры больше подходят для дефектоскопии на производстве, чем для наблюдения.

Я как-то ради получения опыта на добровольных началах участвовал в проекте Stadiounus. Там надо было делать реконструкцию футбольного матча по телетрансляцию. Это было давно, у меня толком ничего не вышло. Сейчас сайт проекта не открывается, видимо, не получилось. Сразу скажу, что раньше и не представлял на какие короткие дубли разбита трансляция, они постоянно сменяются. У меня в конце-концов кончились все идеи и я (с позором) капитулировал перед проблемой.

А параметры камеры в Фотоскане указывали? Там можно и без них, но если указать, то результат получается точнее.

Если изображение не сжимается, то объём памяти никак не изменится. Если сжимается, то каким алгоритмом? Может, тебе его надо просто уменьшить во сколько-то раз? А после увеличить и резкости добавить. Всё таки формулировка важна. Бить картинку на фиксированное число цветов смысла нет, лучше применить PCA, как советует Smorodov.

Непонятна терминология. Что означает выражение "только 20% доминирующих цветов"? Например, у тебя есть идельно красное изображение, т.е. один цвет определяет всю картинку. Где тут 20%? Теперь возьмём флаг России, триколор. Пусть он также будет идеальным, три цвета, каждый из которых занимает 33.(3)%. Как планируется сделать раздел в этом случае? А для двухцветного флага? Думаю, что рассмотрев разные крайние случаи и формализовав требования, ты сам выведешь формулу и поймёшь, что именно ты хочешь получить и как. P.S. Так же предлагаю вручную сделать такие идеальные тестовые картинки и на них оттестировать крайние случаи. Для понимания сути проблемы очень полезно.

Может, куда-то ошибки всё таки пишутся? Стандартные аутпуты смотрел?

Ну, автомобильные номера и не на такой скорости распознают. И на камерах часто fps не более 30, тут же секрет не в нём, а в верно выставленной скорости сработки электронного затвора (shutter speed). Так что всё возможно.

Потому что удобней, это же в Википедии написано. Можно сегментировать по цвету. Например, отслеживать луч лазерой указки, в пространстве HSV он будет более компактным. Зависит от задачи, конечно. Когда важна скорость работы, то часто работают с пространством YUV. Почему? Во-первых, это нативное цветовое пространство для многих видео кодеков и для того же jpeg. Декодировали и сразу работаем без преобразований в другие пространства. Во-вторых, многие алгоритмы не требуют работать с цветами, а только с яркостью, т.к. она несёт в себе большую часть информации. Можно искать линии, вычислять градиенты и т.д., и т.п. А что такое YUV? Это пространство, в котором первый канал содержит практически яркость и она хранится непрерывным куском в памяти. Очень удобно.