Видимо вначале идей собралось слишком мало, поэтому продлили срок подачи заявок на две недели, а теперь набралось СЛИШКОМ МНОГО, и они не успевают их обработать к заявленному сроку :-)
Вообще, между сайтом (который perceptualchallenge.intel.com) и текстом правил соревнования, постоянные какие-то мелкие несоответствия, ну, например одна из категорий на сайте называется «Creative User Experience» в то время, как в правилах нет такой категории, зато есть «Creative User Interface». И это большая таки разница.
Далее, по срокам на сайте было написано (да и сейчас в личке написано), что мол зайдите 9 июля за результатами, в то время, как в правилах ясно написано, что 9 числа результатов быть не может (ибо Ends at 9 July 2013 23:59 GMT).
Возможно эта неразбериха из за того, что конкурс проводят две компании (Intel Corporation & The Game Agency).
Но конечно не все этот форум читают, могли бы и оповестить по почте о задержке. Также не ясно что будет со сроками на разработку — ведь по факту из за задержки у разработчиков времени будет меньше на одну неделю (особенно у тех, кто больше одной идеи подал).
Навряд ли приложение не пропустят если будут мелкие раздражающие тормоза, которые проявляются только на реальном устройстве.
Есть масса косяков не фатальных для прохода в стор, но фатальных для конкурентоспособности приложения. То есть выпускать приложение без тестирования на реальном устройстве, как минимум безответственно.
А устройства для разработки там вообще достать реально? Потому как без тестирования на реальном устройстве приложение может работать, мягко говоря, не так как планировалось.
Ходят сильно неофициальные слухи, что под мак нет и не будет, а вот под линукс может быть и будет (особенно если под линуксом еще и андроид подразумевать).
Кроме того, API к камере под линукс, сколь я понимаю, существует от производителя самой технологии камеры (depth sense softkinetic). Но это именно доступ к камере, без алгоритмов обработки этих данных. То есть сейчас под линукс вариант — добыть эту либу от softkinetic под линукс (утверждается что она freely available on Linux) и использовать OpenCV для обработки полученных данных.
Да, API похоже обратно-совместимо. По крайней мере наше приложение с установленным новым SDK нормально запустилось без перекомпиляции (хотя работать стало, ясное дело, по другому).
Там еще дополнительные примеры на C# c GUI вменяемым появились — советую позапускать, поиграться с настройками алгоритмов (они сразу собраны, студия не нужна).
И, похоже, немного изменили projection — теперь результат отображения depth на color по другому не совпадает с rgb-изображением (теперь добавилось смещение по вертикали, смещение по горизонтали уменьшилось (и зависит от положения объекта в кадре — ближе к границам экрана смещение больше, в середине почти ноль)).
+ распознование лиц теперь умеет работать не только по 6ти feature point'ам, но и по семи (уголки рта, уголки глаз + кончик носа).
Глубже пока не копал (не было пока необходимости, хотя нужно еще uv map проверить).
Я не даром свиней и птичек в качестве примера выбрал — это крайний случай, когда приложение — вещь в себе.
Кроме того, «простые» пользователи обычно про API и не задумываются, а вот на номер версии смотрят. Смена мажорного номера версии должно нести некий message таковым пользователям тоже.
Думаю, в случае самодостаточности, имеет смысл мажорную версию менять, если пользователю придется серьезно переучиваться при переходе на новую версию (существенно изменился UI либо семантика приложения).
Вопрос по семантической нумерации: там предлагается менять мажорную версию когда ломается совместимость API. Но если мое приложение, это именно приложение, а не библиотека, то о каком API может идти речь? Ну вот пишу я очередную игру где пользователь, на этот раз, кидает свиней в птиц. И? Версии 2.0.0 не будет никогда?
Больше всего меня пугает там заголовок: «Средства для неразрушающего контроля». Что как бы намекает, что есть там и средства разрушающего контроля пульса человека…
Примитивнейшее решение для движения, которое я видел — на мочку уха микрофон повесить. На блютус-гарнитуру вешаем такой элемент и все. Второе решение, покруче — емкостные бесконтактные электроды для ЭКГ.
Гм. Я не уверен на счет микрофона. Собственно у нас решение на базе фотоплетизмографа, и тоже на мочку уха. При движениях (скажем ударных нагрузках, тот же бег) там довольно крупные motion artefacts, которые просто через прямые частотные методы не фильтруются, ибо имеют те же частоты что и пульс, и возникают также регулярно как и удары сердца.
ЭКГ, сколь я помню, требует два контакта на разные половинки тела. Точки измерения на мочке одного уха не достаточно. Собственно на базе ЭКГ работают все пояса (вешаются на грудь, там два электрода), и это сейчас самый надежный метод для измерения пульса на бегу. Но это не всегда удобно. Тем более что та же фотоплетизмограмма позволяет не только пульс вытащить из данных, но еще дыхание, изменение артериального давления, и так далее. Там много интересного :-)
Интересно, эта методика позволяет получать данные о пульсе только если человек неподвижно сидит перед камерой, или же даже если он активно разговаривает, жестикулирует и так далее?
Собственно одна из основных задач современной фотоплетизмографии — это определение пульса (а лучше получение нормальной пульсовой волны) когда человек активно двигается (например бегает). Как только она будет окончательно решена, на рынке появится множество часов которые умеют постоянно измерять пульс (то есть не получать данные с пояса, и не измерять пульс когда вы прикладываете вторую руку к часам (как например вот эти часы: www.sportline.com/products/heart-rate-monitors/solo-915-heartrate-mens.html), а самостоятельно круглосуточно снимать данные с руки). Как это научатся делать, следующий шаг — измерение сатурации там же.
PS. Предлагаю попробовать упрощенный вариант задачки топика. Берем, распечатываем bar-код на листок бумаги. Листок бумаги берем в руку и держим перед камерой. Сам бар-код распознается элементарно. Руку удары сердца также качают. Следовательно по движению листка с бар-кодом мы сможем измерить пульс.
Ну, можно было хоть курсивом выделить. А может и через таблицы как-нибудь… Надо будет поэкспериментировать (в коментарий, по крайней мере в превью, таблица не вставляется).
Вообще, между сайтом (который perceptualchallenge.intel.com) и текстом правил соревнования, постоянные какие-то мелкие несоответствия, ну, например одна из категорий на сайте называется «Creative User Experience» в то время, как в правилах нет такой категории, зато есть «Creative User Interface». И это большая таки разница.
Далее, по срокам на сайте было написано (да и сейчас в личке написано), что мол зайдите 9 июля за результатами, в то время, как в правилах ясно написано, что 9 числа результатов быть не может (ибо Ends at 9 July 2013 23:59 GMT).
Возможно эта неразбериха из за того, что конкурс проводят две компании (Intel Corporation & The Game Agency).
We are running a bit late on the judging of the idea submissions, due to the large volume. Our goal is to get the list of finalists out before the end of this week.
Но конечно не все этот форум читают, могли бы и оповестить по почте о задержке. Также не ясно что будет со сроками на разработку — ведь по факту из за задержки у разработчиков времени будет меньше на одну неделю (особенно у тех, кто больше одной идеи подал).
Есть масса косяков не фатальных для прохода в стор, но фатальных для конкурентоспособности приложения. То есть выпускать приложение без тестирования на реальном устройстве, как минимум безответственно.
Кроме того, API к камере под линукс, сколь я понимаю, существует от производителя самой технологии камеры (depth sense softkinetic). Но это именно доступ к камере, без алгоритмов обработки этих данных. То есть сейчас под линукс вариант — добыть эту либу от softkinetic под линукс (утверждается что она freely available on Linux) и использовать OpenCV для обработки полученных данных.
Подробней тут: DepthSenseSDK.
И, похоже, немного изменили projection — теперь результат отображения depth на color по другому не совпадает с rgb-изображением (теперь добавилось смещение по вертикали, смещение по горизонтали уменьшилось (и зависит от положения объекта в кадре — ближе к границам экрана смещение больше, в середине почти ноль)).
+ распознование лиц теперь умеет работать не только по 6ти feature point'ам, но и по семи (уголки рта, уголки глаз + кончик носа).
Глубже пока не копал (не было пока необходимости, хотя нужно еще uv map проверить).
Кроме того, «простые» пользователи обычно про API и не задумываются, а вот на номер версии смотрят. Смена мажорного номера версии должно нести некий message таковым пользователям тоже.
Неплохо бы такие утверждения подкреплять ссылкой на реальную статистику запусков. Иначе это просто желтизна и истерика.
А камеры работающие с длинноволновым ИК стоят бешеных денег и имеют довольно низкое разрешение.
Гм. Я не уверен на счет микрофона. Собственно у нас решение на базе фотоплетизмографа, и тоже на мочку уха. При движениях (скажем ударных нагрузках, тот же бег) там довольно крупные motion artefacts, которые просто через прямые частотные методы не фильтруются, ибо имеют те же частоты что и пульс, и возникают также регулярно как и удары сердца.
ЭКГ, сколь я помню, требует два контакта на разные половинки тела. Точки измерения на мочке одного уха не достаточно. Собственно на базе ЭКГ работают все пояса (вешаются на грудь, там два электрода), и это сейчас самый надежный метод для измерения пульса на бегу. Но это не всегда удобно. Тем более что та же фотоплетизмограмма позволяет не только пульс вытащить из данных, но еще дыхание, изменение артериального давления, и так далее. Там много интересного :-)
Собственно одна из основных задач современной фотоплетизмографии — это определение пульса (а лучше получение нормальной пульсовой волны) когда человек активно двигается (например бегает). Как только она будет окончательно решена, на рынке появится множество часов которые умеют постоянно измерять пульс (то есть не получать данные с пояса, и не измерять пульс когда вы прикладываете вторую руку к часам (как например вот эти часы: www.sportline.com/products/heart-rate-monitors/solo-915-heartrate-mens.html), а самостоятельно круглосуточно снимать данные с руки). Как это научатся делать, следующий шаг — измерение сатурации там же.
PS. Предлагаю попробовать упрощенный вариант задачки топика. Берем, распечатываем bar-код на листок бумаги. Листок бумаги берем в руку и держим перед камерой. Сам бар-код распознается элементарно. Руку удары сердца также качают. Следовательно по движению листка с бар-кодом мы сможем измерить пульс.
Врут.
Не реализовано:
clang.llvm.org/cxx_status.html