Цветное OSD
Вопрос возник тут спонтанно - а нужно ли вообще цветное OSD при плюс-минус D1 разрешении (100% применяемых камер вкупе с видеоканалом)?
Пока преимущество вижу в возможности выделения символов инверсией основного цвета (или прямой, или по определенным правилам), что автоматом дает лучшую читабельность при разных уровнях освещенности, да еще возможность выделять “яркими” цветами разные алармы.
а нужно ли вообще цветное OSD
Оно то, может и нужно- выделить красным цветом какой то аварийный параметр.
Но вот возможно-вряд ли, поскольку для создания цветной буквовки- надо влезть в видеосигнал до его матрицирования (т.е. в камере-сначала имеются три различных сигнала, каждый из которых- соответствует своему (-R-G-😎 цвету.
Затем- из этих цветов, при определённом уровне каждого, создаётся комплексный сигнал…
Вряд ли в применяемых нами камерах- есть доступ к RGB, они заканчиваются в процессоре.
Например в телевизорах- титры подаются прямо на плату кинескопа, туда же, куда поданы RGB сигналы изображения.
Т.е., теоретически- цветные титры хорошо бы сделать.
Практически- нереалезуемо 😦
сначала имеются три различных сигнала, каждый из которых- соответствует своему (-R-G-😎 цвету
Судя по популярным сенсорам от omnivision, там таки YUV 4:2:2 в основном идет, но что в реальных камерах - хз…
Впрочем, пока это все равно чистая теория, пока не дождусь железок всяких и своими ручками не попробую…
Пока просто интересно мнение реально пользующихся OSD
О как интересно!😃
Расскажите, пожалуйста, а как тогда с ч-б буковками телеметрия справляется? Какие там хитрости?😃
Черно-белое то делается относительно легко - достаточно в нужные моменты линию видеосигнала притягивать или к земле, или к плюсу. Соответсвенно серое - это нечто среднее между ними. С цветом так просто не получится делать.
Черно-белое то делается относительно легко - достаточно в нужные моменты линию видеосигнала притягивать или к земле, или к плюсу. Соответсвенно серое - это нечто среднее между ними. С цветом так просто не получится делать.
В секаме получилось бы? Или я плохо учился?
“Дяденька, я не настоящий сварщик”…
В PAL именно так, да и в NTSC, что разнообразие самодельных osd подтверждает…
В секаме получилось бы? Или я плохо учился?
В Секаме- “получилось бы”- что именно?
Чёрно белые титры-да, поскольку способ их подмешивания- вообще системы кодировки цвета не касается.
Цветные- нет, по той же причине, что и в ПАЛ и в НТСЦ: нет в свободном виде цветоразностных сигналов.
Очень теоретически, можно было бы сигнал, идущий с камеры- дематрицировать, получив три сигнала цветности (или- два цветоразностных, что одно и то же)+ яркость (кстати, именно так пИсали видеомагнитофоны VHC)
Но сложность такой процедуры ( а также- её аппаратной реализации) и потеря качества- не окупают наличия разноцветных буквовок 😦
Проще гнать телеметрию на землю (как в Икарусе) а уж там, на компе- рисуй что хошь.
Но тут опять подводные камни: при искажении, а даже не потере, видео или аудио сигнала с борта (смотря, каким способом мы гоним ТМ)- телеметрия тоже отрубится 😦
О как интересно!
Вы, дяденька, со мной об этих вещах не полемизируйте: я декодеров ПАЛ овских во времена Оны понапаял и понавтыкал в советские телеки- туеву хучу.
Штук 500, как минимум 😃
Волей- неволей пришлось разбираться как и что там работает 😃
ненужно
я вообще больше склоняюсь (при своем убогом опыте использования простейших ОСД) вообше уход от цифробукв
банально прогрессбар намного информативнее и позволяет произвести более быструю оценку
(например поэтому отдаю предпочтение стрелочным часам перед символьными)
Цвет - это важно. С помощью цвета можно значительно снизить нагрузку при восприятии информации.
Не понимаю почему разработчики популярных OSD телеметрию не делают цветной. Нашёл на ютубе:
Не понимаю почему разработчики популярных OSD телеметрию не делают цветной.
Потому что соотношение цена/польза очень высокое. Цвет сразу увеличит цену OSD на 100$, а необходимость цвета в реальных полетах всеьма сомнительна. Обычно цвет хотят заядлые игроманы, привыкшие к рющечкам и цветочкам. Тем, кому важнее полет - цветные циферки скорее лишняя рябь и усталость для глаз. 😃
Подождите годика три, когда изобилие и конкуренция FPV систем приведет их к цветовой избыточности, как это случилось с мобильниками 5 лен назад. 😃
Нашёл на ютубе:
Картинка сформирована на земле и отображается на экране ноута.
На ноуте… Понятно.
Однако грамотно созданный интерфейс свободен от ряби, удобен и является помощником. Так же однозначно ясно, что смена цвета элементов индикации в любом случае улучшает восприятие. Для примера возьём внизу экрана элементы типа прогрессбара зелёного цвета. Ведь если по достижении низкого значения индикатор перекрашивается в красный то это однозначно лучше заметно, чем если элементы просто белые. Да, элемент белого цвета может мигать. Тем не менее правильное использование цвета улучшит качество результата.
Поэтому о усталости глаз, ряби и других стереотипах, вызванных неумелым использованием “разноцветных карандашей”, можно не упоминать. Тем более если цифры не нужны их по кнопке можно всегда выключить.
А вот то что технически сейчас это дорого - теперь понятно. Остаётся немного подождать. =)
Чёрно белые титры-да, поскольку способ их подмешивания- вообще системы кодировки цвета не касается. Цветные- нет, по той же причине, что и в ПАЛ и в НТСЦ: нет в свободном виде цветоразностных сигналов.
Ну в секаме они по крайней мере не перемешиваются. Я правильно помню, что секам льет цвет-Y через строку в ЧМ, в отличие от палов, которые гонят R-Y и B-Y одновременно, с ортогональным кодированием в АМ? Пошел читать википедию.
в камере-сначала имеются три различных сигнала, каждый из которых- соответствует своему (-R-G-😎 цвету.
Затем- из этих цветов, при определённом уровне каждого, создаётся комплексный сигнал…
Если я правильно понял, то задумка состоит в “редактировании” RAW (Bayer) изображения с сенсора до его перевода в PAL/NTSC?
Реализация - скорее что то из области фантастики…
Если же речь идет о наложении цветного OSD на сигнал PAL/NTSC, то это более реально. Правда контроллер потребуется гораздо более скоростной чем тот, что применяется для черно-белого OSD. Причина здесь в том (на примере PAL), что информация о цвете в каждой строке изображения передается в крошечный интервал времени (между синхроимпульсом -0.3В и до начала передачи информации о яркости):
Более подробно - здесь
Причина здесь в том (на примере PAL), что информация о цвете в каждой строке изображения передается в крошечный интервал времени (между синхроимпульсом -0.3В и до начала передачи информации о яркости):
Нет, конечно. В этом интервале передается только лишь информация, позволяющая ТВ приемнику правильно зацепиться за фазу поднесущей цвета. Проблема наложения цвета - собственно, проблема правильного управления амплитудой и фазой сигнала на цветовой поднесущей. А это просто жуткий геморрой.
Господа, вы все верно отметили, проблемы вывода цвета - серьезные. Пока не использовать специализированные решения. Я тут просто в своем необъемном хламе роюсь, нашел мега плату с видео кодером (цифра->композит) ADV7175A с кучей обвязки в виде ПЛИСин, SDRAM etc.
Из этого всего умею работать только с самим кодером, так что заказал шустрый проц (а то дома мощнее 128 атмеги ничего и нету).
Судя по расчетам, ресурсов проца с лихвой должно хватить на захват видео с внешнего оцифровщика (привет, easycap!), перенос данных во внешнюю SRAM, а потом и обратно на видеокодер.
Просто пока железяки еще идут, думаю о структуре софта - делать для себя тяп ляп лишь бы работало, или по правильному, с настройками…
Народ. Или палосекамы кординально переписали за последние 10 лет, или йа совсем спилсо:-(
Оба стандарта (PAL|NTSC) передачи цветного изображения обречены тянуть совместимость с чернобелым оборудованием. Кардинально различаются лишь частотами развертки, их Ч/Б прорадителей. Потому и раличаются до сих пор.
Композитный сигнал, действительно устроен так, что наложить Ч/Б буковки, реально просто подтягивая уровень к черному/белому. Инфа о цвете идет рядом, как раз в тех цветоразносных, а вовсе не цифропачками в начале строки.