Перейти к содержимому


Перед регистрацией ознакомьтесь с темой про сертификат безопасности:
Фотография
* * * * * 2 Голосов

Корректная работа с DV (BT601, YUV и RGB)


  • Please log in to reply
388 ответов в этой теме

#51 Eugen65

Eugen65

    Дал камеру подержать другу

  • Писатели
  • PipPipPipPipPip
  • 265 Сообщений:

Отправлено 22 Jan 2004 - 16:57

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

Ошибаешься. Я уже писал, что спокойно получил этот же файл, только в формате DivX без искажений! Просто с декодера DV я брал не RGB сигнал, а YUV и всё пучком. Другое дело, что для работы в программах редактирования нужно будет будет переходить к RGB, вот тут и возникают проблемы.

#52 Vlas

Vlas

    Учусь ставить камеру на телегу

  • Читатели
  • PipPipPipPipPipPip
  • 549 Сообщений:

Отправлено 22 Jan 2004 - 18:21

Кажется мне проблема YCbCr->RGB->YCbCr не только и не столько в диапазонах
просто Y=235 (и уж тем более 255) имеет белый и только белый цвет. Поэтому если вдруг случится так, что Y=235, а Cb или Cr не равны 0 то цвета RGB, вылезающие за 255 вам обеспечены. На ТВ где аналог это нормально, а вот в компе... Потому и превращается оранжевый черт знает во что...
В общем научиться надо корректно из YCbCr делать RGB и наоборот. Делать не сложно (в теории) - просто диапазоны подогнать соответствующим образом и устроийства отображения откалибровать. Практическим решением займусь обязательно, но не сейчас (диплом поперек горла стоит).

#53 Eugen65

Eugen65

    Дал камеру подержать другу

  • Писатели
  • PipPipPipPipPip
  • 265 Сообщений:

Отправлено 23 Jan 2004 - 01:19

Vlas, ты абсолютно прав!!! Правда обрезание выше диапазона 235 отрезает некоторые оттенки белого (мне так показалось). Посмотри сюда http://www.fourcc.org/fccyvrgb.php Там есть формулы для пересчёта. Я не программер, а то сам бы занялся этим... Идеальный вариант, написать плаг для Avisynth. Странно другое, почему никто другой ещё этого не сделал.

#54 Aleksandr_Oleynik

Aleksandr_Oleynik

    O

  • Модераторы
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 15373 Сообщений:

Отправлено 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 DaLiV

DaLiV

    Спрашивайте только если не разберетесь сами.

  • Админы
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 2295 Сообщений:

Отправлено 23 Jan 2004 - 14:18

interesno - a pri sjemkah takih objektov kamera zebroj ne rugajetsja ?
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 Aleksandr_Oleynik

Aleksandr_Oleynik

    O

  • Модераторы
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 15373 Сообщений:

Отправлено 23 Jan 2004 - 16:07

