Pull to refresh

Comments 19

Я уже ранее немного ознакомился со стандартом. Пока, по моему сугубо личному мнению, перспективы OpenVX в ближайшей время довольно туманные — пол года до его выхода и еще не известно сколько до поддержки в различных устройствах (вспоминаем как со скрипом продвигалась поддержка OpenCL). Тем не менее в отдаленной перспективе вполне возможно его широкое распространение, так что вы делаете безусловно весьма полезное дело. За что вам большое спасибо!
Спасибо за интерес к OpenVX! Вы совершенно правы, что до широкого распространения еще надо дожить, но OpenVX для реализации несколько (а, чаще всего, намного) проще, чем OpenCL, поскольку это просто C API. Так что есть надежда, что OpenVX будет распространяться быстрее.
Правильное дело делаете, надеюсь все получится и станет популярным.
Любопытно. При программировании на OpenCL основная часть времени тратиться на перекачку в видеопамять и обратно. Если это время сравнимо с временем, за которое всё можно обработать на проце — смысла ускорять через видюху нет. На мобильных устройствах как я понимаю одна пямять. Значит ли это, что там можно будет напрямую вызывать распараллеливание без перекачки данных?
Проблему перекачки данных они попытались решить при помощи графов — довольно элегантное решение.
При корректной реализации OpenCL накладные расходы на копирование связаны с архитектурой памяти, а не с OpenCL. То есть если вы запускаете ваш OpenCL код на архитектуре с общей памятью для CPU и GPU, накладные расходы на копирование могут быть намного меньше, чем для систем с раздельной памятью. То есть решение о том, делать вычисления на CPU или GPU, зависят от архитектуры. OpenVX с graph API предоставляет абстракцию, благодаря которой вы о таких деталях не думаете, а решение о том, где делать вычисления, принимает алгоритм, реализующий вычисление графа, который для архитектуры с общей памятью примет одно решение, а для раздельной памяти — другое.
UFO just landed and posted this here
Похвальная инициатива, но вот только объясните мне глупому зачем строить видео-аналитику на архитектуре ARM/ASIC/DSP/FPGA?
Я конечно понимаю, что некоторые компании разрабатывают камеры со встроенной видео-аналитикой и строя камеру на ARM/ASIC/DSP/FPGA ускорение операций анализа видео-потока дает выйгрышь, но лично мне кажется, что это утопичная идея — чтобы камера занималась поиском номеров машин в видео-потоке или распознаванием лиц, это приведет к росту цены такой камеры, причем к значительному, гораздо проще производить обработку потока на серверах, их мощности гораздо проще нарастить.
Да, Вы конечно можете сказать, что грядет эра умных роботов и машин которые будут ездить без водителя и там без ARM не обойтись и для этого все это и делается, но пардон, все это звучит как минимум смешно, если до сих пор нет программы поиска и определения номерных знаков или дорожных знаком для смартфона (а может я плохо искал и она есть? ткните пальцем, буду примного благодарен).
UFO just landed and posted this here
Столько внимания мобильным системам уделяется потому, что именно они сейчас предоставляют основной источник данных для компьютерного зрения, и с ними связаны наиболее актуальные задачи. Для мобильного телефона в первую очередь это даже не 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/. Следите за новостями!

Sign up to leave a comment.