Как стать автором
Обновить

Комментарии 19

Я уже ранее немного ознакомился со стандартом. Пока, по моему сугубо личному мнению, перспективы OpenVX в ближайшей время довольно туманные — пол года до его выхода и еще не известно сколько до поддержки в различных устройствах (вспоминаем как со скрипом продвигалась поддержка OpenCL). Тем не менее в отдаленной перспективе вполне возможно его широкое распространение, так что вы делаете безусловно весьма полезное дело. За что вам большое спасибо!
Спасибо за интерес к OpenVX! Вы совершенно правы, что до широкого распространения еще надо дожить, но OpenVX для реализации несколько (а, чаще всего, намного) проще, чем OpenCL, поскольку это просто C API. Так что есть надежда, что OpenVX будет распространяться быстрее.
Правильное дело делаете, надеюсь все получится и станет популярным.
Спасибо!
Любопытно. При программировании на OpenCL основная часть времени тратиться на перекачку в видеопамять и обратно. Если это время сравнимо с временем, за которое всё можно обработать на проце — смысла ускорять через видюху нет. На мобильных устройствах как я понимаю одна пямять. Значит ли это, что там можно будет напрямую вызывать распараллеливание без перекачки данных?
Проблему перекачки данных они попытались решить при помощи графов — довольно элегантное решение.
При корректной реализации OpenCL накладные расходы на копирование связаны с архитектурой памяти, а не с OpenCL. То есть если вы запускаете ваш OpenCL код на архитектуре с общей памятью для CPU и GPU, накладные расходы на копирование могут быть намного меньше, чем для систем с раздельной памятью. То есть решение о том, делать вычисления на CPU или GPU, зависят от архитектуры. OpenVX с graph API предоставляет абстракцию, благодаря которой вы о таких деталях не думаете, а решение о том, где делать вычисления, принимает алгоритм, реализующий вычисление графа, который для архитектуры с общей памятью примет одно решение, а для раздельной памяти — другое.
НЛО прилетело и опубликовало эту надпись здесь
Спасибо!
Похвальная инициатива, но вот только объясните мне глупому зачем строить видео-аналитику на архитектуре ARM/ASIC/DSP/FPGA?
Я конечно понимаю, что некоторые компании разрабатывают камеры со встроенной видео-аналитикой и строя камеру на ARM/ASIC/DSP/FPGA ускорение операций анализа видео-потока дает выйгрышь, но лично мне кажется, что это утопичная идея — чтобы камера занималась поиском номеров машин в видео-потоке или распознаванием лиц, это приведет к росту цены такой камеры, причем к значительному, гораздо проще производить обработку потока на серверах, их мощности гораздо проще нарастить.
Да, Вы конечно можете сказать, что грядет эра умных роботов и машин которые будут ездить без водителя и там без ARM не обойтись и для этого все это и делается, но пардон, все это звучит как минимум смешно, если до сих пор нет программы поиска и определения номерных знаков или дорожных знаком для смартфона (а может я плохо искал и она есть? ткните пальцем, буду примного благодарен).
НЛО прилетело и опубликовало эту надпись здесь
Столько внимания мобильным системам уделяется потому, что именно они сейчас предоставляют основной источник данных для компьютерного зрения, и с ними связаны наиболее актуальные задачи. Для мобильного телефона в первую очередь это даже не augmented reality, а улучшение снимков и видео (computational photography — HDR, intelligent focus and white balance, video stabilization и тп). Для автомобиля — детектирование пешеходов, детектирование смены ряда, предупреждение о столкновении с автомобилем впереди. Конечно, все такие системы имеют смысл только при интеграции с системой управления автомобилем — при пересечении границы ряда без включенного поворотника будет, например, дрожать руль, а при угрозе столкновения с пешеходом или автомобилем будет включаться торможение. Все такие задачи должны решаться на устройстве (мобильный телефон, автомобиль), потому что никакой пропускной способности сети не хватит, чтобы передавать данные на сервер, и обеспечить отсутствие задержек при ответе (latency).
На ARM сейчас действительно сложно что-то сделать, хотя наша система распознавания дорожных знаков как раз работает на мощном смартфоне в реальном времени. Давайте посмотрим немного с другой стороны. Почему на мобильных телефонах есть приложения с достаточно сложной компьютерной графикой (игры, конечно, в первую очередь)? Потому что к моменту, когда смартфоны начали производить массово, уже был OpenGL, была создана его мобильная версия, и все производители графических карт знали, что нужно программистам. Были сделаны графические карты и драйверы к ним, реализующие OpenGL. Вот мы хотим, чтобы такая же ситуация была с компьютерным зрением — основные операции должны быть стандартизированы, тогда появятся ускорители (они, кстати, уже появляются), и программисты смогут создавать сложные программы.