Естественно, что зебра ругается.
Но как можно снять такой материал без пересвета? Да и не только такой, а любой темный объект на светлом фоне.
Речь идет о бытовой съемке в которой невозможно снять без пересвета в 50 из 100 сцен.
Я очень внимательно слежу за зеброй, врядли кто-то это будет делать так как я, но у меня половина сцен, ну треть, имеют пересвет и на каждой касете есть одна-две сцены в которых пересвет влияет на цвета, а не только на белый :(!

#57 DaLiV

DaLiV

    Спрашивайте только если не разберетесь сами.

  • Админы
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 2295 Сообщений:

Отправлено 23 Jan 2004 - 17:12

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

#58 Vlas

Vlas

    Учусь ставить камеру на телегу

  • Читатели
  • PipPipPipPipPipPip
  • 549 Сообщений:

Отправлено 23 Jan 2004 - 18:31

Может все-же есть способ заставить всех правильно работать с YUV 0-255?

Проблема YCrCb не только и не столько в диапазонах. Просто надо понять, что не всем возможным комбинациям Y, Cr и Cb соответствуют некотороые цвета в RGB 0-255
Например, если Y=235, U=220, V=16, то вы получите такой КРАНСНЫЙ, который ваш ваш монитора не отобразит, ибо R явно вылезет за 255, причем сильно. Его зарежут. Картинка приобретет неправильный оттенок.

можно конечно подумать  об создании патча к существующему кодеку

Я вот скорее думаю о проге, позволяющей править уровни DV без рекомпрессии (ну статистическое сжатие без потерь не в счет, я имею в виду DCT). Задача интересная и востребованная. А заодно о проге, переводящей DV в различне форматы (AVI, QT, Avid) тоже без рекомпрессии

Сообщение отредактировано Vlas: 23 Jan 2004 - 18:41


#59 Gri-gri

Gri-gri

    А что такое камера, NLE?

  • Участники
  • Pip
  • 15 Сообщений:

Отправлено 23 Jan 2004 - 19:46

Последная версия MainConcept DV умеет использовать RGB-16..235, позволяющая без ограничения представить
большии диапазон ITU601R (YCbCr) чем нормальный RGB 0..255.

Кто-нибудь пробовал этим воспользоваться?

#60 DaLiV

DaLiV

    Спрашивайте только если не разберетесь сами.

  • Админы
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 2295 Сообщений:

Отправлено 23 Jan 2004 - 20:35

proboval - tolku osobogo netu.
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 Eugen65

Eugen65

    Дал камеру подержать другу

  • Писатели
  • PipPipPipPipPip
  • 265 Сообщений:

Отправлено 23 Jan 2004 - 21:28

Aleksandr_Oleynik, способ только один - правильно преобразовывать YUV - RGB - YUV. Если неправильно преобразовывать в RGB, делать монтаж с "правильным" материалом, то получится сам знаешь что... Пожалуй, возврат обратно в YUV будет важен только для программ типа Edition, которые оперируют только с DV. Поэтому, вижу проблему только с прямым преобразованием в RGB, ведь его можно подсунуть любой программе редактирования и кодеру Mpeg2. И, если в RGB будут уже правильные уровни, можно будет элементарно его совать хоть куда.
Тепер ответ на твой вопрос

Раз RGB может быть 0-255, а YUV только 16-235, а мы видим, что очень легко записать YUV с диапазоном шире 16-235, то может все-таки не искать решение в корректном сужении диапазона в YUV до 16-235?
Может все-же есть способ заставить всех правильно работать с YUV 0-255?

В цифорвой форме, мы можем записать уровни этих сигналов в диапазоне 0-255. Но если мы посмотрим на стандарт... то окажется, что камера не правильно отрабатывает пересвет, вот и всё. Наша задача, избавиться от этого брака. Ведь проблемы то именно из-за выхода камеры за диапазон 16-235.
Vlas

Проблема YCrCb не только и не столько в диапазонах. Просто надо понять, что не всем возможным комбинациям Y, Cr и Cb соответствуют некотороые цвета в RGB 0-255
Например, если Y=235, U=220, V=16, то вы получите такой КРАНСНЫЙ, который ваш ваш монитора не отобразит, ибо R явно вылезет за 255, причем сильно. Его зарежут. Картинка приобретет неправильный оттенок.

хоть кто-то понимает суть проблемы... Я рад.

А заодно о проге, переводящей DV в различне форматы (AVI, QT, Avid) тоже без рекомпрессии

Это как? Да ещё без рекомпрессии? Совсем не понял. Для нормальной работы (без искажений) нужно будет перевести в RGB и делов то... а дальше лепи любой кодек. Самый оптимальный способ написать конвертор для Avisynth. Поясню почему. При открытии в Avisynth, формат цветности не изменяется, пока этого не потребуется программе. Если написать такой конвертор (YUV-RGB-YUV), с настраевыми множителями при параметрах (если кто-то захочет сам подбирать) то все проблемы были бы решены. Если кто-то захочет, то могу свести с теми, кто поможет разобраться с Avisynth и написанием плагов для них. А писать свою прогу... по-моему не рационально.

#62 lagush

lagush

    Сенсей для друзей по NLE

  • Активные Участники
  • PipPipPipPipPipPipPipPipPipPip
  • 1074 Сообщений:

Отправлено 23 Jan 2004 - 23:23

Может кто кинет ссылку на буржуйские форумы по обсуждению данной проблемы. Сам ни чего похожего не нашел, как будто у них нет этого вопроса… Сам долго искать не могу -- time-limit.

#63 Gri-gri

Gri-gri

    А что такое камера, NLE?

  • Участники
  • Pip
  • 15 Сообщений:

Отправлено 24 Jan 2004 - 02:48

16-235_sun содережит (если делать YCbCr -> RGB без ограничения) значения цвета на краях солнца 432 (тогда как максимально в 8-бит помещается только 255). Самое "неприятное", что в середине солнца при етом только R=G=B=276, т.е. середина солнца выглядит сушественно темнее, чем красные края.

Я попробовал отскалировать это так, чтобы красныей стал 255 и посмотреть на экране как ето выглядит...
В этом случае на месте солнца получается "серая дыра", выглядящая более чем неестественно.
Понятно, что это происходит потому, что информация о яркости в центре просто отсутствует (т.е. Y=255 надо интерпретировать как: не знаю что там и какого цвета, но очень много)

К чему все это?
А к тому, что в случае выхода какоей-либо компоненты RGB за пределы "максимально-белого" (Y=255, Cb=128, Cr=128 (нормальныей белый соответствует {235,128,128})) получаем неопределенные значения цвета... и то, как ето будет выглядеть на экране зависит исключительно от везения... т.е. на одном устроействе ето может выглядеть чуть краснее, на другом будет желтым, на третьем - оранжевым...

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

Если пытаться делать ограничение в YCbCr (т.е. ограничивать Cb и Cr так, чтобы результат не выходил за разрешенные пределы в RGB (y=1.0 -> rgb=1.0) то тогда (зрительно) оранжево-желтая область становится практически белой... можно ли это считать желаемым результатом я не знаю.

#64 Aleksandr_Oleynik

Aleksandr_Oleynik

    O

  • Модераторы
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 15373 Сообщений:

Отправлено 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 Gri-gri

Gri-gri

    А что такое камера, NLE?

  • Участники
  • Pip
  • 15 Сообщений:

Отправлено 24 Jan 2004 - 03:42

Если интересно могу прислать по e-mail картинки, которые получаются. Конечно использовать вместо RGB0..255 что-нибугь пошире (например RGB16..235) несколько поможет. Но не в таком "патологическом" случае... здесь даже 150% не хватит.

Предполагается что все 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 Muhin

Muhin

    не теряя ни секунды

  • Активные Участники
  • PipPipPipPipPipPipPipPipPipPip
  • 1783 Сообщений:

Отправлено 24 Jan 2004 - 04:49

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

#67 Gri-gri

Gri-gri

    А что такое камера, NLE?

  • Участники
  • Pip
  • 15 Сообщений:

Отправлено 24 Jan 2004 - 05:56

Именно так. То что получается в видей YCbCr это результат довольно сложного процесса, которыей можно очень упрощенно представить в виде:
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 Aleksandr_Oleynik

Aleksandr_Oleynik

    O

  • Модераторы
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 15373 Сообщений:

Отправлено 24 Jan 2004 - 12:45

Gri-gri ,
значит я прав, и эти все проблемы не относятся только лишь к 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 Eugen65

Eugen65

    Дал камеру подержать другу

  • Писатели
  • PipPipPipPipPip
  • 265 Сообщений:

Отправлено 24 Jan 2004 - 14:25

2. Если этот ненормативный цвет присутствует в YUV изображении только потому, что оно в целом вышло за диапазон 16-235, то чем объяснить тот факт, что я сжимаю диапазон оригинала до 16-235, но только фильтром работающим без преобразования в RGB, а проблема остается. Т.е. как только такое уже полностью отвечающее стандарту BT601 YUV изображение с диапазоном 16-235 я преобразовываю в RGB – все, оранжевого нет, есть только грязно желтый.

Можешь выложить этот кадрик? Очччень интересно...

3. Попробовал оцифровать материал по аналоговому входу Тарги3000, что в MPEG2 I, что в некомпрес – материал идентичен DV. А хотелось бы найти хотя бы способ оцифровки такой, чтобы потом не выискивать по всему материалу такие вот ненормативные куски.

Всё абсолютно верно. Mpeg2 производит захват в том-же YUV. Ты попробуй этот материал дальше преобразовать в RGB, вот тут опять вылезут проблемы.

#70 Aleksandr_Oleynik

Aleksandr_Oleynik

    O

  • Модераторы
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 15373 Сообщений:

Отправлено 24 Jan 2004 - 17:52

Что проблемы вылезут с YUV захваченым материалом понятно, что аналог, что цыфра :(, вот я и ищу способ.

Кажется чуть научился понимать вектроскоп - приведу диаграмки.
Первая, это RGB сделанный из оригинального YUV (последняя, средняя, это YUV откорректированный кадр с сохраненным оранжевым и более менее всеми остальными цветами, правда яркость потушена основательно - но зато в RGB и обратно без сучка и задоринки.
Вообще я так посмотрел, что в данном случае диаграмма Lightning и ее пунктирная область - гловенствующая. Если за нее выходишь - кранты, цвет при RGB преобразовании меняется.

Прикрепленные изображения

  • ColorCorect.png


#71 Gradov_Georg

Gradov_Georg

    штатный злобный буратино форума

  • Модераторы
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 7790 Сообщений:

Отправлено 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 Gradov_Georg

Gradov_Georg

    штатный злобный буратино форума

  • Модераторы
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 7790 Сообщений:

Отправлено 25 Jan 2004 - 00:11

Aleksandr_Oleynik
Спасибо за пример с вектороскопом. Очень похоже на правду

Кстати изложенное очень четко объясняет почему на синтетических картинках нет никакой возможности получить пересвет.

Теоретически пересвет можно получить в Фотошопе при помощи Lab системы цветов.

#73 Alf_Zetas

Alf_Zetas

    Вставляю своих 5 копеек

  • Модераторы
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 10836 Сообщений:

Отправлено 25 Jan 2004 - 03:11

Само собой чем выше разрядность внутненнего пересчета тем "точнее" передаются промежуточные оттенки
...
я склонен к тому, что первой цепочки никогда не было и уже не будет


повторюсь, так я уже несколько раз здесь это писал, что спасение в 10-14 битных камерах - в 8 бит они сжимают по S-кривым и способны уследить за правильностью диапазона
Кстати DVX100 в киногамму переводит тоже S-кривыми, но я нигде не нашел информации о ее битности. Я сомневаюсь что это не 8 бит, но все же есть шансы что в будущем мини-камеры будут хотя-бы 10 битными

#74 Gri-gri

Gri-gri

    А что такое камера, NLE?

  • Участники
  • Pip
  • 15 Сообщений:

Отправлено 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 Gri-gri

Gri-gri

    А что такое камера, NLE?

  • Участники
  • Pip
  • 15 Сообщений:

Отправлено 25 Jan 2004 - 03:24

Кстати конторольные мониторы на всех этапах в теле бизнесе подлключаются по YCrC, а не по RGB не так ли?


Нет, не так. Есть контроль и того и другого.

#76 Eugen65

Eugen65

    Дал камеру подержать другу

  • Писатели
  • PipPipPipPipPip
  • 265 Сообщений:

Отправлено 25 Jan 2004 - 10:45

Gradov_Georg, начну с того, что диапазон цветности любых цветов 0-255, а не 0-254. Это можно увидеть а Avisynth.
Потом, YUV->RGB преобразование должно быть нелинейно, иначе как можно сжать получаемый диапазон любого из RGB до предела 255?
Вот теперь остаётся выяснить, какова же на самом деле формула пересчёта, вот и всё. Если смотреть проблеме в лоб, то Gri-gri абсолютно верно подметил про преобразование с RGB матрицы в YUV. Откуда может взяться пересвет? Скажем так, с помощью RGB можно отобразить все видимые человеком цвета. При выдаче YUV мы получаем пересвет, который не отображается из-за входа RGB за пределы. Но на самом то деле, при просмотре на TV оригинального YUV сигнала, мы получаем нормальные RGB не выходящие за границы. Просто нужно найти принцип этого преобразования.

#77 Gri-gri

Gri-gri

    А что такое камера, NLE?

  • Участники
  • Pip
  • 15 Сообщений:

Отправлено 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 Gradov_Georg

Gradov_Georg

    штатный злобный буратино форума

  • Модераторы
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 7790 Сообщений:

Отправлено 25 Jan 2004 - 19:51

Сорри, 254-255 это типичная ошибка и ссылаться нужно на 2^8, а не на AVSINT... Можно провести пересчет моих данных и убедится что суть не изменится... YUV диапазон БОЛЬШЕ по всем границам чем RGB и пересвет возможен только в случае если с матрицы более чем 8 бит преобразование идет в YUV. Обсуждение же касается только ПЕРЕСВЕТА, потому, что область черного значительно хуже отображается и как следствие искажения в черном менее заметны.

Кстати о матрицах и 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 Eugen65

Eugen65

    Дал камеру подержать другу

  • Писатели
  • PipPipPipPipPip
  • 265 Сообщений:

Отправлено 25 Jan 2004 - 20:41

Gri-gri, ты хочешь сказать, что на мониторе компьютера невозможно получить нормальное изображение (неискажённые цвета)? Это не так. Если не переводить из YUV, то на экране монитора всё отлично видно.

#80 Gri-gri

Gri-gri

    А что такое камера, NLE?

  • Участники
  • Pip
  • 15 Сообщений:

Отправлено 25 Jan 2004 - 21:55

Gri-gri, ты хочешь сказать, что на мониторе компьютера невозможно получить нормальное изображение (неискажённые цвета)? Это не так. Если не переводить из YUV, то на экране монитора всё отлично видно.


Видно только до тех пор, пока монитор может представить на экране "белый ярче чем самый белый", т.е. имеет запас по яркости почти в 2 раза... У монитора с трубкой ето возможно... а у ЖКИ с подсветкой почти неверняка нет.

#81 Eugen65

Eugen65

    Дал камеру подержать другу

  • Писатели
  • PipPipPipPipPip
  • 265 Сообщений:

Отправлено 26 Jan 2004 - 03:33

Но на монитор то идёт сигнал в цифре, с видеокарты... И тут уже без разницы, что в качестве монитора.

#82 shuster

shuster

    Дал камеру подержать другу

  • Писатели
  • PipPipPipPipPip
  • 357 Сообщений:
  • место работы:

Отправлено 26 Jan 2004 - 06:07

п.1.
цитируя автора "Я завел эту ветку для поиска универсального ПРАКТИЧЕСКОГО решения ..."
п.2.
что конкретного?

Сообщение отредактировано shuster: 26 Jan 2004 - 06:09


#83 Aleksandr_Oleynik

Aleksandr_Oleynik

    O

  • Модераторы
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 15373 Сообщений:

Отправлено 26 Jan 2004 - 07:11

shuster
Вот спасибо!
Думаю, что в самом деле с теорией уже можно и закончить
Даже я кое что понял :).

Теперь бы чего-то для практического использования.
Пару вариантов.
Может в кодек свой Main Concept DV что встроит, хотя проблема эта не только у DV.

#84 Aleksandr_Oleynik

Aleksandr_Oleynik

    O

  • Модераторы
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 15373 Сообщений:

Отправлено 26 Jan 2004 - 07:12

Gri-gri, ты хочешь сказать, что на мониторе компьютера невозможно получить нормальное изображение (неискажённые цвета)? Это не так. Если не переводить из YUV, то на экране монитора всё отлично видно.

Ничего на PC мониторе не видно, так как любая картинка на нем уже RGB.

#85 Eugen65

Eugen65

    Дал камеру подержать другу

  • Писатели
  • PipPipPipPipPip
  • 265 Сообщений:

Отправлено 26 Jan 2004 - 20:39

Aleksandr_Oleynik, ошибаешься :) Хочешь кину тебе этот ролик в DivX и ты не отличишь его от своего видеомонитора?

#86 lagush

lagush

    Сенсей для друзей по NLE

  • Активные Участники
  • PipPipPipPipPipPipPipPipPipPip
  • 1074 Сообщений:

Отправлено 26 Jan 2004 - 21:35

Может в кодек свой Main Concept DV что встроит, хотя проблема эта не только у DV.

Значит проблема и в кодеке тоже?

#87 VVV

VVV

    Прежде чем куда-то войти, подумай, как оттуда выйти...

  • Модераторы
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 5116 Сообщений:

Отправлено 26 Jan 2004 - 21:53

Да...
Чего-то нет и просвета...
А в кодек УЖЕ всё "встроено", вот почему это монтажки не понимают!?

#88 Gri-gri

Gri-gri

    А что такое камера, NLE?

  • Участники
  • Pip
  • 15 Сообщений:

Отправлено 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 VVV

VVV

    Прежде чем куда-то войти, подумай, как оттуда выйти...

  • Модераторы
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 5116 Сообщений:

Отправлено 27 Jan 2004 - 04:53

Gri-gri
Объясните, пожалуйста, назначение "галок" вот в таких пунктах 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 Gri-gri

Gri-gri

    А что такое камера, NLE?

  • Участники
  • Pip
  • 15 Сообщений:

Отправлено 27 Jan 2004 - 05:25

1. RGB16..235:
Использовать 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 Gri-gri

Gri-gri

    А что такое камера, NLE?

  • Участники
  • Pip
  • 15 Сообщений:

Отправлено 27 Jan 2004 - 05:29

Но на монитор то идёт сигнал в цифре, с видеокарты... И тут уже без разницы, что в качестве монитора.

Извиняюсь за недопонимание.. я имел ввиду контрольный монитор с YCbCr-входом, а не RGB-монитор компьютера.

#92 DaLiV

DaLiV

    Спрашивайте только если не разберетесь сами.

  • Админы
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 2295 Сообщений:

Отправлено 27 Jan 2004 - 10:53

Aleksandr_Oleynik, ошибаешься :) Хочешь кину тебе этот ролик в DivX и ты не отличишь его от своего видеомонитора?

dobavlju:
+
esli u tebja videokarta rabotajet s native YUV i pleyer otpravljajet ej etu informaciju bez preobrazovanija v rgb

#93 Gri-gri

Gri-gri

    А что такое камера, NLE?

  • Участники
  • Pip
  • 15 Сообщений:

Отправлено 27 Jan 2004 - 14:20

dobavlju:
+
esli u tebja videokarta rabotajet s native YUV i pleyer otpravljajet ej etu informaciju bez preobrazovanija v rgb

И кроме того графическая карта не делает преобразование YCbCr->RGB для YCbCr-overlay, а выводит его без промежуточного преобразования на Y/C-выход.
В противном случае - преобразование в RGB УЖЕ сделано и разницу заметить принципиально не возможно.

Сообщение отредактировано Gri-gri: 27 Jan 2004 - 14:21


#94 Gradov_Georg

Gradov_Georg

    штатный злобный буратино форума

  • Модераторы
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 7790 Сообщений:

Отправлено 27 Jan 2004 - 17:01

Как это делает Билли Гейтс -- расчет в 16 битных словах и отбрасывание младших битов (как уже писалось -- это не наш путь):

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 * B) + 16
U = round(-0.148223 * R - 0.290993 * G + 0.439216 * B) + 128
V = round( 0.439216 * R - 0.367788 * G - 0.071427 * B) + 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 Vlas

