LINUX.ORG.RU

из rgb в grayscale


0

0

Постановка задачи:
Есть вэб камера, кадры с нёё обрабатываются по некоторым алгоритмам.
После замеров времени работы, было выяснено что дольше всех работает функция преобразования картинки в градации серого.
Отсюда вопрос, как это оптимизировать?
И как быстрее конвертировать, из rgb24 или из rgb565?
Может есть готовые заделы, оптимизированные, поскольку в opencv (которая щас используется) это не самым оптимальным образом сделано.

anonymous

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

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

eXire ★★
()
Ответ на: комментарий от eXire

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

eXire ★★
()
Ответ на: комментарий от anonymous

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

eXire ★★
()

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

anonymous
()
Ответ на: комментарий от generatorglukoff

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

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

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

KRoN73 ★★★★★
()
Ответ на: комментарий от anonymous

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

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

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

anonymfus ★★★★
()

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

anonymous
()

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

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

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

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

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

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

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

anonymous
()
Ответ на: комментарий от eXire

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

anonymous
()
Ответ на: комментарий от eXire

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

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.