Определение номерных знаков — это нишевая задача, я не могу придумать, зачем ее программировать на мобильном телефоне. Распознавание дорожных знаков мы делаем для автомобилей, а на смартфон портировали просто для того, чтобы было проще демонстрировать потенциальным клиентам. Тем более, что железки, которые стоят в автомобиле, похожи на смартфон (иногда несколько мощнее, иногда слабее). К слову, распознавание знаков реализовано не только в Mercedes, а во вполне бюджетном Ford Focus 3 (link).
Извините, но я не алигарх и у меня нет столько денег чтобы купить автомобиль типа Mercedes Benz S500, я вот неск. тыс. рублей на программу опред. знаков для смартфона я бы выделил.

И покажите ка мне эту встроенную в андроид систему распознавания лиц, а? Разблокировки экрана по графическому паролю это даже не работа с жестами, вы что то путаете.

Преобразование 2D в 3D ну да это круто, в моём LG TV это есть, а толку то, за пол года его эксплуатации я ни разу не воспользовался этой функцией, как и многие другие облодатели таких TV. Так что данный функционал просто не востребован, хотя и был включён в стоимость TV.

Лучше бы производители железа и софта объединились инаписали открытую систему офлайн распознавания голоса — она как раз более востребована на рынке. Только не говорите что такая система уже есть, да есть но она закрыта и работает только на андроиде.
Android face unlock — www.android.com/about/ice-cream-sandwich/ (см Face Unlock). Так же гуглятся пользовательские отзывы — что система неидеальна, но работает достаточно неплохо, и является полезной.
Гигаспасибо за пост. Я буду теперь отсылать к нему всех интересующихся OpenVX, а таких немало.

У меня только мелкая придирка (я, помимо прочего, главред блога Intel на хабре, т.е. по работе постоянно придираюсь к текстам разных авторов, так что можете не обращать внимания, если не хотите ). А именно, я не понимаю, что тут делает фраза «Например, используя NEON оптимизацию, cv::resize можно ускорить более чем в 7 раз на ARM (см [1]).»? Векторизация пропрционально ускоряет любой исходный код, независимо от того, медленный он или быстрый, так что это знание ничего не дает. Кроме того, если ускорить в 7 раз, то по числам получается, что и на одном CPU все будет работать нормально (3мс на ф-ю), но оттуда делается вывод «Стало очевидно, что необходимо более эффективное взаимодействие кода с SoC,....GPU...». В общем, без этой фразы про NEON я понимаю все, с ней — ничего :) Поясни, плииз.
Вика, привет! Тут ускорение было на одном потоке продемонстрировано, распараллеливания не было. В целом, я согласен, что логика хромает — я старался писать лаконично. Но, я думаю, общая идея понятна: есть функции, которые очень хорошо ускоряются с использованием NEON, а есть другие функции, которые лучше ускоряются на GPU, а есть специальные ускорители, вычисляющие оптический поток. И хочется иметь единый способ взаимодействия со всем этим многообразием. Хотя такая логика — это тоже сильное упрощение реального мира :-)
Вика, привет! Тут ускорение было на одном потоке продемонстрировано, распараллеливания не было. В целом, я согласен, что логика хромает — я старался писать лаконично. Но, я думаю, общая идея понятна: есть функции, которые очень хорошо ускоряются с использованием NEON, а есть другие функции, которые лучше ускоряются на GPU, а есть специальные ускорители, вычисляющие оптический поток. И хочется иметь единый способ взаимодействия со всем этим многообразием. Хотя такая логика — это тоже сильное упрощение реального мира :-)
Отличная инициатива, а как обстоят дела со внедрением этой технологии через 2 с небольшим года?

Ох, как быстро время пролетело :-)


Мы (рабочая группа OpenVX) выпустили первую версию спецификации (OpenVX 1.0) в 2014 году, а в 2015 было выпущено обновление 1.0.1 с рядом улучшений, в основном, инфраструктурных функций. Стандарт включает не только спецификацию, но и conformance tests, которые проверяют реализацию стандарта на соответствие спецификации. В настоящее время ряд компаний публично заявили о создании реализации OpenVX, вся информация доступна в новостях https://www.khronos.org/news/categories/category/openvx. Информация о последней версии спецификации доступна здесь https://www.khronos.org/openvx/. Следите за новостями!

Зарегистрируйтесь на Хабре, чтобы оставить комментарий