Vlas

    Учусь ставить камеру на телегу

  • Читатели
  • PipPipPipPipPipPip
  • 549 Сообщений:

Отправлено 28 Jan 2004 - 10:01

Ну в общем из всего вышесказанного следует, что YUV надо в RGB 10bit перегонять (или в 16 что еще лучше) так, подбирая диапазоны так, чтобы ЛЮБОЙ комбинации YUV соответствовал цвет RGB, потом отрываться в композере, потом обратно в YUV. В общем, работаем в 10 bit !

#96 Aleksandr_Oleynik

Aleksandr_Oleynik

    O

  • Модераторы
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 15373 Сообщений:

Отправлено 28 Jan 2004 - 19:23

А практический совет-резюме с конкретной схемой работы кто нибудь изложит после всей этой теории????
Или может програмку-фильтр напишет???
Или еще какой ПРАКТИЧЕСКИЙ вывод-совет?

#97 VVV

VVV

    Прежде чем куда-то войти, подумай, как оттуда выйти...

  • Модераторы
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 5116 Сообщений:

Отправлено 28 Jan 2004 - 19:41

Надо программисту Gradov_Georg ия подарить miniDV :D .
Если такая утилитка будет, то можно с её помощью выловить участки с пересветом, поставить маркеры и при необходимости через фильтр Broadcast Colors.
Вроде бы пока так вырисовывается.

