Ну тут уже специфика конкретной задачи, нужно просто экспериментировать, вряд ли я смогу чем-то помочь)
По поводу цветов, кстати, если они играют на изображениях большую роль — возможно есть смысл вместо «обычного» усредненного чб изображения подать на вход один из цветовых каналов, на котором объект лучше всего различим с точки зрения детектора. А для чб исходников — подвигать контраст, ну или еще какие параметры, смотря на что детектор точек лучше отзовется.
На счет размеров, SIFT и SURF хоть и scale invariant, но в определенных пределах, поэтому есть смысл иметь не одно образцовое изображение, а несколько: в разных масштабах и, возможно, под разными углами. Искать придется каждое из них по очереди, так что тут уже баланс между производительностью и точностью.
А поиск нескольких объектов и выделение среди множества похожих — отдельная головная боль, тут возможно стоит проанализировать расположение найденных точек, как-то локализовать их сгущения и анализировать по новой уже эти фрагменты изображения по отдельности.
Ну сам RANSAC, если на пальцах, работает примерно следующим образом. Пусть у нас есть сопоставленные друг другу множества особых точек source и dest. Алгоритм берет случайным образом 4(для гомографии) точки из source и соответствующие им из dest. Предполагается, что эти 4 точки сопоставлены верно. Тогда по этим точкам вычисляется преобразование из source в dest, которое представляет собой некую матрицу H_current. Затем по этой матрице мы преобразуем каждую точку из source и смотрим, попала ли она геометрически в окрестность «своей» точки в dest. Если да, то помечаем ее как inline, в противном случае как outline и считаем общее количество инлайнов. На этом первая итерация заканчивается. Потом берем случайно еще 4 точки и так далее N раз. Если в очередной раз получаем инлайнов больше, чем в лучший из предыдущих => H_best = H_current. В итоге получаем некоторую H_best, для которой количество инлайнов максимально, в этом случае пересчитываем матрицу преобразования уже не для 4 точек, а для всех инлайнов и возвращаем полученную матрицу.
В случае вашей задачи, чтобы сделать вывод о наличии объекта на изображении, можно было бы просто оценить количество инлайнов в лучшем варианте, найденном RANSAC. Однако, findHomography() возвращает нам уже готовую матрицу преобразования, которая нам по сути и не нужна. Но если не лезть в код алгоритма, то самое простое на мой взгляд — «отмотать» вручную алгоритм на шаг назад. То есть, у нас есть sample, image и матрица H преобразования из sample в image(ну или наоборот). Можно просто в лоб каждую особую точку sample преобразовать матрицей H и посмотреть, попала ли она геометрически в окрестность соответствующей ей точки на image. Если таких попаданий достаточно много, то можно сказать, что объект присутствует. А сколько «много» их нужно — выяснить экспериментально, на нескольких примерах пустого фона и фона с объектом. Чем больше особых точек на картинке с объектом обнаружится на собственно объекте, тем лучше это по идее должно работать. Советую поэкспериментировать с параметрами детекторов и самим детектором(возможно лучше получится с ORB). Еще возможно есть смысл как-то поработать с исходным изображением, чтобы облегчить жизнь детектору. Например, яркость выровнять, если есть перепады. Но это уже мои предположения)
Функции send и read — это по сути обертки для работы с кодом отсюда: msdn.microsoft.com/en-us/library/ff802693.aspx
Что касается самого измерения — тут как раз второй случай. Одна итерация цикла — с момента отправки первого запроса и до момента получения второго ответа, на это есть около 30 мс, в которые в принципе удается уложиться даже с запасом, если бы не отдельные выбросы
Да, как раз по похожим темам прошелся. Основной вопрос не в самом таймере, а в том, что он показывает, какова причина этих выбросов. Сам таймер проверю более точным, но в основном мои надежды на то, что помогут эксперименты с приоритетами.
Спасибо, помогло немного разобраться:) В принципе, если timeGetTime действительно при соответствующих настройках выдает точность 1 мс и этим значениям можно верить, то этой точности будет достаточно. Но можно попробовать проверить более точным таймером.
В том-то и дело, что не является, но именно W7 изначально заложена в эту задачу :( Понятно, что настоящего RT не будет, но для начала хочется максимально, насколько это возможно, к нему приблизиться, вполне возможно, что этого будет достаточно. Ну или хотя бы выяснить, как штатные настройки приоритета влияют на ситуацию. Вопрос в том, как это правильно сделать.
Уже имеется система с ext4, проще отключить, чем заморачиваться с конвертацией, если она возможна, или сносить все к чертям — если нет. Да и судя по имеющейся информации, ext4 — наиболее оптимальный вариант. А связываться с экзотикой вроде btrfs пока не хочется.
По поводу цветов, кстати, если они играют на изображениях большую роль — возможно есть смысл вместо «обычного» усредненного чб изображения подать на вход один из цветовых каналов, на котором объект лучше всего различим с точки зрения детектора. А для чб исходников — подвигать контраст, ну или еще какие параметры, смотря на что детектор точек лучше отзовется.
На счет размеров, SIFT и SURF хоть и scale invariant, но в определенных пределах, поэтому есть смысл иметь не одно образцовое изображение, а несколько: в разных масштабах и, возможно, под разными углами. Искать придется каждое из них по очереди, так что тут уже баланс между производительностью и точностью.
А поиск нескольких объектов и выделение среди множества похожих — отдельная головная боль, тут возможно стоит проанализировать расположение найденных точек, как-то локализовать их сгущения и анализировать по новой уже эти фрагменты изображения по отдельности.