Как насчет воспользоваться Гаусс-размытием?
Сила размытия будет определять границу между подавлением шумов и чувствительностью определения движения. Определить силу размытия можно на этапе калибрации: включить камеру на неподвижную сцену и снять первые десяток-два кадров для проведения сравнения и выделения шумов.
После того, как с шумами разобрались, остается проблема автоподстройки камеры под изменение светового заполнения сцены. Эту проблему можно как игнорировать (в случае, если камера профессиональная и подобная автоподстройка может быть выключена), так и обработать далее:
— выбросить «мигающий» кадр
— определить, не произошло ли полное перестроение источников света (включили/выключили свет в помещении)
Слишком большое количество дельт можно убрать, разбив алгоритм на три стадии: грубый анализ, уточнение, определение границ движущегося объекта.
Грубый анализ можно реализовать через вычитание двух соседних (а может и не соседних) размытых гауссом кадров — Вы получите перемещение контрастных точек. После этого проведение уточнения следует делать в окрестностях этих точек, не тратя процессорное время на неизменную часть кадра. Определение границ объекта может проходить как с помощью готовых алгоритмов (заливка, повышение контрастности), так и прикидочным образом с помощью попиксельного/поблочного вычитания.
Спасибо.
Заодно задайте, пожалуйста вопрос, насколько критичным они считают риск того, что оригинальное решение могут перевести на русский язык и адаптировать, уничтожив клоны?
«Это новый инвестиционный проект компании Fast Lane Ventures» o_O
То есть забабахать баблос в клон фиг знает чего наобум выбранного из топа Alex-ы — это нормально?
Я все больше и больше разочаровываюсь в адекватности инвестиционных компаний.
Думаю, что разница лишь в качестве микрофона. Т.к. один хрен, ваша запись голоса отправляется на сервера гугла для распознавания, а не обрабатывается на текущем девайсе.
Я говорю о качестве. И их продано в 3.5 раза больше не потому что Андроид, а потому что его ставят уже куда ни попадя, не удосуживаясь выпускать своевременные обновления и выстраивать железо под полную совместимость с ОС.
Да сделайте уже упор на качество: железо, ОС, набор приложений!
Тогда и будут уходить, как горячие пирожки с яблоками, а то и сделано косяк-наперекосяк, и гугл руками разводит, типа мы вам дали ОС, разбирайтесь, и при этом еще жалуются на что-то… шлак.
Ну, смотрите. Фишка в том, что не всякое можно мешать воедино.
Так или иначе у Вас должно быть разделение, чтобы не было хардкода, чтобы соответствовать объектной структуре Вашего приложения.
Дело в следующем:
Вы сказали, что подобный прием используется в Javascript библиотеках, таких, как, например, jQuery.
К слову, такое еще используется во всяких библиотеках, которые строят чарты вроде openflashchart.
И там, и там цепочки выстраиваются в рамках первого главного узлового объекта и заканчиваются сразу, как только мы исчерпали скоуп. Да, не смотря на то, что это не ORM, скоупы никто не отменял.
Важно понимать, что действия, которые Вы выполняете такими методами должны быть четко связаны с предыдущим элементом или его родителем. В противном случае Вы получаете обычное функциональное программирование, только не через точку с запятой, а через стрелочку.
Веду к тому, что архитектурно работу Вашего приложения нужно выстраивать следующим образом:
function APP(){return Application::Instance();}
// при создании экземпляра объекта приложения (синглтон), автоматически вызывается метод Init(), который отвечает за загрузку конфигов и первичную инициализацию переменных
App()->group=123;
App()->student=431;
// к слову, две предыдущие строки - лишние. Если Вы хотите работать с $_REQUEST, имеет смысл загнать все параметры в свойства объекта Application автоматически на этапе инициализации, либо забросить их в массив и получать доступ к ним через волшебные методы, ну или воспользоваться кодом ниже:
/*
public function __get($name){
return isset($_GET[$name]) ? $_GET[$name] : (isset($_POST[$name]) ? $_POST[$name] : null);
}
*/
// А теперь самое интересное:
APP()->addTree () // добавили в приложение дерево
->InitFromConfig () // проинициализировали дерево из конфига
->ActivateGroup (APP()->group) // сделали активным узел с группой
->ActivateStudent (APP()->student); // подсветили текущего пользователя
APP()->addContentField(APP::C_PERSONAL_PAGE) // добавили в приложение область контента с типом "персональная страница"
->AttachUserProfile( APP()->sudent ); // и отобразили профиль выбранного студента
Все дальнейшие действия точно так же атомарно бьются, а за атом принимается любая самостоятельная группа элементов интерфейса.
Ну а дальше — рендер, который в случае раздельной архитектуры должен идти отдельной прослойкой после того, как были выполнены все действия с данными.
Что касается запросов на изменение отдельно аватарки или выборочных полей в профиле студента, то здесь тоже все просто и красиво с теми же объектно-ориентированными цепочками команд.
// уровень обработки данных.
// грубый пример реализации функционала выборочного изменения частей профиля
if (APP()->ajax){
switch (APP()->action){
case 'changeAvatar':
APP()->Students()->getById(APP()->studentId)
->setAvatar($_FILES['avatar'])
->Save();
break;
case 'changeAvatar':
APP()->Students()->getById(APP()->studentId)
->setName(APP()->name) // все проверки и санация переменных внутри метода
->Save();
break;
}
die(); // это был всего лишь ajax-запрос на изменение. Здесь перед самоликвидацией можно поставить вывод JSON-ответа о том, что все прошло хорошо.
}
Таким образом все получается аккуратно:
— отдельные аспекты описаны отдельно
— потоки команд применены для всех объектов
— можно четко отделить обработку данных от непосредственного вывода
Главное — не переусердствовать и видеть границу между «красиво» и «понятно и работает»
Сила размытия будет определять границу между подавлением шумов и чувствительностью определения движения. Определить силу размытия можно на этапе калибрации: включить камеру на неподвижную сцену и снять первые десяток-два кадров для проведения сравнения и выделения шумов.
После того, как с шумами разобрались, остается проблема автоподстройки камеры под изменение светового заполнения сцены. Эту проблему можно как игнорировать (в случае, если камера профессиональная и подобная автоподстройка может быть выключена), так и обработать далее:
— выбросить «мигающий» кадр
— определить, не произошло ли полное перестроение источников света (включили/выключили свет в помещении)
Слишком большое количество дельт можно убрать, разбив алгоритм на три стадии: грубый анализ, уточнение, определение границ движущегося объекта.
Грубый анализ можно реализовать через вычитание двух соседних (а может и не соседних) размытых гауссом кадров — Вы получите перемещение контрастных точек. После этого проведение уточнения следует делать в окрестностях этих точек, не тратя процессорное время на неизменную часть кадра. Определение границ объекта может проходить как с помощью готовых алгоритмов (заливка, повышение контрастности), так и прикидочным образом с помощью попиксельного/поблочного вычитания.
Заодно задайте, пожалуйста вопрос, насколько критичным они считают риск того, что оригинальное решение могут перевести на русский язык и адаптировать, уничтожив клоны?
То есть забабахать баблос в клон фиг знает чего наобум выбранного из топа Alex-ы — это нормально?
Я все больше и больше разочаровываюсь в адекватности инвестиционных компаний.
idkfa от пиратов
idclip от штормов и рифов
Ну и вдогонку, количество вирей. Да оно еще большее решето, чем java-апплеты на кирпичных телефонах.
www.securelist.com/ru/images/vlill/q3_malware2011_pic02.png
Тогда и будут уходить, как горячие пирожки с яблоками, а то и сделано косяк-наперекосяк, и гугл руками разводит, типа мы вам дали ОС, разбирайтесь, и при этом еще жалуются на что-то… шлак.
А в остальном правы, выше оставил комментарий.
Так или иначе у Вас должно быть разделение, чтобы не было хардкода, чтобы соответствовать объектной структуре Вашего приложения.
Дело в следующем:
Вы сказали, что подобный прием используется в Javascript библиотеках, таких, как, например, jQuery.
К слову, такое еще используется во всяких библиотеках, которые строят чарты вроде openflashchart.
И там, и там цепочки выстраиваются в рамках первого главного узлового объекта и заканчиваются сразу, как только мы исчерпали скоуп. Да, не смотря на то, что это не ORM, скоупы никто не отменял.
Важно понимать, что действия, которые Вы выполняете такими методами должны быть четко связаны с предыдущим элементом или его родителем. В противном случае Вы получаете обычное функциональное программирование, только не через точку с запятой, а через стрелочку.
Веду к тому, что архитектурно работу Вашего приложения нужно выстраивать следующим образом:
Все дальнейшие действия точно так же атомарно бьются, а за атом принимается любая самостоятельная группа элементов интерфейса.
Ну а дальше — рендер, который в случае раздельной архитектуры должен идти отдельной прослойкой после того, как были выполнены все действия с данными.
Что касается запросов на изменение отдельно аватарки или выборочных полей в профиле студента, то здесь тоже все просто и красиво с теми же объектно-ориентированными цепочками команд.
Таким образом все получается аккуратно:
— отдельные аспекты описаны отдельно
— потоки команд применены для всех объектов
— можно четко отделить обработку данных от непосредственного вывода
Главное — не переусердствовать и видеть границу между «красиво» и «понятно и работает»
Vendors::GetById (APP()->vendorId) -> Delete();