из rgb в grayscale

Если так критично время преобразования в grayscale, почему бы не использовать камеру, которая сразу отдает картинку в grayscale.

PS: Не понимаю, что у вас там за алгоритмы, если самым долгим из них является color2grayscale

алгоритм несложный
там еше сравнение 2х картинок и binary threshold.

камеры надо уметь использовать любые дешевые. та с которой сейчас упражняюсь в grayscale картинку отдавать не умеет.

Не понятно, что здесь можно оптимизировать. 2 сложения и деление? Так куда уж меньше. В opencv это преобразование сделано нормально.

Возможно имеет смысл попробовать написать реализацию rgb2grayscale с использованием sse2 и обрабатывать в ней пиксели пачками, а не по одному. По идее должно выйти быстрее.

проще всего брать среднее арифметическое для каждого пикселя

а на sse можно сделать обработку сразу нескольких пикселей ?

С определенными допущениями - да. Если в качестве деления на 3 использовать деление на 4 (логический сдвиг на 2 вправо) то есть возможность обрабатывать по 8 пикселей за раз. Смотри в сторону sse2 и опкодов: paddw, psrlw. Идея в том, что в один 128-ми битный регистр загружаем 8 16-ти битных значений (например компонента R 8-ми пикселей), далее прибавляем к ним G и B компоненты и делаем сдвиг вправо командой psrlw.

извиняюсь, я забыл что у меня sse2 нет, камень то geode так кроме mmx ничё нет

>проще всего брать среднее арифметическое для каждого пикселя

Строго формально Y = (2*R + 4*G + B)/7

А так - видимо, SIMD надо юзать. Под такое и затачивалось.

Кстати, ни до sse, ни даже до mmx в асме я в своё время не добрался, но упомянутая формула в наше время считается за считанные такты. Пусть даже 5 тактов. В случае 640x480x24 это даст 22 кадра в секунду на 100МГц. А уже на 500МГц - 109к/с. Чему там тормозить?

Если у него есть MMX и нет SSE, то это Geode LX (как в OLPC). Следовательно, минимальная частота 433 МГц.

у меня уже закралось сомнение что я гдето не так намерял...

Я немного проясню ситуацию.

Процессор у меня будет geode lx800/500 500 МГц.

А камеры будет работать 3, т.е надо сигнал с 3х камер обрабатывать в реальном времени.

Камеры максимум выдают 24 кадра в секунду.

Получается 1000 / 24*3 = ~13 . Тоесть на обработку 1 кадра не более 13 миллисекунд.

Сейчас я тестил на P3 800 и там на обработку 1 кадра тратится ~20 миллисекунд.

Я не говорил что тормозит, я ищу возможность оптимизации если это возможно.

Месье, вы сами-то пробовали использовать сдвиг вправо на 2 для вычисления Y? Боюсь картинки после этого годятся разве что на выстаку абстрактного искусства...

Тут поэкспериментировал на досуге - наиболее быстрой оказалась формула y=(1<<r+2<<g+b)>>3. При этом она ещё и не сильно поганит качество картинки.

всем спасибо, направили на путь истинный
во первых переписал захват картинки в рукопашную
и конвертирование в gray тоже в рукопашную
остальное opencv
времена приемлемые вроде стали, целевого железа нет еще, проверить почестному негде