Pull to refresh
101
0
Ермолаев Игорь @ErmIg

Пользователь

Send message
Проблему перекачки данных они попытались решить при помощи графов — довольно элегантное решение.
Я думаю, что реализация на IPP будет даже быстрее, если конечно найдется именно та функция, что вам нужна. К сожалению за IPP нужно денежку платить.
У каждого, кто пытался работать с BGR-24 на SSE2, наверное получились свои собственные уникальные костыли :)
Я уже ранее немного ознакомился со стандартом. Пока, по моему сугубо личному мнению, перспективы OpenVX в ближайшей время довольно туманные — пол года до его выхода и еще не известно сколько до поддержки в различных устройствах (вспоминаем как со скрипом продвигалась поддержка OpenCL). Тем не менее в отдаленной перспективе вполне возможно его широкое распространение, так что вы делаете безусловно весьма полезное дело. За что вам большое спасибо!
Я больше по целым числам специализируюсь. Но MMX я уже не застал. Лет пять колупал SSE2, последний год — AVX2. Возможно, что скоро руки дойдут до NEON.
Наверное в некотором роде действительно, так оно и есть — я действительно написал очевидные для специалиста вещи. Но я себя сознательно ограничивал, так как хотел описать проблему в общих чертах, что бы она была понятна не специалистам. Возможно, что я был не прав.
Безусловно, у моего алгоритма есть недостатки (к кропу он не устойчив). Однако большинство случаев хватает и его. В частности очень эффективно ищет похожую картинку (картинку с другим разрешением или степенью сжатия).

P.S. К стати почему вы не ищете картинки по блогам и социальным сетям?
Ну так индексирование в моем алгоритме — это просто способ уменьшить количество сравнений. В моем случае оказалось достаточно трехмерного индекса, но ничего в принципе не мешает использовать индексы большей размерности, например, пятимерные индексы.
В принципе для поиска по загруженному изображению можно приспособить и более простой алгоритм:

habrahabr.ru/post/122372
Как-то ночью за окошком
Вырастает дивный гриб
И искусственное солнце…
Понимаю, что погиб.

Только нет во мне волненья,
Понимаю: это сон.
И расслаблено взираю
Как грядет Армагеддон.

Просыпаюсь и как прежде:
За окошком дивный гриб
И искусственное солнце…
Понимаю, что погиб.

Полон ужаса и страха.
Делать что? куда бежать?
Просыпаюсь тут повторно
Весь в поту, ядрена мать!
На сколько я понимаю, человек должен находится вплотную к камере. Иначе для обнаружения его микродвижений просто не хватит разрешающей способности камеры. Так же встает вопрос: как будут себя вести алгоритмы при нахождении в поле зрения камеры двух и более лиц. Лампы дневного света ощутимо мерцают — не помешает или это?
Опыт подсказывает, что даже с учетом уже имеющегося опыта в создании подобных проектов, разработка подобного рода решений занимает несколько месяцев. Итоговая точность будет за 90-95%. При этом прототип реализуется достаточно быстро (но он как правило имеет невысокую точность). Однако потом длительное время приходится его доводить то промышленного применения — оптимизация по точности и скорости исполнения, тестирование в различных условиях. Как правило, для тестирования готовится база видеороликов, которые предварительно размечаются в ручную.
Медианный фильтр, если его грамотно написать, вполне подходит для обработки реального видео (у меня, например, медианный фильтр 3х3 занимает менее 1 мс для 1 мегапиксельного серого изображения на одном ядре).
Да такая потенциальная возможность есть — теоретически можно даже повысить разрешение картинки путем анализа последовательных, слегка смещенных изображений (если данные смещения контролируемые). Однако на практике, оказывается у данного метода масса подводных камней — это цифровой шум, смазывание картинки из-за смещения камеры во время захвата кадра, погрешность метода определения субпиксельного сдвига, произвольность направление смещения и амплитуды камеры во время дрожания, как и периодичности этого процесса сводят на нет практическую применимость данного подхода.
А как цифровая стабилизация может поднять резкость? При наличии дрожания камеры, резкость обычно только понижается. В основном по двум причинам: 1) смазывание изображения из-за движения камеры 2) размытие изображения из-за его компенсационного субпиксельного сдвига, если последний выполняется при помощи билинейной интерполяции. Можно конечно накладывать специальные фильтры для устранения смазывания изображения, да и компенсацию выполнять другими методами (например, бикубической интерполяцией), однако это все довольно ресурсоёмко. Кроме того, для наших целей (аналитическая обработка изображения и детектирование движения) это размытие особо не мешает, а иногда даже помогает.
Если изображение дрожит, то нужно применять цифровую стабилизацию изображения. У нас для этого реализован достаточно эффективный алгоритм, позволяющий стабилизировать изображение с субпиксельной точностью.
Внутри конвейера только черно белое изображение, потому мне к сожалению ваш вариант не подходит.
А как на счет целочисленной (char, short, int) векторизации циклов — поддерживают ли ее компиляторы?
Можно. Вопрос только, что делать если эти изображения немного отличаются — например одним пикселем или несколькими. Нужно ввести критерий похожести. В моем случае это среднеквадратическое отклонение для серых изображений одного и того же размера. Но в принципе можно выбрать и любой другой критерий.

Information

Rating
Does not participate
Location
Минск, Минская обл., Беларусь
Date of birth
Registered
Activity