[python] 16-битный цвет в 32-битный цвет.

32 бита это A8R8G8B8, наверняка тебе нужно B5G6R5 перевести в R8G8B8.

На питоне такое сложно найти, проще переписать алгоритм с с++. В 3д движках он должен быть.

Я не осиливаю битовые операции в питоне. Я так понимаю, что надо занулять ненужные биты и делать сдвиг? Но тогда как же это будет тормозить-то с питоновым резиновым интом...

Опечатка в заголовке, 24-битный цвет.

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

Не будет это бысро работать в питоне. Как и предлагалось выше - лучший выход сделать Python/C extension.

Генерируй виндовый HiColor bmp, прицепляя в начало hardcoded - шапку (*). Потом передавай его какому-нибудь консольному конвертору через fork чтобы получить более православный формат. Еще можно посмотреть поддерживает ли tiff или tga 16-битный цвет если не хочется заморачиваться еретическим bmp.

(*) Т.к все параметры типа высоты, ширины и глубины цвета зафиксированы то шапку можно захардкодить.

BTW, 24-битный цвет TIFF поддерживает.

Если мне не изменяет память, в 16-битном .bmp на каждую RGB-составляющую пикселя отводится по 5 бит, т.е. пошаманить с маскосдвигами все равно придется.

/me весь в шоке, у меня простенькое realtime распознавание образов, а тут 30 вызовов внешнего бинаря в секунду на слабеньком ARM процессоре.

>у меня простенькое realtime распознавание образов

/0

Хорошо-хорошо, стремящееся не тормозить по полчаса.

>Хорошо-хорошо, стремящееся не тормозить по полчаса.

Полюбасу, непонятно чего ты добиваешься. Если ты пистоном будешь работать с большими битмапами попиксельно, то это по любому будет тормозить как аццкий песец, причем раздербанивание байта сдвигами займет один процент времени.

>Полюбасу, непонятно чего ты добиваешься. Если ты пистоном будешь работать с большими битмапами попиксельно, то это по любому будет тормозить как аццкий песец, причем раздербанивание байта сдвигами займет один процент времени.

я как-то делал на .net через Lock() с прямым копированием пикселей, но все равно на 6000х3000 картинках тормозило феерически

Я выделяю 300 нужных мне пикселей и сравниваю с эталонными цветами алгоритмом «сумма модулей разности компонент».

Попробую, как скажется на проихводительности распаковывание данных через struct и выделение нужного битовым сдвигом. Эх, почему только нету в struct распаковки битов?..

/me весь в шоке, у меня простенькое realtime распознавание образов, а тут 30 вызовов внешнего бинаря в секунду на слабеньком ARM процессоре.

...и все это - на питоне? Да, месье знает толк.

Для работы с изображениями в python есть библиотечка PIL - http://www.pythonware.com/products/pil/ Умеет дофига всего, и, думаю, о скорости разрабы тоже позаботились. Посмотри, может окажется полезна.

Поставить libv4l и запускать твою софтину так:

LD_PRELOAD=/path/to/v4l2convert.so ./your-stuff

В your-stuff использовать V4L2_PIX_FMT_RGB32 (RGB + альфа, пустая).

/me весь в шоке, у меня простенькое realtime распознавание образов, а тут 30 вызовов внешнего бинаря в секунду на слабеньком ARM процессоре.

Нафиг тебе тогда цвета вообще? Используй слой яркости в V4L2_PIX_FMT_YUV420 или сразу V4L2_PIX_FMT_GREY.

Месье начинал с ноутбуком и не знал, во что это выльется. Вся система на питоне, состоит из 3х - 4х процессов, обменивающихся данными через udp и в одном месте через пайп. И да, теперь это все трамбую на ARM. И там не только видео много кушает(

Прошу прощения, но моя китайская пластмассовая камера на GPIO и китайский пластмассовый модуль ядра к ней имеют что-то общее с v4l1? Жажду продолжения.

Как зачем, я же написал, что сравниваю еще с пятью эталонными цветами.

Прошу прощения, но моя китайская пластмассовая камера на GPIO и китайский пластмассовый модуль ядра к ней имеют что-то общее с v4l1? Жажду продолжения.

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

Пиши сишный плагин для питона, который будет rgb16 в rgb32 конвертить.

Камера мегадубовая, фиксированное разрешение, 16 бит, доступ - чтение из файла. К ней идет example код на плюсах, который тупо читает из камеры и пишет в 16-битный framebuffer. Работает. Только мне счастья не прибавляет, т.к. моя софтина юзает v4l2 через opencv, от которого теперь хочу избавиться. И вот единственное мешающее - цвета.

Кстати, может ты в курсе - что делает v4l1-compat.ko и как его юзать?

Камера мегадубовая, фиксированное разрешение, 16 бит, доступ - чтение из файла. К ней идет example код на плюсах, который тупо читает из камеры и пишет в 16-битный framebuffer. Работает. Только мне счастья не прибавляет, т.к. моя софтина юзает v4l2 через opencv, от которого теперь хочу избавиться. И вот единственное мешающее - цвета.

Так хоть какой-нибудь Video4Linux есть или нет? 1-й, 2-й - неважно.

Кстати, может ты в курсе - что делает v4l1-compat.ko и как его юзать?

.ko или .so?

Ну правда нету.

.ko, модуль ядерный. просто так не modprob'ится, интересно, а в доки лезть лень.

Ну правда нету.

Ну тогда не парься и напиши плагин на Си, который в 32-битном цвете отдавать будет. Можно даже с векторными операциями для пущей скорости замутить, если они в твоём арме есть.

.ko, модуль ядерный. просто так не modprob'ится, интересно, а в доки лезть лень.

В /var/log/messages посмотри, что ему не нравится. Исходя из названия, похоже, что мапит v4l1 вызовы на v4l2 (для софта, который v4l2 не умеет).

PIL