Ошибаешься. Я уже писал, что спокойно получил этот же файл, только в формате DivX без искажений! Просто с декодера DV я брал не RGB сигнал, а YUV и всё пучком. Другое дело, что для работы в программах редактирования нужно будет будет переходить к RGB, вот тут и возникают проблемы.poeksperimentiroval i obnaruzhil chto samij bol'shoj vred materialu nanosit ljuboj dekoder DV materiala - u nih u vseh nepravil'nij proschet stoit pohozhe. poskol'ku pri kodirovanii v DV material prakticheski ne otlichajetsja ot togo chto vidim na monitore.
eugen: tebe skazat' mogu odno - avisinth delajet chto to tol'ko posle DVSD dekodera a ne pered nim
Корректная работа с DV (BT601, YUV и RGB)
#51
Отправлено 22 Jan 2004 - 16:57
#52
Отправлено 22 Jan 2004 - 18:21
просто Y=235 (и уж тем более 255) имеет белый и только белый цвет. Поэтому если вдруг случится так, что Y=235, а Cb или Cr не равны 0 то цвета RGB, вылезающие за 255 вам обеспечены. На ТВ где аналог это нормально, а вот в компе... Потому и превращается оранжевый черт знает во что...
В общем научиться надо корректно из YCbCr делать RGB и наоборот. Делать не сложно (в теории) - просто диапазоны подогнать соответствующим образом и устроийства отображения откалибровать. Практическим решением займусь обязательно, но не сейчас (диплом поперек горла стоит).
#53
Отправлено 23 Jan 2004 - 01:19
#54
Отправлено 23 Jan 2004 - 13:52
Я думаю, что решенй у нее может быть несколько, как минимум два -
1. Найти способ корректного возврата в YUV (YCbCr) после всех работ с материалом в RGB (ведь возвращает же почти корректно Canopus DV Coder с включенной опцией Expand RGB Range to 150% материал из RGB в YUV, правда есть серьезные проблеммы в случаи если декодированием сигнала в RGB занимались директ шоу фильтра майкрософта).
2. Найти вообще корректный способ трансформации в обе стороны - YCbCr->RGB->YCbCr , при этом решить проблему внутри кодека или фильтра какого-нибудь, не выводя ее за пределы преобразований, не дать возможность испортить материал левыми декодерами, в том числе и главным образом майкрасофта.
Почему этим никто серьезно до сих пор не занимается? -
так все все время ведь на работе .
Профи, которых я носом тыкал в эту проблему просто отмахиваются, мол не до тебя - видишь завтра эфир, а нам тут насовали разношерстного материала и DV и аналог и графику и сказали до утра все свести вместе.
А я удивляюсь глядя на то, как монтажеры крутят цветокрректор пытаясь весь этот материал свести к одному знаменателю на ГЛАЗ???????????????????????!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Братцы, у меня совсем другое образование, я в данной ситуации могу только поставить проблему и пытаться локализовать ее место, а вот решить, и тем более фильтр написать - это уж ВЫ, те кто хоть как-то этому учился!
У меня есть еще один вопрос!
Раз RGB может быть 0-255, а YUV только 16-235, а мы видим, что очень легко записать YUV с диапазоном шире 16-235, то может все-таки не искать решение в корректном сужении диапазона в YUV до 16-235?
Может все-же есть способ заставить всех правильно работать с YUV 0-255?
Всетаки, если правильно по Level зажимать диапазон YUV до 16-235 часть информации на изображении теряется, а потом я писал, что изображение с более широким диапазоном значительно выигрывает, особенно на большом экране с проектора!!!!
Конечно все решилось бы само, если-бы все работали только с YUV, но на это мы точно влиять не можеи .
Сообщение отредактировано Aleksandr_Oleynik: 23 Jan 2004 - 14:01
#55
Отправлено 23 Jan 2004 - 14:18
po idee peresvet poluchajetsja.
poproboval v vegase sdelat' analiz materialov no ne s pomoshju vektroskopa - a vnutrennim plugom "Broadcast colors" vistaviv v nem invertirovat' to chto za predelami diapazona - rezul'tat horosho vidno gde material budet iskazhen
#56
Отправлено 23 Jan 2004 - 16:07
Но как можно снять такой материал без пересвета? Да и не только такой, а любой темный объект на светлом фоне.
Речь идет о бытовой съемке в которой невозможно снять без пересвета в 50 из 100 сцен.
Я очень внимательно слежу за зеброй, врядли кто-то это будет делать так как я, но у меня половина сцен, ну треть, имеют пересвет и на каждой касете есть одна-две сцены в которых пересвет влияет на цвета, а не только на белый !
#57
Отправлено 23 Jan 2004 - 17:12
можно конечно подумать об создании патча к существующему кодеку... (если кто имеет время и силен в патч-мейкерстве - может возьмется ?)
#58
Отправлено 23 Jan 2004 - 18:31
Проблема YCrCb не только и не столько в диапазонах. Просто надо понять, что не всем возможным комбинациям Y, Cr и Cb соответствуют некотороые цвета в RGB 0-255Может все-же есть способ заставить всех правильно работать с YUV 0-255?
Например, если Y=235, U=220, V=16, то вы получите такой КРАНСНЫЙ, который ваш ваш монитора не отобразит, ибо R явно вылезет за 255, причем сильно. Его зарежут. Картинка приобретет неправильный оттенок.
Я вот скорее думаю о проге, позволяющей править уровни DV без рекомпрессии (ну статистическое сжатие без потерь не в счет, я имею в виду DCT). Задача интересная и востребованная. А заодно о проге, переводящей DV в различне форматы (AVI, QT, Avid) тоже без рекомпрессииможно конечно подумать об создании патча к существующему кодеку
Сообщение отредактировано Vlas: 23 Jan 2004 - 18:41
#59
Отправлено 23 Jan 2004 - 19:46
большии диапазон ITU601R (YCbCr) чем нормальный RGB 0..255.
Кто-нибудь пробовал этим воспользоваться?
#60
Отправлено 23 Jan 2004 - 20:35
testovij material kadr Oleynika Sun_...
na monitore prisutstvujet zheltij cvet pri ljubih nastrojkah kodeka.
sdelal softinku dlja analiza i poiska koeficientov YUV->RGB
http://daliv.bokova.lv/video/yuv/
skachat' .exe i .stream [v nem YUV potok kadra virvannij cherez avisinth sckript:
AVISource("C:\tmp\16_235_Sun.avi")
ConvertToYV12()
ImageWriter("c:\tmp\", 0, 0,"ebmp")
s ubrannim bmp zagolovkom]
igrat'sja s softinkoj sovetuju pogljadivaja na original kadra (smotret' vishe v etom zhe topike) na televizore - inache tolku netu
tak zhe zakinul ishodnij material i kadr v jpg poluchennij konvertacijej vnutri kameri - gorazdo blizhe chem cherez dv kodek v kompe, no tozhe ne sovsem to...
#61
Отправлено 23 Jan 2004 - 21:28
Тепер ответ на твой вопрос
В цифорвой форме, мы можем записать уровни этих сигналов в диапазоне 0-255. Но если мы посмотрим на стандарт... то окажется, что камера не правильно отрабатывает пересвет, вот и всё. Наша задача, избавиться от этого брака. Ведь проблемы то именно из-за выхода камеры за диапазон 16-235.Раз RGB может быть 0-255, а YUV только 16-235, а мы видим, что очень легко записать YUV с диапазоном шире 16-235, то может все-таки не искать решение в корректном сужении диапазона в YUV до 16-235?
Может все-же есть способ заставить всех правильно работать с YUV 0-255?
Vlas
хоть кто-то понимает суть проблемы... Я рад.Проблема YCrCb не только и не столько в диапазонах. Просто надо понять, что не всем возможным комбинациям Y, Cr и Cb соответствуют некотороые цвета в RGB 0-255
Например, если Y=235, U=220, V=16, то вы получите такой КРАНСНЫЙ, который ваш ваш монитора не отобразит, ибо R явно вылезет за 255, причем сильно. Его зарежут. Картинка приобретет неправильный оттенок.
Это как? Да ещё без рекомпрессии? Совсем не понял. Для нормальной работы (без искажений) нужно будет перевести в RGB и делов то... а дальше лепи любой кодек. Самый оптимальный способ написать конвертор для Avisynth. Поясню почему. При открытии в Avisynth, формат цветности не изменяется, пока этого не потребуется программе. Если написать такой конвертор (YUV-RGB-YUV), с настраевыми множителями при параметрах (если кто-то захочет сам подбирать) то все проблемы были бы решены. Если кто-то захочет, то могу свести с теми, кто поможет разобраться с Avisynth и написанием плагов для них. А писать свою прогу... по-моему не рационально.А заодно о проге, переводящей DV в различне форматы (AVI, QT, Avid) тоже без рекомпрессии
#62
Отправлено 23 Jan 2004 - 23:23
#63
Отправлено 24 Jan 2004 - 02:48
Я попробовал отскалировать это так, чтобы красныей стал 255 и посмотреть на экране как ето выглядит...
В этом случае на месте солнца получается "серая дыра", выглядящая более чем неестественно.
Понятно, что это происходит потому, что информация о яркости в центре просто отсутствует (т.е. Y=255 надо интерпретировать как: не знаю что там и какого цвета, но очень много)
К чему все это?
А к тому, что в случае выхода какоей-либо компоненты RGB за пределы "максимально-белого" (Y=255, Cb=128, Cr=128 (нормальныей белый соответствует {235,128,128})) получаем неопределенные значения цвета... и то, как ето будет выглядеть на экране зависит исключительно от везения... т.е. на одном устроействе ето может выглядеть чуть краснее, на другом будет желтым, на третьем - оранжевым...
Цветовоей профиль перехода "красный край" - "белая середина" (через Желтый (оранжевый) или через зеленый) определяется тем, как насышались отдельные цвета в фоточувствительной матрице той камеры которой производилась съемка...
Если пытаться делать ограничение в YCbCr (т.е. ограничивать Cb и Cr так, чтобы результат не выходил за разрешенные пределы в RGB (y=1.0 -> rgb=1.0) то тогда (зрительно) оранжево-желтая область становится практически белой... можно ли это считать желаемым результатом я не знаю.
#64
Отправлено 24 Jan 2004 - 03:07
Хотя я все же в меру своих, хотел бы спросить -
А нельзя не смотря на то, что этот кадр весь неправильный и вне стандарта, все-же после работы с ним в RGB вернуть его корректно в YUV, ну вот хотябы так как это делает Canopus DV Coder с включенной опцией Expand RGB Range to 150%. При этой опции кодек вообще не портит материал нормально снятый, а вот такое солнышко после его включения в какую нибыдь композицию в AE, который только с RGB работае, возвращает к жизни восстанавливая оранжевый цвет.
Сообщение отредактировано Aleksandr_Oleynik: 24 Jan 2004 - 03:13
#65
Отправлено 24 Jan 2004 - 03:42
Предполагается что все RGB имеют значения 0..255, при етом RGB=16 соответствует Y=16, а RGB=235 соответствует Y=235. Кстати в студийном цифровом RGB оборудовании тоже используется RGB16..235.
Теоретически можно сделать и RGB32..196, но при етом возникнут ошибки округления YCbCr->RGB32..196->YCbCr, поскольку черно-белые значения в таком "широком RGB" лежат "реже" чем в YCbCr (Y16..235, CbCr16..240). Таким образом платой за расширение диапазона RGB будет неточное представление серой шкалы.
Сообщение отредактировано Gri-gri: 24 Jan 2004 - 03:43
#66
Отправлено 24 Jan 2004 - 04:49
#67
Отправлено 24 Jan 2004 - 05:56
1. элементы форточувствительной матрицы принимают свет
1.а. регулировка (аналоговая) чувствительности фотоэлементов.
2. аналогово-цифровое преобразование
3. преобразование RGB -> YCbCr
3.а. выработка сигналов регулирования чувствительности отдельных каналов цвета, баланс белого
4. понижение частоты выборки цвета, нелинейное преобразование уровней
5. компрессия и запись на носитель
при очень неравномерно освещенноей сцене в 1-4 возникают проблемы с ограничением видеосигналов (в аналоговои части) и с ограничением диапазона квантизации в цифровоей (нелинейности в этом случае не столь критичны). Для сигналов 16..235 камеры калибруются примерно одинаково... а все что выходит за пределы сильно зависит от конкретноей камеры.
Поэтому и мучаются видеоинженеры пытаясь сохранить детали в областях 1..15 и 235..255 и в то-же время не сильно ухудшить передачу 16..235.
В конечном итоге на экране телевизора/монитора светятся RGB-цвета которые должны представлять цвета, принятые камерой в п.1.
Сообщение отредактировано Gri-gri: 24 Jan 2004 - 06:48
#68
Отправлено 24 Jan 2004 - 12:45
значит я прав, и эти все проблемы не относятся только лишь к DV камерам?
Так почему до сих пор не найдены автоматические средства нормализации сигналов при оцифровке с камеры, с минимальными потерями цветов и детализации?
И думается мне, что производство материала для вещания и производство для прямого просмотра можно было бы и разделить, так как в угоду TV вещанию заужать диапазон - ГЛУПО.
Кстати 150% на взгляд даже много, так как Canopus DV Coder с включенной опцией Expand RGB Range to 150% возвращает на место оранжевый слегка его расширяя, но еле-еле.
Хотел бы высказать еще некоторые соображения.
1. Я посмотрел это солнышко на хорошем HD проекторе SIM2 HT300 – нет никаких проблем с отображением оранжевого, и на желтый в оригинальном материале и намека нет. На плазме пока не удалось глянуть.
2. Если этот ненормативный цвет присутствует в YUV изображении только потому, что оно в целом вышло за диапазон 16-235, то чем объяснить тот факт, что я сжимаю диапазон оригинала до 16-235, но только фильтром работающим без преобразования в RGB, а проблема остается. Т.е. как только такое уже полностью отвечающее стандарту BT601 YUV изображение с диапазоном 16-235 я преобразовываю в RGB – все, оранжевого нет, есть только грязно желтый.
3. Попробовал оцифровать материал по аналоговому входу Тарги3000, что в MPEG2 I, что в некомпрес – материал идентичен DV. А хотелось бы найти хотя бы способ оцифровки такой, чтобы потом не выискивать по всему материалу такие вот ненормативные куски.
Может хоть это можно как то решить? Черт с ним с тем с оранжевым, пусть будет желтым, но только сразу и сразу в 16-235. Как это то сделать?
Ой как неохота весь материал через RGB преобразование таскать.
#69
Отправлено 24 Jan 2004 - 14:25
Можешь выложить этот кадрик? Очччень интересно...2. Если этот ненормативный цвет присутствует в YUV изображении только потому, что оно в целом вышло за диапазон 16-235, то чем объяснить тот факт, что я сжимаю диапазон оригинала до 16-235, но только фильтром работающим без преобразования в RGB, а проблема остается. Т.е. как только такое уже полностью отвечающее стандарту BT601 YUV изображение с диапазоном 16-235 я преобразовываю в RGB – все, оранжевого нет, есть только грязно желтый.
Всё абсолютно верно. Mpeg2 производит захват в том-же YUV. Ты попробуй этот материал дальше преобразовать в RGB, вот тут опять вылезут проблемы.3. Попробовал оцифровать материал по аналоговому входу Тарги3000, что в MPEG2 I, что в некомпрес – материал идентичен DV. А хотелось бы найти хотя бы способ оцифровки такой, чтобы потом не выискивать по всему материалу такие вот ненормативные куски.
#70
Отправлено 24 Jan 2004 - 17:52
Кажется чуть научился понимать вектроскоп - приведу диаграмки.
Первая, это RGB сделанный из оригинального YUV (последняя, средняя, это YUV откорректированный кадр с сохраненным оранжевым и более менее всеми остальными цветами, правда яркость потушена основательно - но зато в RGB и обратно без сучка и задоринки.
Вообще я так посмотрел, что в данном случае диаграмма Lightning и ее пунктирная область - гловенствующая. Если за нее выходишь - кранты, цвет при RGB преобразовании меняется.
#71
Отправлено 25 Jan 2004 - 00:04
1) все устройства хранения выбраны YUV[0-254]
2) все устройства вывода RGB [0,254]
Все устройства отображения не управляют ЧЕРНЫМ цветом.
Диапазон YUV[0-254] больше RGB [0,254] -- что дает возможность
манипуляций составляющими при монтаже и коррекции.
А теперь ближе к баранам:
Пока аксиомы:
1)Диапазоны всех трех параметров DV на ленте YUV[0-254]
2)Зависимости оттенков линейные
3)Канопус говорит что максимум DV это в 150% от RGB [0-254]
Задаем соотношения YUV в RGB формулы сами знаете где.
Ищем максимальные значения теоретических RGB для YUV[0-254]
R 478 (254,x,254)
G 431 (254,0,0)
B 531 (254,254,x)
Кстати сумма RGB 254*3=762 и этих RGB (YUV[254,254,254]) 1134.756 соотносятся как 148,9% Ничего не напоминает?
Теоретически нужно было бы еще провести пересчет по минимумам -- НО но устройства отображения НЕ ДАЮТ МЕХАНИЗМА УПРАВЛЕНИЯ ЧЕРНЫМ т.е. нижняя половина скорее всего просто обрезается 0.
Теперь кто-нибудь может провести линейный пересчет исходя из найденых максимумов приводя их к 254??? и представить картинки для сравнения?
Простейший это механически привести все параметры исходя из максимума.
Точнее это найти максимальные значения в куске и расчитать коэффициент для куска.
Я не знаю АВсинта и других популярных программ так что сам под них делать не буду, сорри.
При наличии механизма ввода своих законов преобразования для каждого
из цветов можно подобрать необходимую цветовую корректность глядя на
исходные и получаемые картинки. Не думаю что она будет очень сложной.
Максимум легкая поправка типа схожая с гаммой.
В теории идеальный плугинс/программа корректор должен работать так:
1) определение цельного куска по дата/время (единстово времени дефекта)
2) определение выхода составляющих за диапазон в куске
3) перевод в "RGB 150%"
4) масштабирование в "100%"
5) передача редактору /или / возврат в YUV[0-254]
Я бы делал это на этапе сгона материала в комп, а дальше бы уже работал с обработаным материалом.
=====================================
Теперь еще о теории и практике железа -- теоретически все входные устройства RGB [0,254].
Но это лишь в теории или на 3 матричных камерах.
На практике в Ваших камерах стоят матрицы на которых в "псевдо-шахматном порядке" (забыл фамилию ученого который это предложил) расположены элементы чувствительные к одному из RGB цветов.
В ПРОФИ ЦИФРОВЫХ ФОТОАППАРАТАХ ВЫ МОЖЕТЕ ПОЛУЧИТЬ RAW данные с КАЖДОГО ЦВЕТА В ОТДЕЛЬНОСТИ которые будут содержать слои из ЧЕРНЫХ и ОДНОЦВЕТНЫХ точек. Причем ЦВЕТНЫЕ ТОЧКИ НЕ БУДУТ СОВПАДАТЬ ДРУГ С ДРУГОМ НА 3 СЛОЯХ! И количество точек разных цветов так же не будут одинаковыми -- если я правильно помню больше всего красных потом голубые и меньше всего зеленых... (но могу и ошибаться для сути это не важно, тк. повлиять мы на это не можем).
Так вот для выдачи с матрицы RGB [0,254] каждый из производителей как матриц так и !камер! может использовать самый разный алгоритм смешивания и расчета промежуточных цветов точек в зоне нечувствительности к данному цвету. Само собой чем выше разрядность внутненнего пересчета тем "точнее" передаются промежуточные оттенки и следовательно более красиво/естественно выглядит полученая выходная RGB [0,254] картинка.
А вот тут и возникает вопрос, а почему собственно обязательно в RGB [0,254] когда у нас на ленте более широкий диапазон заданый форматом YUV[0-254]???
Я думаю теперь всем понятно почему бытовые камеры (а возможно и профи тоже) ВСЕГДА БУДУТ ПОЗВОЛЯТЬ ПЕРЕСВЕТ ВНЕ ЗАВИСИМОСТИ ОТ СТАНДАРТА?
Цепочки процесса (в круглых скобках ваша камера):
1)
(Матрица шахматка > RGB [0,254] > обрезаный YUV[0-254]) > DV> полный YUV[0-254] > RGB [0,254] > редактор > Выход RGB [0,254]
НЕТ ПРОБЛЕМ С ПЕРЕСВЕТОМ.
2)
(Матрица шахматка > полный YUV[0-254]) > DV> полный YUV[0-254] > RGB [0,254] > редактор > Выход RGB [0,254]
ВОЗМОЖНЫ ПРОБЛЕМЫ С ПЕРЕСВЕТОМ
А если не ваша, а профи камера просто по нужде компактная?
3)
(Матрица шахматка > полный YUV[0-254]) > BetaCam (или круче?)> монтажно микшерное оборудование в стандарте YUV > мастер пульт с аппаратно-ручным преобразованием-лимитированием RGB [0,254] для вещания или фотовывод на кинопленку полного диапазона.
НЕТ ПРОБЛЕМ С ПЕРЕСВЕТОМ Т.К. ВЕСЬ МОНТАЖ ВЕДЕТСЯ ТОЛЬКО В ПОЛНОМ ДИАПАЗОНЕ и лишь на финальной стадии приводится к вещательному "зажиму".
Кстати конторольные мониторы на всех этапах в теле бизнесе подлключаются
по YCrC, а не по RGB не так ли?
Так как сначала разрабатываются оборудование для ПРОФИ, а потом для БЫТА -- то я склонен к тому, что первой цепочки никогда не было и уже не будет -- хотя в трехматричных камерах -- возможно это и так и проще, без проблем с пересветом.
Удачи! G71.
#72
Отправлено 25 Jan 2004 - 00:11
Спасибо за пример с вектороскопом. Очень похоже на правду
Кстати изложенное очень четко объясняет почему на синтетических картинках нет никакой возможности получить пересвет.
Теоретически пересвет можно получить в Фотошопе при помощи Lab системы цветов.
#73
Отправлено 25 Jan 2004 - 03:11
Само собой чем выше разрядность внутненнего пересчета тем "точнее" передаются промежуточные оттенки
...
я склонен к тому, что первой цепочки никогда не было и уже не будет
повторюсь, так я уже несколько раз здесь это писал, что спасение в 10-14 битных камерах - в 8 бит они сжимают по S-кривым и способны уследить за правильностью диапазона
Кстати DVX100 в киногамму переводит тоже S-кривыми, но я нигде не нашел информации о ее битности. Я сомневаюсь что это не 8 бит, но все же есть шансы что в будущем мини-камеры будут хотя-бы 10 битными
#74
Отправлено 25 Jan 2004 - 03:16
Именно так.значит я прав, и эти все проблемы не относятся только лишь к DV камерам?
Такие проблемы возникают при всех преобразованиях системы цветности, поскольку даже "правильный" ВТ601 выходит за пределы RGB.
Правда в нормальных условиях этого не происходит, поскольку изначально матрица работает в RGB и сгенерированый YUV из правильного RGB не содержит того, что не представить в RGB.
Ситуация проявляется, когда изначальное RGB выходит за разрешенные пределы, при этом, кстати YUV может быть и в ВТ601 пределах, но результат YUV->RGB выйдет за 0..255, т.е. не будет отображаться правильно в RGB0..255.
Самое неприятное происходит, когда изначальные RGB так далеко выходят за разрешенные пределы, что даже YUV начинает ограничивать... тогда вся информация о цвете становится искаженнои или пропадает совсем (например в середине солнца 15_235_sun Cb=Cr=128,Y=255 -> RGB=297) а на краях красный превосходит 400.
Может хоть это можно как то решить? Черт с ним с тем с оранжевым, пусть будет желтым, но только сразу и сразу в 16-235. Как это то сделать?
Ой как неохота весь материал через RGB преобразование таскать.
Теоретически можно проверить YCbCr на соответствие RGB и ограничить Cb и Cr так, чтобы результат (в RGB) не выходил за пределы RGB=0..297 (т.е. был представим в RGB16..235 8-бит).
К сожалению за ВТ601 выходит до 80% всех не профессиональных съемок...
#75
Отправлено 25 Jan 2004 - 03:24
Кстати конторольные мониторы на всех этапах в теле бизнесе подлключаются по YCrC, а не по RGB не так ли?
Нет, не так. Есть контроль и того и другого.
#76
Отправлено 25 Jan 2004 - 10:45
Потом, YUV->RGB преобразование должно быть нелинейно, иначе как можно сжать получаемый диапазон любого из RGB до предела 255?
Вот теперь остаётся выяснить, какова же на самом деле формула пересчёта, вот и всё. Если смотреть проблеме в лоб, то Gri-gri абсолютно верно подметил про преобразование с RGB матрицы в YUV. Откуда может взяться пересвет? Скажем так, с помощью RGB можно отобразить все видимые человеком цвета. При выдаче YUV мы получаем пересвет, который не отображается из-за входа RGB за пределы. Но на самом то деле, при просмотре на TV оригинального YUV сигнала, мы получаем нормальные RGB не выходящие за границы. Просто нужно найти принцип этого преобразования.
#77
Отправлено 25 Jan 2004 - 17:43
Это не совсем так.который не отображается из-за входа RGB за пределы. Но на самом то деле, при просмотре на TV оригинального YUV сигнала, мы получаем нормальные RGB не выходящие за границы.
Аналоговый сигнал матрицы оцифровывается большим числом бит (например 9-бит), (в однослойных 3-х цветных матрицах положения отдельных фотоэлементов (RGB) не совпадают, поэтому делается интерполяция для "сведения" цветов вместе), потом преобразуется в YCbCr и только потом приводится в 8-бит.
Рассмотрим это на примере красного цвета (16_235_sun.avi)
1. Если, например, красный был изначально (после матрицы) 272, а все остальные, например, 100, тогда такой сигнал можно представить в ВТ601 YCbCr(16..235, 16..240), т.е. RGB(272,100,100)->YCbCr->RGB восстанавливает исходный RGB (конечно с ошибками округления, но без ограничения цвета). Но такой RGB невозможно отобразить правильно на устройстве не имеющем запаса по яркости в 272/255=106%. Обычно CRT имеет большой запас по яркости, а ЖКИ только чуть-чуть, чтобы представить Y=0..255 серую шкалу полностью.
На этом примере понятно что с таким RGB(272,100,100) надо что-то делать, чтобы изобразить его на RGB0..255. Можно заменить на (255,100,100) или, например, на (255,93,93).
2. Если сигналы матрицы настолько большие, что они ограничиваются в YCbCr представлении, тогда цветовая информация очень сильно искажается, но в какой-то мере соответствует оригиналу.
3. Если сигналы настолько большие, что ограничиваются во входном оцифровывании, тогда RGB=(511,511,511) и, в результате, цвет полностью уничтожается, а после восстановления из YCbCr получается "максимальный белый" (272,272,272), отдельные компоненты которого меньше чем то, что получается в п.1 и п.2 (т.е. п.1 и п.2 могут, например, произвести (300,100,100) соответствующий исходному, а при полной перегрузке п.3 красный получается слабее, чем при перегрузке только по красному).
Сообщение отредактировано Gri-gri: 25 Jan 2004 - 17:46
#78
Отправлено 25 Jan 2004 - 19:51
Кстати о матрицах и RAW
http://www.photoscap...andbook/camera/
http://www.photoscap...raw/converters/
Gri-gri
Абсолютно прав про перегрузочную способность -- которая присутсвует лишь в аналоговых устойствах.
Использование в одной линейке устройств с разной калибровкой?Кстати конторольные мониторы на всех этапах в теле бизнесе подлключаются по YCrC, а не по RGB не так ли?
Нет, не так. Есть контроль и того и другого.
Редкостное извращение... В этом то и проблема с Премьером ПРО
из-за которого и возникло обсуждение. Сорри.
Eugen65
Потом, YUV->RGB преобразование должно быть нелинейно, иначе как можно сжать получаемый диапазон любого из RGB до предела 255?
Пардон вот тут и прокол -- YUV->RGB производится по фиксированым формулам, а вот результат можно
1) обрезать по младшему биту -- т.к. потери в черном, не столь принципиальны.
2) провести масштабирование -- исходя из максимальных возможных значений каждого цвета -- каждый цвет привести со своим коэффициентом.
3) найти максимальное значение каждого цвета в фрагменте и привески к 255
4) Правда посмотрев на физику -- я пока пришел к выводу, что для сохранения цветов предпочтительнее в исходном YUV уменьшать яркостную состаляющую до 60 и провести повторный пересчет YUV->RGB
При этом цветовой баланс не должен нарушаться.
5) самый сложный -- провести коррекцию только для елементов изображения по яркости превышающей 60 единиц и выходящей за пределы RGB8
Но это скорее относится к ручной работе.
Наличие многообразия перечисленых методов и есть суть проблемы...
Если бы фотошоп позволял работать более с более чем RGB8...
Но увы.
#79
Отправлено 25 Jan 2004 - 20:41
#80
Отправлено 25 Jan 2004 - 21:55
Gri-gri, ты хочешь сказать, что на мониторе компьютера невозможно получить нормальное изображение (неискажённые цвета)? Это не так. Если не переводить из YUV, то на экране монитора всё отлично видно.
Видно только до тех пор, пока монитор может представить на экране "белый ярче чем самый белый", т.е. имеет запас по яркости почти в 2 раза... У монитора с трубкой ето возможно... а у ЖКИ с подсветкой почти неверняка нет.
#81
Отправлено 26 Jan 2004 - 03:33
#82
Отправлено 26 Jan 2004 - 06:07
цитируя автора "Я завел эту ветку для поиска универсального ПРАКТИЧЕСКОГО решения ..."
п.2.
что конкретного?
Сообщение отредактировано shuster: 26 Jan 2004 - 06:09
#83
Отправлено 26 Jan 2004 - 07:11
Вот спасибо!
Думаю, что в самом деле с теорией уже можно и закончить
Даже я кое что понял .
Теперь бы чего-то для практического использования.
Пару вариантов.
Может в кодек свой Main Concept DV что встроит, хотя проблема эта не только у DV.
#84
Отправлено 26 Jan 2004 - 07:12
Ничего на PC мониторе не видно, так как любая картинка на нем уже RGB.Gri-gri, ты хочешь сказать, что на мониторе компьютера невозможно получить нормальное изображение (неискажённые цвета)? Это не так. Если не переводить из YUV, то на экране монитора всё отлично видно.
#85
Отправлено 26 Jan 2004 - 20:39
#86
Отправлено 26 Jan 2004 - 21:35
Значит проблема и в кодеке тоже?Может в кодек свой Main Concept DV что встроит, хотя проблема эта не только у DV.
#87
Отправлено 26 Jan 2004 - 21:53
Чего-то нет и просвета...
А в кодек УЖЕ всё "встроено", вот почему это монтажки не понимают!?
#88
Отправлено 27 Jan 2004 - 04:32
Да...
Чего-то нет и просвета...
А в кодек УЖЕ всё "встроено", вот почему это монтажки не понимают!?
Может в кодек свой Main Concept DV что встроит, хотя проблема эта не только у DV.
Значит проблема и в кодеке тоже?
Проблема не в кодеке, а том, что YCbCr-8-бит нельзя без потерь представить в RGB-8-бит (либо теряется точность в основном диапазоне как у Канопуса (RGB-150%), либо приходится вырезать то, что нельзя представить в RGB (RGB16..235 или RGB0...255)). Цифровое RGB-оборудование работает в RGB16..236 (т.е. сохраняет полностью диапазон белого получаемого из YCbCr ВТ601), но ограничивает то, что не представимо в RGB16..235.
Как я уже писал, YCbCr способен представить РЕАЛьНЫЕ (т.е. получаемые с матрицы) RGB выходящие за пределы 8-бит.. но только не по всем компонентам сразу. Это означает, что в ВТ601 можно представить RGB(300,0,0), но никак нельзя (300,300,300).
Так что вопрос, в общем-то, остается открытым: а что ожидается от кодека при преобразовании YCbCr -> RGB
1. Делать так, чтобы на компьютере все было так как ожидается (черный=0, белый=255, т.е. RGB0..255)
2. Делать как в цифровом RGB-оборудовании (RGB16..235) -> представляем серую шкалу без потерь (включая 235<Y<255 и 0<Y<16), и "жертвуя" непредставимыми цветами (хотя область таких цветов заметно меньше чем в RGB0..255)
3. Пожертвовать точностью представления серой шкалы, а вместо этого расширить диапазон RGB так, чтобы в него попали все возможные цвета (в том числе и "непредставимые") из YCbCr, правда при этом нескольким цветам из YCbCr будет соответствовать один и тот-же цвет в RGB (потеря точности).
4. Делать ограничение в YCbCr так, чтобы цвета оказались в RGB16..235
5. Ввести нелинеиное ограничение по RGB так, чтобы представить цвет "разумным образом" - т.е. было бы похоже на то, что видим на аналоговом мониторе с YCbCr -входом
Самое неприятное, что все эти меры не помогают при "склеивании" переходов с оригиналом... всегда будет отличие уже за счет преобразования цвета.
В пп.1,2,4,5 это отличие будет (реально) присутствовать только в "непредставимой" области, а в п.3 оно будет везде, зато в "непредставимой" области оно будет меньше.
#89
Отправлено 27 Jan 2004 - 04:53
Объясните, пожалуйста, назначение "галок" вот в таких пунктах MainConceptDV (v2.4.4)
Encoder
1. RGB 16...235
2. Clumb YUV to ITU 601r
Decoder
1. тот же
2. тот же
3. YUV2 disable
4. UYVY disable
Спасибо.
Сообщение отредактировано VVV: 27 Jan 2004 - 04:55
#90
Отправлено 27 Jan 2004 - 05:25
Использовать RGB, полностью сохраняющее серую шкалу ВТ601 и включающую 0..15 и 235..255 (т.е. соответствующую RGB цифрового студийного оборудования)
2. ограничивать YUYV(YUY2) и UYVY согласно РАЗРЕШЕННЫМ значениям в ВТ610 (16..235) -> нужно в очень редких случаях если Оverlay-Video-out-Hardware использует значения Y<16 для синхронизации.
3.4. отключить поддержку (очень редкий случай старых графических карт) для YUYV(YUY2) и UYVY в декодере
#91
Отправлено 27 Jan 2004 - 05:29
Извиняюсь за недопонимание.. я имел ввиду контрольный монитор с YCbCr-входом, а не RGB-монитор компьютера.Но на монитор то идёт сигнал в цифре, с видеокарты... И тут уже без разницы, что в качестве монитора.
#92
Отправлено 27 Jan 2004 - 10:53
dobavlju:Aleksandr_Oleynik, ошибаешься Хочешь кину тебе этот ролик в DivX и ты не отличишь его от своего видеомонитора?
+
esli u tebja videokarta rabotajet s native YUV i pleyer otpravljajet ej etu informaciju bez preobrazovanija v rgb
#93
Отправлено 27 Jan 2004 - 14:20
И кроме того графическая карта не делает преобразование YCbCr->RGB для YCbCr-overlay, а выводит его без промежуточного преобразования на Y/C-выход.dobavlju:
+
esli u tebja videokarta rabotajet s native YUV i pleyer otpravljajet ej etu informaciju bez preobrazovanija v rgb
В противном случае - преобразование в RGB УЖЕ сделано и разницу заметить принципиально не возможно.
Сообщение отредактировано Gri-gri: 27 Jan 2004 - 14:21
#94
Отправлено 27 Jan 2004 - 17:01
http://msdn.microsof.../yuvformats.asp
------------------------------
Example: Converting RGB888 to YUV 4:4:4
In the case of computer RGB input and 8-bit BT.601 YUV output, we believe that the formulas given in the previous section can be reasonably approximated by the following:
Y = ( ( 66 * R + 129 * G + 25 * B + 128) >> 8) + 16
U = ( ( -38 * R - 74 * G + 112 * B + 128) >> 8) + 128
V = ( ( 112 * R - 94 * G - 18 * B + 128) >> 8) + 128
These formulas produce 8-bit results using coefficients that require no more than 8 bits of (unsigned) precision. Intermediate results will require up to 16 bits of precision.
Example: Converting 8-bit YUV to RGB888
From the original RGB-to-YUV formulas, one can derive the following relationships for the 8-bit BT.601 definition of YUV:
Y = round( 0.256788 * R + 0.504129 * G + 0.097906 * + 16
U = round(-0.148223 * R - 0.290993 * G + 0.439216 * + 128
V = round( 0.439216 * R - 0.367788 * G - 0.071427 * + 128
Therefore, given:
C = Y - 16
D = U - 128
E = V - 128
the formulas to convert YUV to computer RGB can be derived as follows:
R = clip( round( 1.164383 * C + 1.596027 * E ) )
G = clip( round( 1.164383 * C - (0.391762 * D) - (0.812968 * E) ) )
B = clip( round( 1.164383 * C + 2.017232 * D ) )
where clip() denotes clipping to a range of [0..255]. These formulas can be reasonably approximated by the following:
R = clip(( 298 * C + 409 * E + 128) >> 8)
G = clip(( 298 * C - 100 * D - 208 * E + 128) >> 8)
B = clip(( 298 * C + 516 * D + 128) >> 8)
These formulas use some coefficients that require more than 8 bits of precision to produce each 8-bit result, and intermediate results will require more than 16 bits of precision.
-------------------------------
Как это делат Canopus DVStorm2 -- тоже не хорошо -- при включении Save Color если верить Vectorscop -- (и глазам) производится жесткое независимое НЕСВЯЗАНОЕ лимитирование (обрезание выстующих за пределы допуска составляющих) как якростного так и цветоразностных составляющих.
S-кривые на YUV каналах делают это визуально иначе.
Пока наилучший визуальный способ -- при помощи Y кривой вручную подобрать диапазон и "растяжку" в ярком пятне Y, а потом при помощи Chroma подобрать уменьшение цветности...
Яркостью и контрастностью не дает возможности растянуть яркость в нужном поддиапазоне, а манипуляции UV кривыми не удобны для соблюдения оттенков...
--------------------
Технология создания искусственной пересвеченой картинки:
В фотошопе выбираете систему цвета LAB/8 на канал.
Рисуете используя максимальные значения L,a,b.
Сливаете все слои в один
СОХРАНИТЕ ЭТОТ ФАЙЛ КАК ЭТАЛОН.
Переключаете разрядность на 16/бит
Переключаете систему цвета на RGB
Сохраняте -- теперь пользуясь этой картинкой
вы можете убедится в дефекте и определить
"пораженные цвета".
Проверка наличия дефекта отображения
без корректного ТВ выхода (т.е. дорогой платы)
Вставляете эту картинку в видеоредактор
и регулируете YUV сжимая диапазон до начала видоизменения
картинки на экране -- после видимого изменения верните
регулировку на шаг назад.
Сохранение этот визуально не изменившийся кадр.
Откройте в фотошопе Эталон и вставте вторым слоем полученый кадр
Пощелкайте видимостью слоев и убедитесь что разницы
не видно.
Теперь задайте в свойсвах верхнего слоя Difference -- вы получите
черный экран -- можете поводить мышом и увидеть разницу в инфо,
а можете слить слои и при помощи CTRL+L (Level) -- auto увидить
разницу отчетливо.
----------------------------------
Полный диапазон YUV 888 -- RGB 12-,10-,12-бит с большим смещением в
минусовые цвета.
Я счас ставлю задачу программеру -- скан файла вывод найденого пересвеченого кадра и вывод рядом "усиленой" разницы
и выбор разных типов коррекции для кадра -- сохранение
фильмов для сравнения исходного и "откорректированого".
А там по статистике -- бум посмотреть как сложится.
Правда далее как у него будет с желанием возиться с этой задачей
не знаю...
#95
Отправлено 28 Jan 2004 - 10:01
#96
Отправлено 28 Jan 2004 - 19:23
Или может програмку-фильтр напишет???
Или еще какой ПРАКТИЧЕСКИЙ вывод-совет?
#97
Отправлено 28 Jan 2004 - 19:41
Если такая утилитка будет, то можно с её помощью выловить участки с пересветом, поставить маркеры и при необходимости через фильтр Broadcast Colors.
Вроде бы пока так вырисовывается.
#98
Отправлено 28 Jan 2004 - 19:54
dlja programmistov -est' ideja no ne proverennaja - decode kadra - opredeljajem maksimum ljuma i privodim tol'ko ee k normal'nomu vidu U,V ne trogajem
#99
Отправлено 28 Jan 2004 - 21:54
Я понял назначение данной утилиты так - автоматическое определение пересвета (пусть будет только luma), рассановка маркеров на этих участках.
А дальше уже пусть решает монтажер - то ли материал выкинуть вообще, то ли избежать кодека, а если всё же нужен пресловутый переход (ну, может титры), то тогда уже самому работать. Broadcast Colors - попроще, можно в Sintetic Aperture Color Finesse, лишь бы мониторинг был.
Вот в голову пришло - для АЕ попробовать скрипт написать для этих целей, только как маркеры в монтажку перенести и будет ли все это быстро?
#100
Отправлено 29 Jan 2004 - 00:33
Тогда титры и переходы можно будет делать как обычно, правда все настройки цвета будут немного не такими как в RGB
Так, просто идея.
Сообщение отредактировано Gri-gri: 29 Jan 2004 - 00:35
0 человек читают эту тему
0 пользователей, 0 гостей, 0 скрытых пользователей