Хочу удостовериться в правильности подхода:
на входе имеем 16 бит RGB данные в формате 5/6/5, т.е. 5 бит на R, B, 6 бит на G.
на выходе нужно 18 бит, т.е. 6 бит на каждый цвет.

Думаю делать так: 5-битные цвета имеют разрешение цвета в 2 раза меньше чем 6-битный, значит их нужно "разтянуть" на 6-битную шкалу. Посему думал каждый полученный sample R или B умножать на 2 (сдвиг влево на 1), таким образом "разжимая" его шкалу линейно на 6-бит, но ессно теряя в резолюции в 2 раза относительно G (который натурально 6 бит).

Что скажем ? Есть лучшие способы сделать подобное ?
Спасибо

Я бы предварительно посмотрел, как кодируется серый цвет в одном и другом формате, так как именно окраска серых тонов является самым заметным артефактом неправильного преобразования цвета.

Да, спасибо, хорошая идея.
Значит нужно проверить color map конкретного дисплея насчет его кодировки по серому относительно полного комплекта RGB, и затем сопоставить это с кодировкой серой шкалы входного формата, так ?
Ежели подогнать серые оттенки, гарантирует ли это правильность цветов ?

А в принципе, может есть смысл рассмотреть перекодировку R, B в 6 бит по нелинейной шкале (обратное S) ?

Если на входе RGB 565, а не цветоразностный, то наверное нет смысла перекодировать что-либо, просто *2 (сдвиг или прямо назначить на нужные выводы дисплея...).
Кроме того, оттенки серого 6 бит и так выглядят неочень...
А какой дисплей?

Спасибо.
Да, дейсвительно, на входе RGB 565, пока закодировал в 666 просто сдвигом влево R и B, либо думаю просто добавлю нули (или '1', пока не уверен) а коде конвертируя в 18 бит.
Выходной дисплей: Kyocera TCG057QV1AC. Это 5.7" TFT со встроенным контроллером, принимает 18 бит RGB вход. В приципе основная информация идет ч/б, т.е. оттенки серого важны (хотя не требуется у них супер резолюция), но вход пред-определен как 565. Цвет нужен только для всяких overlayев (менюшки и т.д.), т.е. там очень высокая точность не сильно важна.

выкинуть нафиг младший бит в шестёрке и задействовать его под альфа канал

Не надо '1' - чистого черного цвета не будет, хотя 1ЕМР вряд ли будет сильно заметна.

Не понял ?
Зачем альфа канал ? В приципе про таковой знаю только по наслышеке, никогда с ним не приходилось работать еще. А вообще оно релевантно мне ?




Спасибо.
А что такое 1EMP ?

То же, что и LSB - Единица Младшего Разряда

Если картинка ч/б, то логичнее было бы взять монитор с 24-и битным интерфейсом. Неужели 6 битная ч/б картинка вас устраивает?

Для конкретной аппликации вполне устраивает, тут не идет речь о высокой графике, система работает (только пока на другой дисплей и TV монитор), разрешение по shades - устраивает (опять-же в рамках конкретной аппликации).

Хотя если-бы речь шла о высококачественной графике - наверняка-бы охотно согласился с вами.

И как результаты, получается?

Я как раз только-что вывел ч/б картинку на LCD панель, чтобы проверить выше сказанное. И получил какую-то непонятную проблему :

- итак, вход 565
- на дисплей 666 R и B сдвигаем на 1 влево (просто назначением пинов)
- пока отсутствует старший разряд (закрываем, к примеру диафрагму, темная картинка) - все впорядке. А как только появляется старший разряд - начинаются какие-то мелькания...

Может и не так все просто...

На данном этапе отображаем на OLED дисплее (похожее на то что обычно идет в видоискателях цифровых камер, там где электронные видоискатели, не оптические), картинка в видоискателе нормальная, т.е. нашим требованиям удовлетворяет. Там OLED имеет сериальный вход 8 бит (т.е. R -> G -> B, бит на каждый), но мы подаем 5/6/5 так что данные сдвинуты на MSB.
Кроме того идет выход видео на TV монитор, но там composite ессно, и я не уверен а каком формате там были данные в оригинале (до конвертации в composite) ибо это делается не нами и внутри системы в которую у нас доступа нет.

В вашем случае получается что кода старший разряд на входе обнулен (в 565 - темная картинка) а мы сдвигаем нулем влево - мы по идее все-равно должны получить примерно схожий уровен в выходном формате (0х01111 в 5-битном формате должен примерно соответствовать 0х011110). Небольшие искажения можно ожидать, но по идее ничего драмматического...
Нужно подумать что происходит в вашем случае...

В моем случае что-то другое, похоже на жуткие помехи по питанию

Ну, в вашем случае - вам виднее...

Сдвигайте R и B на 1 влево, и если их старший (5) бит равен 1 - добавляйте еще 1.
черный останется черным, а белый - белым.
0b000000 -> 0b000000
0b011111 -> 0b111110
0b100000 -> 0b100001
0b111111 -> 0b111111

Смело умножайте R и B на 2. Можно, с коррекцией младшего разряда, как предлагал _pv.
Формат 5-6-5 используется исключительно для экономии, позволяя вписаться в 16 разрядов. Человеческий глаз более восприимчив к зеленому цвету, поэтому он цифруется с большей точностью.

Да - фиг с ней с коррекцией младшего бита.

Во, быть одна очень важная деталь, о которой забыли:
если мы пишем в видеобуфер с камеры и одновременно выводим на монитор из этого же буфера, то получаем при динамической картинке помеху в виде горизонтальной полосы (ползущей по вертикали).
Это вполне логично, ведь когда мы читаем из буфера для вывода на монитор, то в один прекрасный момент мы доходим до строки, где в данный момент идет запись с камеры. Т.е. в верхней части монитора выводится новый кадр, а внизу - еще предыдущей. Именно поэтому этой помехи не видно на статической картинке. Похожий эффект возникает и при использовании черезсстрочной развертки...

Методы борьбы:
- синхронизировать вывод и ввод картинки. Подходит только если частоты ввода/вывода кратны.
- использовать две страницы памяти. В одну пишем новый кадр, из другой пока выводим, после меняем местами... Этот способ проверил - порядок...

Ну это-то логично но только если rates записи и чтения в/из буфера не равны. Иначе, если они равны и есть задержка чтения относительно записи, то чтение всегда по идее должно запаздывать ан постоянное тау, и тогда не должно быть помехи.
Есть задержки записи и чтения в/из буфера за счет того что физическиая длинна строки (в клоках) больше чем длинна видео данных, посему даже если скорость чтения у меня будет чуть ниже скорости записи, все равно поинтеры записи/чтения не должны пересекаться.
Все это пока рассчетные теории, буду проверять на практике в симуляции...

Все правильно. При равных кадровых и строчных частотах, т.е. если развертка одинаковая, никаких помех не будет, главное, чтобы чтение не опередило запись. Тем более, что есть кадровое гашение, когда запись кадра закончено, и можно спокойно дочитывать буфер, не опасаясь, что запись нового кадра его испортит.

Мы же эту тему обсуждали в другой теме...

Да, так и есть, обсуждали с вами. В данной ветке оно как-то палвно переросло в схожее русло...

У меня как раз вывод на дисплей 60 кадров/с, а с камеры идет 15...30 кадров/с. Потому синхронизация не всегда возможно, гораздо проще сделать 2 страницы...

Значит выводим на дисплей каждый кадр по нескольку раз после накопление очередного кадра в выходном буфере ? (если входная кадровая - кратна 60 конечно..)

Ага