#98 DaLiV

DaLiV

    Спрашивайте только если не разберетесь сами.

  • Админы
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 2295 Сообщений:

Отправлено 28 Jan 2004 - 19:54

VVV : vizual'no uchastki s peresvetom i tak uvidis ( v tom zhe vegase nalozhiv plug legacy br.colors s vkljucehhoj galkoj invertirovat') - no dazhe nalozhiv fil'tr broadcast colors ti ne reshish dannuju problemu - poskol'ku cveta uzhe iskazheni na stadii decode.
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 VVV

VVV

    Прежде чем куда-то войти, подумай, как оттуда выйти...

  • Модераторы
  • PipPipPipPipPipPipPipPipPipPipPipPipPipPipPip
  • 5116 Сообщений:

Отправлено 28 Jan 2004 - 21:54

DaLiV
Я понял назначение данной утилиты так - автоматическое определение пересвета (пусть будет только luma), рассановка маркеров на этих участках.
А дальше уже пусть решает монтажер - то ли материал выкинуть вообще, то ли избежать кодека, а если всё же нужен пресловутый переход (ну, может титры), то тогда уже самому работать. Broadcast Colors - попроще, можно в Sintetic Aperture Color Finesse, лишь бы мониторинг был.
Вот в голову пришло - для АЕ попробовать скрипт написать для этих целей, только как маркеры в монтажку перенести и будет ли все это быстро?

#100 Gri-gri

Gri-gri

    А что такое камера, NLE?

  • Участники
  • Pip
  • 15 Сообщений:

Отправлено 29 Jan 2004 - 00:33

А если вместо BGRA (т.е. RGB + прозрачность) использовать VUYA (т.е. Cr<->R, Cb<->G, Y<->R + прозрачность) ?
Тогда титры и переходы можно будет делать как обычно, правда все настройки цвета будут немного не такими как в RGB :)

Так, просто идея.

Сообщение отредактировано Gri-gri: 29 Jan 2004 - 00:35





0 человек читают эту тему

0 пользователей, 0 гостей, 0 скрытых пользователей



Рейтинг@Mail.ru