|
Подгонка 5/6/5 RGB под 18 бит (6/6/6) RGB |
|
|
|
Feb 21 2008, 18:07
|
Гуру
     
Группа: Свой
Сообщений: 2 563
Регистрация: 8-04-05
Из: Nsk
Пользователь №: 3 954

|
Цитата(torik @ Feb 21 2008, 18:54)  - итак, вход 565 - на дисплей 666 R и B сдвигаем на 1 влево (просто назначением пинов) Сдвигайте R и B на 1 влево, и если их старший (5) бит равен 1 - добавляйте еще 1. черный останется черным, а белый - белым. 0b000000 -> 0b000000 0b011111 -> 0b111110 0b100000 -> 0b100001 0b111111 -> 0b111111
|
|
|
|
|
Feb 22 2008, 11:06
|

Частый гость
 
Группа: Свой
Сообщений: 99
Регистрация: 27-10-07
Из: СПб
Пользователь №: 31 797

|
Цитата(Саша Z @ Feb 20 2008, 22:39)  Хочу удостовериться в правильности подхода: на входе имеем 16 бит RGB данные в формате 5/6/5, т.е. 5 бит на R, B, 6 бит на G. на выходе нужно 18 бит, т.е. 6 бит на каждый цвет. Смело умножайте R и B на 2. Можно, с коррекцией младшего разряда, как предлагал _pv. Формат 5-6-5 используется исключительно для экономии, позволяя вписаться в 16 разрядов. Человеческий глаз более восприимчив к зеленому цвету, поэтому он цифруется с большей точностью.
|
|
|
|
|
Feb 22 2008, 11:53
|

Гуру
     
Группа: Свой
Сообщений: 2 113
Регистрация: 1-11-05
Пользователь №: 10 359

|
Да - фиг с ней с коррекцией младшего бита.
Во, быть одна очень важная деталь, о которой забыли: если мы пишем в видеобуфер с камеры и одновременно выводим на монитор из этого же буфера, то получаем при динамической картинке помеху в виде горизонтальной полосы (ползущей по вертикали). Это вполне логично, ведь когда мы читаем из буфера для вывода на монитор, то в один прекрасный момент мы доходим до строки, где в данный момент идет запись с камеры. Т.е. в верхней части монитора выводится новый кадр, а внизу - еще предыдущей. Именно поэтому этой помехи не видно на статической картинке. Похожий эффект возникает и при использовании черезсстрочной развертки...
Методы борьбы: - синхронизировать вывод и ввод картинки. Подходит только если частоты ввода/вывода кратны. - использовать две страницы памяти. В одну пишем новый кадр, из другой пока выводим, после меняем местами... Этот способ проверил - порядок...
--------------------
Быть. torizin-liteha@yandex.ru
|
|
|
|
|
Feb 22 2008, 14:55
|
Знающий
   
Группа: Свой
Сообщений: 921
Регистрация: 6-04-07
Из: Israel
Пользователь №: 26 822

|
Цитата(torik @ Feb 22 2008, 15:53)  Да - фиг с ней с коррекцией младшего бита.
Во, быть одна очень важная деталь, о которой забыли: если мы пишем в видеобуфер с камеры и одновременно выводим на монитор из этого же буфера, то получаем при динамической картинке помеху в виде горизонтальной полосы (ползущей по вертикали). Это вполне логично, ведь когда мы читаем из буфера для вывода на монитор, то в один прекрасный момент мы доходим до строки, где в данный момент идет запись с камеры. Т.е. в верхней части монитора выводится новый кадр, а внизу - еще предыдущей. Именно поэтому этой помехи не видно на статической картинке. Похожий эффект возникает и при использовании черезсстрочной развертки...
Методы борьбы: - синхронизировать вывод и ввод картинки. Подходит только если частоты ввода/вывода кратны. - использовать две страницы памяти. В одну пишем новый кадр, из другой пока выводим, после меняем местами... Этот способ проверил - порядок... Ну это-то логично но только если rates записи и чтения в/из буфера не равны. Иначе, если они равны и есть задержка чтения относительно записи, то чтение всегда по идее должно запаздывать ан постоянное тау, и тогда не должно быть помехи. Есть задержки записи и чтения в/из буфера за счет того что физическиая длинна строки (в клоках) больше чем длинна видео данных, посему даже если скорость чтения у меня будет чуть ниже скорости записи, все равно поинтеры записи/чтения не должны пересекаться. Все это пока рассчетные теории, буду проверять на практике в симуляции...
|
|
|
|
|
Feb 22 2008, 15:22
|

Частый гость
 
Группа: Свой
Сообщений: 99
Регистрация: 27-10-07
Из: СПб
Пользователь №: 31 797

|
Цитата(Саша Z @ Feb 22 2008, 17:55)  Ну это-то логично но только если rates записи и чтения в/из буфера не равны. Иначе, если они равны и есть задержка чтения относительно записи, то чтение всегда по идее должно запаздывать ан постоянное тау, и тогда не должно быть помехи. Все правильно. При равных кадровых и строчных частотах, т.е. если развертка одинаковая, никаких помех не будет, главное, чтобы чтение не опередило запись. Тем более, что есть кадровое гашение, когда запись кадра закончено, и можно спокойно дочитывать буфер, не опасаясь, что запись нового кадра его испортит. Мы же эту тему обсуждали в другой теме...
|
|
|
|
|
Feb 22 2008, 18:28
|
Знающий
   
Группа: Свой
Сообщений: 921
Регистрация: 6-04-07
Из: Israel
Пользователь №: 26 822

|
Цитата(Liseev @ Feb 22 2008, 19:22)  Все правильно. При равных кадровых и строчных частотах, т.е. если развертка одинаковая, никаких помех не будет, главное, чтобы чтение не опередило запись. Тем более, что есть кадровое гашение, когда запись кадра закончено, и можно спокойно дочитывать буфер, не опасаясь, что запись нового кадра его испортит.
Мы же эту тему обсуждали в другой теме... Да, так и есть, обсуждали с вами.  В данной ветке оно как-то палвно переросло в схожее русло...
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|