Цветное OSD
сначала имеются три различных сигнала, каждый из которых- соответствует своему (-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) передачи цветного изображения обречены тянуть совместимость с чернобелым оборудованием. Кардинально различаются лишь частотами развертки, их Ч/Б прорадителей. Потому и раличаются до сих пор.
Композитный сигнал, действительно устроен так, что наложить Ч/Б буковки, реально просто подтягивая уровень к черному/белому. Инфа о цвете идет рядом, как раз в тех цветоразносных, а вовсе не цифропачками в начале строки.
Инфа о цвете идет рядом, как раз в тех цветоразносных, а вовсе не цифропачками в начале строки.
Однозначно! Причём, в ПАЛе -эту инфу видно обычным осциллографом, она сидит на площадке синхроимпульса в виде такой бородавки.
Называется PAL-burst, что в переводе означает “паловская вспышка” 😃
Декодер PAL (в те суровые времена, когда я этим делом кормился- была микросхема TDA4510 www.alldatasheet.com/view.jsp?Searchword=TDA4510) и занимается именно тем, что выделяет эту самую вспышку, извлекает из неё информацию о цвете и- прилаживает оную в цветоразностные сигналы.
По идее, вот тут то и надо в эти самые сигналы- засадить буквовки ОСД, потом, при помощи кодера- из них опять сделать ПЦТС и -пульнуть его на передатчик.
Конечно, может сейчас эти микросхемы (ПАЛ декодер и ПАЛ кодер) есть маленькие и слабопотребляющие?
Не знаю…
А это просто жуткий геморрой.
И Ето- прАвильно 😃
Пока не использовать специализированные
Даже решив принципиально проблему- Вы тут же упрётесь в другую: огромное (с точки зрения бортового оборудования авиамодели) энергопотребление.
Причём, снизить его не удастся- просто в силу необходимости обработки ВЧ телесигнала 😦
Декодер PAL (в те суровые времена, когда я этим делом кормился- была микросхема TDA4510 www.alldatasheet.com/view.jsp?Searchword=TDA4510) и занимается именно тем, что выделяет эту самую вспышку, извлекает из неё информацию о цвете и- прилаживает оную в цветоразностные сигналы.
Немного неверно. TDA4510 прилаживает оную вспышку к сигналу своего кварцевого генератора и синхронизирует его по частоте и фазе. А потом, в интервале строки, прилаживает сигнал этого генератора к цветовой поднесущей, наложенной на черно-белый сигнал. … и выдает на выходах (двух амплитудно-фазовых детекторов) два нормальных цветоразностных сигнала. Потом из них и яркостного сигнала простым матрицированием получают R-G-B сигналы.
Раскрасить титры в PAL не так уж сложно. Декодировать видеосигнал для этого совсем необязательно. Достаточно лишь засинхронизировать кварцевый генератор от вспышки, сформировать из него набор сигналов, сдвинутых по фазе (набор цветов) и замешать обратно в видеосигнал в нужных местах.
замешать обратно в видеосигнал в нужных местах Декодировать видеосигнал для этого совсем необязательно
А вот это то- как сделать без его декодирования?
И- последующего кодирования?
У меня друг производит студийные транскодеры, в том числе- у него и титры любого цвета можно вводить в итоговый сигнал…
Так первое, что он там делает- “разбирает” исходный сигнал на составляющие 😃
Ну и ящик у него- весьма приличных размеров и жрёт- мама не горюй 😦
Достаточно лишь засинхронизировать кварцевый генератор от вспышки, сформировать из него набор сигналов, сдвинутых по фазе (набор цветов) и замешать обратно в видеосигнал в нужных местах.
Если мы “замешиваем”, значит, складываем. Если складываем- значит поползет уровень белого… Надеюсь, не сильно.
Хотя, есть спецмикросхемы OSD ( Max какой-то там, точно не помню), которые делает Белые, синие и красные буковки. Применялись в дорогих видиках, сейчас уже, вероятно, не выпускаются…
У меня друг производит студийные транскодеры, в том числе- у него и титры любого цвета можно вводить в итоговый сигнал… Так первое, что он там делает- “разбирает” исходный сигнал на составляющие
В результате получается так, но титры вводятся не в итоговый сигнал, а в еще “разобранный”. “Разборка” там необходима для транскодирования, а если она уже есть, то титры ввести очень несложно, а потом все “собрать”.
Чисто теоретически, два полностью (в т.ч. по цветовой поднесущей) синхронных сигнала PAL можно накладывать друг на друга простым микшированием без декодирования. Проблема лишь в том, чтобы создать синхронный с видеосигналом от камеры цветной сигнал титров.
Если мы “замешиваем”, значит, складываем. Если складываем- значит поползет уровень белого… Надеюсь, не сильно.
Уровень белого пока не трогаем, хотя он совершенно некритичен. Замешиваем цвет мы не в сигнал яркости, а в цветовую поднесущую методом замеЩения.
Дык как туда замешаешь , не отфильтровав ее предварительно из исходного сигнала? отфильтровывать цвет для отдельных частей строки? Сигнал же цельный, его мы не разбиваем предварительно. Я предполагал что вы хотите складывать цветовую поднесущую с исходным (комплексным) сигналом в тех пикселях (временных отрезках строк), которые надо перекрасить.
Хотя, нам их не перекрашивать надо, а сначала делать яркими, потом- перекрашивать. Или одновременно.