388 ответов в этой теме

[Aleksandr_Oleynik]

Нет, с тобой после изучения Испанского точно что-то не так .

[marat_k]

И справка есть!

[DenizZ]

Читал-читал - совсем запутался...
Насколько я понял - задача правильно сунуть и вынуть материал из АЕ?..
Почему не попробовать Ависинт? Он может конвертировать колорспэйсы (насколько я понял) и его фэйк-авишки легко понимаются АЕ.

Пример (я говорил об этом в "заметках на мышином ковре"): нужно втянуть в АЕ сиквенс из 70к кадров например... Простой импорт займёт весьма приличное время. Если сделать скрипт и из него - ави, то импорт будет почти мгновенным. А в самом скрипте пиши, что хочешь, да и Link2 тоже кое-что предлагает...

А рендерить...

Просто так сложилось, что кроме сиквенсов я практически ни с чем не работаю. Оч.редко - qt-футажи. И всегда привязан к чему-то от DPS...

[marat_k]

У фильтров Avisynth (ConvertToRGB24 и ConvertToRGB32) будут те же самые проблемы, все что в диапазоне перейдет нормально, остальное будет меняться, а перевода в 16bpp RGB что-то не нашел.

[Aleksandr_Oleynik]

Nickos
На целый день наверное нет , спасибо, а вот скажем с 15-00 и до предела терпения того Профи, что сядет рядом????????
antidemOOn
Давай уже как-то на ТЫ? В инете нет возраста .

Два стандарта DV существует, все зависит от аппаратного и программного кодеков.

Не зависит это ни от чего, кроме камеры и оператора. Камеры, во всяком случае все, что держал в руках или видел отснятое ими, позволяют снимать в яркостном диапазоне 0-255, вернее 16-255 (нижний предел почему-то ниже 16 не встречал. И снимают они в RGB, только пишут на ленту в YUV (причины пусть профи объясняют).

Используйте фильтры типа Броадкаст колор.

Так в том то и дело, что загонять отснятый материал в 16-235 нужно только если он предполагает трансляцию на TV, а если это для домашнего видео, или для DVD, нафига сужать диапазон? Какими бы фильтрами не пользовался при сужении диапазона часть информации пропадет.

А вообще Я сталкивался раньше с этим, все равно материал всегда коррекировал и подгонял

Вот вот - подгонял , вот так профи и решают возникающие проблемы. А может все-же правильнее использовать программы, которые не требуют отсмотра всего материала (иногда покадрово) и гарантируют, что никаких всплесков от применения фильтров работающих не в YUV и не в 0-255 в ит огоге не будет? А если потом этот материал нужно вознать в 601 стандарт для TV, так на весь материал и кинуть Броадкаст колор, или прогнать через апаратный нормолайзер.

Сейчас к сожалению времени мало, но под преобразованием YUV и RGB я имел ввиду внутри композера поэтому написал - цифровой, а то что там кодеки творят - это совсем другое дело. Это проблема я думаю касается MainConcept, - я использовал Панасоник для ДВ или Канопус.

Опять ошибочное представление. Кодек не причем, он прекрасно справляется с задачей не преобразовывать YUV DV материал в RGB, если об этом подумали програмисты проектирующие Монтажку, Premier - использовать нельзя, Adobe обманул своих пользователей!!!!!

Современные кодеки типа Панасоника или MainConcept выдерживают до 10 рекомпрессий без заметной на глаз потери.

Вот это и подтверждает сказанное мной, что кодек в проблемме YUV-RGB-YUV преобразовании не причем, да и в загоне в 16-235 принудительном (как это сделано в Premier) тоже.

Для резки ДВ я тебе маленький проект под АЕ с комментариями пошлю - там разберешься.

Огромное спасибо!!! На oleynik@videoediting.ru

[antidemOOn]

Уже выслал....
DV - MJPG, с жесткозаданым битрейтом, каждый кадр - ключевой и весит не помню сколько килобайт.
Его прелесть в том, что при монтаже в стык, без просчета, без эфектов - какой-бы сложный монтаж не был он отдает материал в исходном формате.
Проблемы начинаются, если я правильно понял при накладывании титров, эфектах и переходах?
Можно настроить кодек или пересчитать Весь материал (или план до эффекта и после эффекта). А броадкаст - ничего страшного с DV не сделает.
кадр DV - jpg с решеткой 4х4 (в посланом проекте для кея эта особенность и учитывается) хранится действительно YUV 4.4.0 формате, для компрессии, как и любой jpeg.

А больше я ниче не знаю, про то как Адоб обнанул, - они всегда одманищики были и остануца - смогли продать 1.0 версию как законченый продукт ,
причем наравне с Майкрософт и ее directshow, wmv и т.д.
В аппл ведь квиктайм не глючит, больше того он и под виндосом корректно работает - переходите на QT DV - он там 1999 году уже был встроен.
Для АВИ попробуйте в Майнконцепте понастраивать, там пара галок есть YUY2 disable или UyVy disable.
Попробуйте проект с другим DV кодеком создать. Экспериментируй и побеждай Зло - это наша цель. Да будет добро!!!!
Если все в авторе делать - то эффекта нет. - там все пересчитывается

Я всегда все обрабатываю - у меня таких заморочек.

Не в премьере мне кажется дело а маинконцепте, встроеном в премьер

Сообщение отредактировано antidemOOn: 20 Aug 2004 - 22:33

[Aleksandr_Oleynik]

Уже выслал....

Уже получил - огромное спасибо!! Завтра , вернее уже сегодня, гляну.

Его прелесть в том, что при монтаже в стык, без просчета, без эфектов - какой-бы сложный монтаж не был он отдает материал в исходном формате.

Встык он и есть встык, какой уж тут сложный монтаж?

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

Абсолютно правильно ты понял.

Можно настроить кодек или пересчитать Весь материал (или план до эффекта и после эффекта).

Так и делаем, но времени это отнимает.................., но кодек настроить нельзя, ничего это не дает.

А броадкаст - ничего страшного с DV не сделает.

Еще как делает - в зоне 235-255 пропадают все детали, а они и так при засвете не сильно подробные.

А больше я ниче не знаю, про то как Адоб обнанул,

Adobe обещал все свои фильтры и переходы, также как и у других профи монтажек, сделать работающими без преобразования в RGB, только в YUV пространстве - а сделал аж два, а все остальное - в RGB, да еще и в 16-235.
Вот и получается что в месте перехода скачкообразно тухнет белый и если отснятый в YUV материал имеет шире цвета, чем может RGB, так еще и цвета меняются, наприме ярко оранжевый скачком становится грязножелтым.

Всего отого Г нет ни в AVID ни в Liquid со штатными плагинами.

В аппл ведь квиктайм не глючит, больше того он и под виндосом корректно работает - переходите на QT DV - он там 1999 году уже был встроен.
Для АВИ попробуйте в Майнконцепте понастраивать, там пара галок есть YUY2 disable или UyVy disable.
Попробуйте проект с другим DV кодеком создать. Экспериментируй и побеждай Зло - это наша цель. Да будет добро!!!!
Если все в авторе делать - то эффекта нет. - там все пересчитывается

У QT DV теже проблеммы, еще и похлеще. Это на Apple все ОК и только в FCP, который также умеет в YUV оставаться, а в AE или Shake - все RGB.
Эта тема на форуме не нова - сдесь и разработчик DV кодека Майнконцепт был и признал все эти проблемы с преобразованиями YUV-RGB-YUV, но все осалось по прежнему, так как невозможно вернуть из RGB цвет в YUV без потерь.

Не в премьере мне кажется дело а маинконцепте, встроеном в премьер

Нет, проблема в Премьере и в его плагинах написанных для RGB.
Там есть два фильтра, дисолв и еще какой-то, которые с тем-же MC работают прекрасно только в YUV.

[antidemOOn]

C пересвеченым материалом - Levels + BritContr,
Еще можно скопировать этотже слой положить с Overlay(Или другим режимом) + BritContr + Opacity.
Вообще можно под кино вырулить. Тут экспериментировать надо.
По премьеру - если работать в Unconpress - не будет таких скачков. При титрах.
Вспомнил, давно монтировал передачи, DV материал, - сталкивался с титрами - премьер 6.5 были скачки яркости.
лечил установкой Panasonic DV.

[Aleksandr_Oleynik]

C пересвеченым материалом - Levels + BritContr

Это он для вещания "пересвеченный", а для всех прочих способов использования материал с полным диапазоном яркости.
Чтож ты предлагаешь, часовой фильм весь прогнать через Levels + BritContr?
Да и пробовал я - результат отвратный.

Вообще можно под кино вырулить. Тут экспериментировать надо.

Болезнью под названием под кино я не болен. Считаю это только модой. Мне больше нравится реальное, как в жизни отображение цветов и всего прочего.
И эксперементировать тут незачем, я работатаю в Liquid. а там проблем с RGB вообще нет.

По премьеру - если работать в Unconpress - не будет таких скачков.

Будут. Да и где взять этот некомпрес, если DV на касете, да и при выборе в Premier некопрес проекта - теряем тут-же внешний TV монитор.

Вспомнил, давно монтировал передачи, DV материал, - сталкивался с титрами - премьер 6.5 были скачки яркости.
лечил установкой Panasonic DV.

Это другое, хотя где-то у кого-то что-то получалось, но Premier Pro намертво прикручен к MC.


Ладно,
давайте лучше вернемся к Композитингу и RT -
Всеже, что из Композитинга уже перекочивало намертво в Монтажки и не имеет смысла с этим морочится в Композитинге, а что в ближайшее время перекочует?

[antidemOOn]

Я, не понимаю, почему если возможно решить проблнму полным пересчетом и еще и обработать динамический диапазон материала для лучшего восприятия материала не сделать этого?
1 час материала на Athlon XP 2500 чуть больше часа считается.

А функции мотажа и композинга перейдут в разряд монтажа.
Современные монтажки AVID Descreet - этому подтверждение.
т.е. не имеет смысла в дальнейшем разделять их функции.
Даже 3d объекты импортируются и текстурируются видеолеерами.

Для меня сейчас важней поддержка HD и 2K на любительском оборудовании.

А в любительском монтаже все зависит от Adobe, Canopus, Sony и др.

[Gradov_Georg]

Скачай солнышко Александра и посмотри...
Не улучшится восприятие от сжатия диапазона... (топик связаный с 601)

[Aleksandr_Oleynik]

А в любительском монтаже все зависит от Adobe, Canopus, Sony и др.

Может в любительском и от них, только в любительский монтаж HD прийдет не скоро и если и прийдет (массово) то через уже существующий и поддержаный всеми брэндами HDV.
Только вот я к любительству отношусь серьезно и считаю, что от профессионального подхода оно только выигрывает, а вот до этого самого профи подхода Premier Pro еще ОООчень далеко даже Edius, которому чуть как год, его обогнал.
Я выбираю Liquid и в Liquid 6.0 поддержка HDV имеется и без всякого железа - просто по I394.
Sony опоздала, опять опоздала и ей досталось то, что осталось.
Игроками будут только те компании, которые имеют в своем составе весь спектр и софта и железа, а это пожалуй Pinnacle, Avid, Canopus - все.
Как только Canopus перестанет писать драйвера под Premier - он перейдет окончательно в плоскость третьесортных продуктов.

Я, не понимаю, почему если возможно решить проблнму полным пересчетом и еще и обработать динамический диапазон материала для лучшего восприятия материала не сделать этого?
1 час материала на Athlon XP 2500 чуть больше часа считается.

Я разве возражаю? Где обработать? Где и как обработать корректно материал у которого диапазон цвета в YUV представлении значительно шире чем в 8 Bit RGB, а кодеков умеющих из 8 Bit YUV делать 16 Bit мы всем колхозом так и не нашли и вообще не нашди как 8 Bit YUV вогнать без потерь в RGB.

[antidemOOn]

Прочитал топик о диапазоне яркости в Премьере.
Теперь ощущаю себя любителем - вот это глубина исследования !!!
Век живи - век учись!

Нет возможности проверить - только предположения
Я думаю проблема заключается в следующем:
А не Canon, JVC DV prof или Sony DV prof у вас оборудование ?
Если да попробуйте просмотреть на дешевом Панасоник - проблема исчезла?
Использовали кодек панасоник?
Проблема исчезла?
Или через монтажку (Pinnacle DV500 - образных) на ДВ по композиту (или S-Video но не через FireWare) посмотреть - возникает ли она там?

Налицо, по всем симптомам непонятка м/у софт кодеком MC и хард Устройства отображения.

Повторюсь сейчас нет возможности проверить.

[Aleksandr_Oleynik]

antidemOOn
Так тот топик не единственный.
Ты этот читал? -
http://forum.videoed...topic=6031&st=0
Большой пользы от поиска оборудования на котором скачка по яркости не будет (в чем я сомниваюсь) мало, так как есть еще и проблема YUV-RGB-YUV, которая существенно реже возникает, так как пересвет по цветам реже снимается, но она есть.
Кроме того, все сторонние плагины также работают через RGB преобразование.
Тут проще и правильнее было-бы найти корректный и быстрый способ превращения 8 Bit YUV материала в 16 Bit RGB. Тогда те критичные места которые будут иметь стык по планам можно было-бы вот так рулить.

По поводу DV кодека от Panasonic был такой вариант, меня даже приглашали посмотреть на результат с Premier Pro. который вроди и не дает работать ни с чем, кроме MC, но я преступно не смог выбраться . А человек утверждал, что скачки по яркости исчезли ???

Сообщение отредактировано Aleksandr_Oleynik: 22 Aug 2004 - 12:42

[iliuxa]

жаль в тему позно вклинился,
я если честно не понимаю -что вообще просходит с писюками и софтом - мощности процов и объемы памяти растут как на дрожжах
пресловутый премьер еще с версии 5.1с называли реалтай -
А ГДЕ ОН ?? этот реалтайм
много лет назад в нашем училише появился первый монтажный комп
на MIRO 30, помоему просто пентиум 166 и памятью 64мег и первым сказевым хардом 4гиг так там премьер 4.0 просто летал, да если начинаешь навешивать переходы и фильтры то их приходилось посчитать, но тже не так уж и долго, и при том что у миры небыл процессора эфектов или какого либо аппаратного рендера.
а сейчас премьер про не может в реалтайме сделать простой ресайз картинки по вертикали или просто наложить каше и это уже не на 166мегагерц проце а почти в 20 РАЗ быстрее на Р4 2800 да и памяти тоже раз в 20 стало больше.
и это все простой, я бы даже сказал примитивный монтаж с парой склеек на фильм и простым ресайзом.
так что же тут говорить про композинг или 3d тем более.
я тут вспомнил старую прогу 3d studia- так она у нас еще 386 работала и видео картой в пару мегобайт так еще в реальном времени относительно сложные текстуры крутила
а щас ?? наш програмер считает что виной тому операционка
что если бы проги работали напрямую со всем комповым оборудованием то реалтайм уже давно бы был.
остается ждать когда адобы напишут свою ос.
или всетаки не зря маки на unix ядро перешли.

Сообщение отредактировано iliuxa: 22 Aug 2004 - 13:15

[Aleksandr_Oleynik]

iliuxa
Поставь Edius 2.5 и ты будешь удивлен как монтажка которой год на XP в RT рулит 4-5 слоев видео со сложными фильтрами.
Операционка тут при чем?
Это маркетологи не считают необходимым вклвдывать деньги в новые движки. Вот Canopus вложил и имеем RT монтажку без железа на PC.

[Alf_Zetas]

А человек утверждал, что скачки по яркости исчезли

это обычный рекомпресс всего материала, не имеющий отношения к конкретному кодеку

[antidemOOn]

В каждой железке c DV есть СВОЙ DV кодек - который невозможно отрулить,
только подачей материала одного рода.

Ведь 2 стандарта диапазона сущевствует.

Железки - снимают 16-255, 16-235.
16-235 - чаще в профессиональных моделях (запас для того чтобы можно было управлять пересветами и недостаточной видимостью)
16-255 - чаще в обычных моделях
Бывают и исключения.


Причем Canon JVC придерживаются диапазона 16-235, а Панасоник 16-255

Если мы монтируем материал и просматриваем Canon JVC, а монтажки и софтваре кодеки настроены 16-255 то имеем матерал
допустим так
Кусок 16-235 - переход - кусок 16-235
после просчета выглядит так
Кусок 16-235 - 16-255 - кусок 16-235
далее загоняем в камеру:
и имеем скачок.
Если камера снимает 16-255 то имеем
Кусок 16-255 - переход - кусок 16-255
после просчета выглядит так
Кусок 16-255 - 16-255 - кусок 16-255
- скачка нет.
Это видно только на оборудовании.

Как печать на принтере, под конкретную бумагу и чернила надо подгонять КАРТИНКУдля упрощения и придумали различные системы коррекции м/у мониторами и принтерами, сканерами и т.д, ведь ручек цветокорекции у принтера нет.

У киноматериала тоже есть такая технология - LUT преобразование логарифмического цвета в RGB или YUV.

RGB с YUV тождественно равны с математической точки зрения. (Однозначное соответствие)
т.е. не происходит потерь.
Но YUV в компьютере используется для сжатия динамического диапазона а не статичного.
Просто меньше бит используется для цранения цвета, без особого ущерба качества.
Это преобразование выполняестся современными FPU (технологии SSE, 3DNOW для этого и не только и создавались) процессора с большой легкостью в реальном времени, вот оно и входит в нашу жизнь.

Повторяю, к сожалению нет возможности проверить, давно с DV не работал, а камеры пока нет (другу дал на время).

[Aleksandr_Oleynik]

Ты не внимательно читал ветку, которую я указал.
Вот что показывает вектроскоп -


Самая правая колонка - это оригинал у которого есть перехлест по цвету (с точки зрения RGB цветового диапазона), крайняя левая - это то, что происходит с материалом при преобразовании в RGB, цвет поджимается в рамки доступные RGB.
А ты пишешь -

RGB с YUV тождественно равны с математической точки зрения. (Однозначное соответствие)
т.е. не происходит потерь.

Сделай хоть один RGB клип (пусть синтетический) у которого на двух верхних графиках цвет выйдет как у YUV за рамки вот тех паралелипипедов (фиг знает как они там правильно называются ).

[Gradov_Georg]

RGB с YUV тождественно равны с математической точки зрения. (Однозначное соответствие)
т.е. не происходит потерь.

НИКОГДА -- Даже в 16 битном RGB будут потери в черном... на формулу пересчета внимательно посмотри... там отрицательные значения у RGB будут -- не имеющие физического аналога.

[antidemOOn]

Вы такой YUV(справа) сигнал получаете с DV????

Я не понимаю тему разговора тогда.
Мы разговариваем о цифровых или аналоговых сигналах?

Я лично о скачках яркости в премьере.
и о цифровых сигналах и их представленни в ПО компьтера.

Боюсь я не смогу больше ничем помочь

НИКОГДА -- Даже в 16 битном RGB будут потери в черном... на формулу пересчета внимательно посмотри... там отрицательные значения у RGB будут -- не имеющие физического аналога.

В каком софте? Каком кодеке? Значит анкомпресс 8 бит хуже цифрового YUV?
т.е. цифровая видеокамера снимает лучше чем монитор может показать?
А преобразования из RGB в матрице камеры в YUV для записи и компресии учитываешь?
А то что все системы цифрового отображения RGB тоже учитываешь?
А формат YUV использовала Sony в Betacam и до них еще - это аналоговая компресия, которая, например вместе с интерлейсом позволила удешевить каналы связи для передачи изображений.
B по радиоканалам, экономить пленку в видеокасетах и т.д.
почти без ущерба качеству.
т.е. RGB - сам по себе и цифровой и аналоговый более качественен чем YUV.

[Gradov_Georg]

antidemOOn
Извини, но тут ты АБСОЛЮТНО не прав, почитай еще раз что я писал в топиках по этой теме, там все формулы приведены, причем они идентичны для любого кодека ибо ЭТО СТАНДАРТ.

С ДВ кассеты и с ДВД дисков (фирменых!) после декодирования
оригинального YUV (8-8-8) получается сигнал БЕЗ ОГРАНИЧЕНИЙ !16-235! (Хочешь верь хочешь не верь проверить можешь сам собственной программой декодируя получаемые файлы) по верху эквивалентный RGB (12-10-12), для устранения указаного мной отричательных значений для нижних значений -- надо еще и отскалить вверх...

YUV это аналоговая компресия -- это бред -- никакой АНАЛОГОВОЙ компресси тут никогда не было -- это исключительно математический прием позволяющий в теже 8*3 бита вложить БОЛЬШЕ ИНФОРМАЦИИ без потерь.

А преобразования из RGB в матрице камеры в YUV для записи и компресии учитываешь?

Извини ты начинаешь валить в кучу разные вещи без малейшего понятия... В МАТРИЦЕ НИЧЕГО НЕ ПРЕОБРАЗУЕТСЯ И НЕ КОМПРЕСИРУЕТСЯ...

Искренняя рекомендация -- если ты хотя бы с блок схемами камер не ознакомился -- причем не только ТРЕХ-МАТРИЧНЫМИ, лучше не пытайся опускаться на "физический уровень"...

Сообщение отредактировано Gradov_Georg: 22 Aug 2004 - 23:15

[Gradov_Georg]

У меня предложение к модераторам -- отправить хвост этой ветки к старым топикам по 601... -- т.к. к оригинальной теме про реалтайм в композинге это не имеет отношения...

И возможно antidemOOn там скорее прочитает о чем ломали копья... Просто опять идет одно и тоже вокруг "солнышка" которое в RGB (8-8-8) оказывается лучше чем в YUV (8-8-8)...
Может он все-таки прочитает-скачает-посмотрит, а то он опять нас пытаются затащить в дурацкий спор...

Сообщение отредактировано Gradov_Georg: 22 Aug 2004 - 23:13

[Aleksandr_Oleynik]

Вы такой YUV(справа) сигнал получаете с DV????

Именно. Да ты его сам можешь глянуть скачав фрэйм отснятого солнца.
Георгий, не поможешь ссылку найти, я не могу .

Я не понимаю тему разговора тогда.
Мы разговариваем о цифровых или аналоговых сигналах?

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

Я лично о скачках яркости в премьере.
и о цифровых сигналах и их представленни в ПО компьтера.

Ну Премьер здесь не единственный подарок, я ведь написал, так ведут себя все сторонние плагины в любой монтажке, так как они не умеют работать в YUV и все что им дают на вход преобразовывают в RGB, а потом опять в YUV.
Представление YUV цифрового сигнала в ПО компа зависит от ПО, а не от кодека, вот это и пытаемся объяснить.

В каком софте? Каком кодеке? Значит анкомпресс 8 бит хуже цифрового YUV?

В любом софте и в любом кодеке YUV цветовое пространство шире чем RGB. А кто сказал, что Анкомпрес 8 Bit не YUV? В чем пишут аналоговые камеры? Разве не в YUV?

т.е. цифровая видеокамера снимает лучше чем монитор может показать?

Какой монитор? PC монитор - Да, ХУЖЕ, так как он по определению RGB и ДиректШоу фильтра отвечающие за отображение преобразовывают YUV в RGB даже если монтажка этого не делает, а следовательно все проблеммы можно увидеть только на внешнем и желательно профи TV мониторе. А на PC мониторе картинка будет совсем другой и ничего общего с Действительностью не имеющая.

А преобразования из RGB в матрице камеры в YUV для записи и компресии учитываешь?

А зачем нам его учитывать? Мы что на него повлиять можем? Как получили с тем и работаем.

А то что все системы цифрового отображения RGB тоже учитываешь?

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

А формат YUV использовала Sony в Betacam и до них еще - это аналоговая компресия, которая, например вместе с интерлейсом позволила удешевить каналы связи для передачи изображений.

Вот это и было начало всех бед - вольность перевода так сказать RGB на матрице в YUV на касете, а потом точно также и в компе с кодеками и модулями Рэндера. Нет соответствия ни математического ни визуального у RGB и YUV, так как разные это форматы. И перевода нет корректного из одного в другой.

почти без ущерба качеству.

Вот это ПОЧТИ ты и видешь на вектроскопе, а средний график - это попытка Нормализовать YUV сигнал до разрешенного в RGB с потерей большого кол-ва информации и цвета. Но зато такой YUV сигнал без проблем хоть сто раз YUV-RGB-YUV и т.д. - цвета остаются на месте, но от оригинала записанного Камерой они очень далеки.

т.е. RGB - сам по себе и цифровой и аналоговый более качественен чем YUV.

Не знаю, не видел. Не видел я материала снятого и записанного камерой в RGB.

[antidemOOn]

2 Aleksandr_Oleynik

Вот это и было начало всех бед - вольность перевода так сказать RGB на матрице в YUV на касете, а потом точно также и в компе с кодеками и модулями Рэндера. Нет соответствия ни математического ни визуального у RGB и YUV, так как разные это форматы. И перевода нет корректного из одного в другой.

Об этом я давно и говорю.
Эта вольность - кодеки. Однако в одном и томже кодеке преобразование тождественно и однозначно.
Если есть возможность используйте в работе материал Uncompress
Важно
у панасоник DV кодек - не спроста и у сони.
Это эмуляторы HARDWARE кодека. Думаю становится понятней.
Пинакл тоже всегда писала софт версии своих кодеков, для правильной работы других программ. У кэнона не видел, хотя они самый качественный и натуральный ИМХО DV сигнал дают - HardWare на высоте, а вот софтваре где???

Не знаю, не видел. Не видел я материала снятого и записанного камерой в RGB.

Я видел. С камеры Thomson Viper HD RGB 16 бит канал идет напрямую с матриц, без преобразований. Особенно хорош для хромакея или например для искуственных рапидов.

Но ведь YUV - логарифмический сигнал, и только от кодека (или аппаратного или программного) зависит - как он преобразуется в RGB. в каждом кодеке я думаю могут использоваться разные алгоритмы пересчета.

Какой монитор? PC монитор - Да, ХУЖЕ, так как он по определению RGB и ДиректШоу фильтра отвечающие за отображение преобразовывают YUV в RGB даже если монтажка этого не делает, а следовательно все проблеммы можно увидеть только на внешнем и желательно профи TV мониторе. А на PC мониторе картинка будет совсем другой и ничего общего с Действительностью не имеющая.

У RGB определение такое если, напрмер для красного в процентах
0-пихель потушен полностью
100 - полностью включен, например красный цвет.
Однако потушен полностью - на TV - серенький, по сравнению с черной бумагой рядом, а даже белый цвет не ярче света из окна.
Динамический диапазон очень маленький, по сравнению даже с киноматериалом и фотопленкой, а не только окружающим нас миром.
Поэтому кино сканируют в логарифмические форматы типа dpx и др.
а чтобы на компе редактировать - применяют спец программы DF, Cyborg, Flame, и др. их преобразовывают в RGB через LUT - набор коэффицентов для преобразования YUV (8 10 12 бит) логарифмические в абсолютный RGB (8, 16 бит). Т.к. фильтры работают с RGB (похоже везде, во всех прогах).
Но и в АЕ с недавних пор сущ. возможность. CineonConvers.
Работая с таким материалом можно многое позволять в обработке его.
Кроме того эта пробема актуальта в 3D графике для рендера фотореалистичных изображений, только совсем недавно (относительно конечно) появилась возможность использовать HDRI а также dpx и др.
для освещения и тектурирования. Если по форумам полазить - очень много информации набрать можно.
Монитор не покажет всю полноту картинки HDRI, однако на косвенные результаты HDRI очень сильно влияет, Увеличивая достоверность восприятия.
Однако в русскоязычном очень мало уделяют внимания пока.

2 Gradov_Georg
YUV используется и в аналоге, а последнее время и в цифре. Это одна из математических моделей цвета. А разве там нет сжатия. Логарифмичекого.
Это абсолютно также, как например отличаются WAV uncompress и WAV PCM или ADPCM - я думаю Вам это знакомо. Но полюбому - PCM или YUV всегда получаются из некомпрессированого материала.
Поэтому
Там сжимают цветоразностные сигналы, а канал яркости оставляют как есть - учитывая особенности человеческого восприятия. как МП3 использует особенности восприятия слуха. Не будете Вы ведь утверждать, что МП3 лучше WAV? Хотя исходя из области применения: предача МП3 - дешевле.
Тоже самое и здесь.
И чем, же трехматричные от одноматричных в корне различаются, с точки зрения электроники, хотелось бы мне узнать????

теже 8*3 бита вложить БОЛЬШЕ ИНФОРМАЦИИ без потерь.

Позвольте спросить Вас где это Вы прочитали что в теже 8*3 и что без потерь?????

Извини, но тут ты АБСОЛЮТНО не прав, почитай еще раз что я писал в топиках по этой теме, там все формулы приведены, причем они идентичны для любого кодека ибо ЭТО СТАНДАРТ.

Хотелось бы чтобы Вы внимательнее читали мессаги, прежде чем отвечать так.
Стандарт - хорошо, когда он полнстью описывает все возможности и разрешение конфилктов.
К сожалению в жизни не все так гладко, иначе не былобы этой темы
Для примера JPG - очень похожий на DV внури - можно назвать хорошим стандартом - везде одинаково выглядит )
а про DV я не могу так сказать. вот
Если вы хотите получить максимум качества от DV и др. цифровых. Освещайте хорошо объекты съемок. Этим избежите цифровых шумов при низком освещении. И не бойтесь обрабатывать DV, делая более насыщеный диапазнон, используйте моды наложения материала самого на себя и.т.д.
Использовать фильтры шумопонижения.

Сообщение отредактировано antidemOOn: 23 Aug 2004 - 02:20

[Gradov_Georg]

И чем, же трехматричные от одноматричных в корне различаются, с точки зрения электроники, хотелось бы мне узнать????"

"Шахматкой"... и интерполяцией значений на соседние пиксели... Которая сразу делается с расчета на YUV... А НЕ НА RGB ЭТО МИНИМУМ В ОТЛИЧИИ реальной схемотехники от теории... в которой с матрицы идет RGB...

Если не знаешь что подразумевается под "шахматкой" -- то читатай тут:
http://www.photoscap...andbook/camera/

И сразу загляни сюда:
http://www.photoscap...raw/converters/

Так вот ВИДЕО КАМЕРЫ В RAW никому еще информацию не отдают...

Чем одна камера отличается от другой? Картинкой... Если есть возможность не сжимать диапазон с 12 битного цапа до RGB(8-8-8), а можно отдать эквивалентный YUV (8-8-8) (DV стандарт) который равнозначен RGB (12-10-12) то производитель БУДЕТ делать пересчет СРАЗУ В YUV...

YUV используется и в аналоге, а последнее время и в цифре. Это одна из математических моделей цвета. А разве там нет сжатия. Логарифмичекого.

Формулу в студию -- с логарифмами и первоисточником.

Полный прокол у тебя -- что называется слышал звон да не знаешь откуда он.

Я между прочим тут еще в Jan 27 2004, 16:01 выложил все формулы

YUV из RGB

Y = 0.256788 * R + 0.504129 * G + 0.097906 * B + 16
U = -0.148223 * R - 0.290993 * G + 0.439216 * B + 128
V = 0.439216 * R - 0.367788 * G - 0.071427 * B + 128

RGB из YUV

C = Y - 16
D = U - 128
E = V - 128

R = 1.164383 * C + 1.596027 * E
G = 1.164383 * C - (0.391762 * D) - (0.812968 * E)
B = 1.164383 * C + 2.017232 * D


http://msdn.microsof.../yuvformats.asp

КАК видишь НИЧЕГО КРОМЕ ЛИНЕЙНЫХ КОЭФФИЦЕНТОВ В НИХ НЕТ.
Никаких логарифмов и потерь ЗА ИСКЛЮЧЕНИЕ ОКРУГЛЕНИЯ ДО ЗАДАНОЙ ЦЕЛОЧИСЛЕНОСТИ.

Посчитать граничные значения по известным формулам думаю можешь и сам.

Попытаешься свалить на Билли -- я тебе найду ссылку на прямую из стандарта и печатных изданий советского времени.

НО ТОЛЬКО ПОСЛЕ ТОГО КАК ТЫ ПРЕДСТАВИШЬ ФОРМУЛУ ПЕРЕСЧЕТА ЦВЕТОВЫХ ПРОСТРАНСТВ С ЛОГАРИФМАМИ И ПОТЕРЯМИ.

Мой программер между прочем до сих пор вспоминает ящик пива который мы распили _с_ и за счет Александра по поводу софта написаного по данному поводу...

=========

Противоречия в СТАНДАРТЕ DV НЕТ.
Есть противоречия между ВЕЩАТЕЛЬНЫМ СТАНДАРТОМ который ограничен своими требованиями (16-235) и БОЛЕЕ ВЫСОКИМ КАЧЕСТВОМ которое ПОЗВОЛЯЕТ стандарт НОСИТЕЛЯ DV.

А так же интерпретации в софте который ДАВНО ЗАЦИКЛИЛСЯ НА RGB (8-8-8) и компьтерных видео карточках которые ТОЖЕ ЗАЦИКЛИЛИСЬ НА RGB (8-8-8) и как следствие НЕ ПОЗОЛЯЮТ УВИДЕТЬ НА ЭКРАНЕ КОМПЬЮТЕРНОГО МОНИТОРА ИСКАЖЕНИЯ ЦВЕТА.

У RGB определение такое если, напрмер для красного в процентах
0-пихель потушен полностью
100 - полностью включен, например красный цвет.


Вот это ПОЛНЫЙ АНАЛОГОВО-ГУМАНИТАРНЫЙ ОТОРВАНЫЙ ОТ РЕАЛЬНОГО ПОНИМАНИЯ ОБСУЖДАЕМОЙ ПРОБЕМЫ ПРИМЕР.
В цифре не может быть 100% и 99.999999% в цифре

при 8 битах будеть СТУПЕНЬКА в 0,390625%:
100 - 99,609375% -99,21875 -98,828125

И из-за суммирования ТРЕХ таких ступенек в результирующем
цвете будет ИСКАЖЕНИЕ, о котором мы говорим...

при 16 битах RGB будет ступенька в 0,00152587890625%
и ЭТА ступенька уже ЗА ПРЕДЕЛАМИ разрешения YUV (8-8-8)
и следовательно ОНА УЖЕ НЕ БУДЕТ ВНОСИТЬ ИСКАЖЕНИЯ
В ВИДИМЫЙ КАРТИНУ...

=============
Солнышко с горы Моисея... Из-за которого все началось...

http://www.videoedit.../16_235_Sun.avi

И топик в котором оно впервые было выложено:

http://forum.videoed...indpost&p=30917

Ну и остальные:
http://forum.videoed...indpost&p=42249
http://forum.videoed...indpost&p=43735

Сообщение отредактировано Gradov_Georg: 23 Aug 2004 - 03:17

[Aleksandr_Oleynik]

Gradov_Georg
Чуть вежлевее
antidemOOn
Не обижайся, у Георгия это не зажившая рана, так как нет решения до сих пор, а он угрохал много времени.

Предлагаю распить еще один ящик пива и решить вот эту задачу-возможность -

при 16 битах RGB будет ступенька в 0,00152587890625%
и ЭТА ступенька уже ЗА ПРЕДЕЛАМИ разрешения YUV (8-8-8)
и следовательно ОНА УЖЕ НЕ БУДЕТ ВНОСИТЬ ИСКАЖЕНИЯ
В ВИДИМЫЙ КАРТИНУ...

Осталось YUV 8 Bit конвертнуть в RGB 16 Bit и все споры законченны.
Только вот кодека или метода пока никто не предложил.

[Gradov_Georg]

Декодировать то можно... Его просто его ни одна монтажка не возмет.

За исключением АЕ в трех форматах Cineon(.cin) SGI(.rgb.sgi) Maya (.iff) и вообще сумасшедших по цене монстров завязаных на железо...

Это кстати тоже вопрос скользкий как чтобы его собственные обработки будут обходится с 16 битами -- особенно те которые НЕДАВНО куплены и включены в 6.5.

Как я уже говорил -- когда эту болезнь повышения разрядности проходили в звуке (2-3 года назад) было очень много плугинсов которые декларировали одно, а на практике было совсем другое...

Сообщение отредактировано Gradov_Georg: 23 Aug 2004 - 03:34

[antidemOOn]

Шахматкой... и интерполяцией значений на соседние пиксели... Которая сразу делается с расчета на YUV... ЭТО МИНИМУМ В ОТЛИЧИИ реальной схемотехники от теории... в которой с матрицы идет RGB...

Это понятно и из названий, но это не коренное отличие. По сути вель с матрицы снимается RGB, а уж интерполяция или дополнительные пиксели для шумопонижения - это вариации производителей. А уже затем кодируется или не кодируется.

Я между прочим тут еще в Jan 27 2004, 16:01 выложил все формулы

Я видел эти формулы. И согласен что там нет логарифмических составляющих, однако какая по Вашему разница в 4:4:4 представлении и 4:2:0 или 4:4:0.
Под YUV видимо я не то имею ввиду, т.е. наверно путаю термины.
Я имею ввиду Яркостный канал и цветоразностные по красному и синему.
Ведь DV похож на MJPEG. А там кадр почти тоже самое что JPEG.
А в Jpeg каналы цвености сильно убиты - следовательно там должны применяться логарифмические преобразования. В фотошопе можно посмотреть.
Здесь есть еще о чем поговорить короче.
Я пока не могу ссылку по использованию LUT.

ПОЛНЫЙ АНАЛОГОВО-ГУМАНИТАРНЫЙ

Это всего лишь пример для понимания что RGB зависит от УСТРОЙСТВА вывода, надо было использовать привычные 0-255 для 8 бит. Но RGB и аналог бывает если взять, к примеру, от нуля до еденицы вольт. И все равно зависит от устройства (ЭЛТ аналог, LCD цифра).
То бишь снимаем RGB - нормализуем уровни (в камере) - сжатие -загон материала - расжатие - обработка - сжатие - вывод материала - расжатие - RGB смотрим.
Если бы в YUV не преобразовывали (uncompress) - было бы макс. соответствие.
Но тогда бы цифрового видео не было. Требования по каналам передачи не выполнялись. Но сжимая - теряем большую часть цветовой информации. Кроме того, из-за требований запаса по яркости для компенсации пересвета(пришло из аналоговых систем непонятно зачем) еще и в диапазоне теряем.
Хотя средств для восстановления справедливости не дали.
А восстанавливают не все устройства. (На моем панасонике скачков при титрах и переходах небыло даже MainConcept Premiere Pro 1.0)
А вот раньше, давно когда работал с Canon XL1 Премьер 6 надо было плясать с бубном - все пересчитывать.

Сообщение отредактировано antidemOOn: 23 Aug 2004 - 06:21

[Gradov_Georg]

На компьтере да зависит и более 8-8-8 НЕТ (исключение Матроксы на ТВ выход -- 12 бит цапы).

А на ДВД и ДВ нет не зависит т.к. в 90% стоят 12 битные цапы на выходе RGB.

[Gradov_Georg]

4-4-4
4-2-2
4-2-0
4-1-1

Вот сначала и выясни для себя ЧТО ЭТИ ЦИФРЫ значат...
По той самой ссылке на Билли...

Это прорежаеся УЖЕ преобразованый цветоразностный полный массив именно то что обзывается YUV.

Только видишь ли опять проблема не в том что ДВ плохой наследник от JPEG... Проблема в том КАК НЕ ПОТЕРЯТЬ картинку которая УЖЕ СЖАТА DV и портится когда ты пытаешься с ней работать в RGB в монтажках...

[antidemOOn]

Про RGB - но ведь от него все и пляшется.
т.е. 16 бит RGB - работать на ПС с ним можно, а вот посмотреть в полную силу нельзя.
Но косвенно лучше качество на градиентах и жестких фильтрах.

А почему не зависит в DVD или DV ?
RGB не только цифровой - он еще и аналоговый и при чем тут 12 бит?

Капчюрить материал в анкомпресс, по компоненту. Из DV-CAM рекордера
Я пробовал, тут ведь из аналога YUV как раз идет. в DPS Velocity uncompress.
Надо бы ло максимум выжать. Не помогло.
или смонтировать материал и закинуть в AE, предварительно пережав в Uncompress
Как мы с jpeg поступаем???
сохраням как TGA или как слой в PSD.
Мы же у него YUV не вытаскиваем
Хотя переходим в лаб колор и видем что в каналах а и б - пикселение

Если у Вас есть YUV идем в DF и преобразовываем. Он с 1998 работал с 16 а с четвертой версии уж и 32 битах работает (общий 128 бит с альфой).

А эти цифры - читал я про них давно. Что запомнилось - чем меньше последние цифры, тем более материал по цветовому разрешению теряет, опять как то восприятием человека связано.

Но ведь кодеки же виноваты...
Софт и хард

Сообщение отредактировано antidemOOn: 23 Aug 2004 - 06:06

[antidemOOn]

Как портится картинка то?
Если эффекты применять?

А вы тут все что ли из хохляндии?
Круто.....

И еще в Cyborg если кеш выставить в YUV - то будут кешироваться ноды в этом формате - может это поможет?

У меня свои бараны - на обычном компе сделать компз в 2K, 10 бит - из скана dpx, вот я их и вкручиваю по ходу разговора. В них цвет логарифмический. Спец. левелами его приводишь в RGB и работаешь. А пресеты - LUT называются. (10 в 12, 10 в 16 и др.)
Вот я и подумал что гася диапазон цветоразностных сигналов к ним логарифм применяют.
Т.е. YUV - вы развернули в 888 (uncompress), а в DV и MPEG2 цветовые составляющие урезаны для снижения потока.
Я с таким никогда не работал.
Но помоему от YUV 888 толку никакого - кто его замуж возьмет?

Сообщение отредактировано antidemOOn: 23 Aug 2004 - 05:14

[DaLiV]

antidemOOn: posmotri specifikaciju DV - on YUV
posmotri specifikaciju videokart - oni RGB

otkroj solnishko i vivedi bez rekompressii na TV (i mozhesh sravnitj s cvetom na monitore - kotorij zavedomo proshol preobrazovanije v RGB)
sdelaj minimaljnije izmenenija hotj na 1 tochku (chto bi proshlo cherez rekompress) i posmotri raznicu na TV.

i toljko posle etogo prodolzhaj postitj ...

[Aleksandr_Oleynik]

Братцы
А вот antidemOOn еще одну проблемку высветил и я теперь крепко думаю что со всем этим делать.
Я имею в виду устойчивую тенденцию того, что через лет пять у нас не останется ни одного YUV устройства ОТОБРАЖЕНИЯ.
А если это так, то нафига, так сказать, ПОПУ ГОРМОНЬ?
Зачем мы так стараемся уберечь и сохранить то, что есть в YUV и вернуть его после всех RGB преобразований в YUV?
Скорее нам нужно научится делать так, чтобы RGB картинка на PC мониторе не отличалась от YUV на TV мониторе.
Правда, если говорим о корректном преобразовании YUV - RGB эта задача автоматом и решится.

antidemOOn
Никак до DF не могу добраться чтобы проверить его умение работать с YUV.

[Gradov_Georg]

Про RGB - но ведь от него все и пляшется.
т.е. 16 бит RGB - работать на ПС с ним можно, а вот посмотреть в полную силу нельзя.
Но косвенно лучше качество на градиентах и жестких фильтрах.

А почему не зависит в DVD или DV ?
RGB не только цифровой - он еще и аналоговый и при чем тут 12 бит?

Капчюрить материал в анкомпресс, по компоненту. Из DV-CAM рекордера
Я пробовал, тут ведь из аналога YUV как раз идет. в DPS Velocity uncompress.
Надо бы ло максимум выжать. Не помогло.
или смонтировать материал и закинуть в AE, предварительно пережав в Uncompress
Как мы с jpeg поступаем???
сохраням как TGA или как слой в PSD.
Мы же у него YUV не вытаскиваем
Хотя переходим в лаб колор и видем что в каналах а и б - пикселение

Если у Вас есть YUV идем в DF и преобразовываем. Он с 1998 работал с 16 а с четвертой версии уж и 32 битах работает (общий 128 бит с альфой).

А эти цифры - читал я про них давно. Что запомнилось - чем меньше последние цифры, тем более материал по цветовому разрешению теряет, опять как то восприятием человека связано.

Но ведь кодеки же виноваты...
Софт и хард

Про RGB - но ведь от него все и пляшется.

При ДВ камере на входе? Перестань повторять чужие рассуждия:
на одноматричной камере с "шахматки" пересчет сразу идет на "jpeg" YUV 4-2-0
который и лежит на пленке.

В трехматричной ДВ ты тоже получешь на пленке "jpeg" YUV 4-2-0

Откуда ты получишь RGB (16*3)????

По аналогу у камер и DVD проигрывателей на S-Video стоят 12 битные цапы которые дают YUV 4-4-4 которые !аналоговые! преобразователи в ТВ "превращают" в RGB (12-10-12)
== поэтому КАРТИНКА ЛУЧШЕ.

т.е. 16 бит RGB - работать на ПС с ним можно, а вот посмотреть в полную силу нельзя.
Но косвенно лучше качество на градиентах и жестких фильтрах.

Скачай солнышко и посмотри...

А почему не зависит в DVD или DV ?
RGB не только цифровой - он еще и аналоговый и при чем тут 12 бит?

Смотри выше... НА ДВД ТОЖЕ ЛЕЖИТ ЦИФРОВОМ ФОРМАТЕ YUV (8-8-8)
Схемотехнику и разрядность чипов смотри сам -- глядишь чудеса меньше пинать будут.

RGB не только цифровой - он еще и аналоговый и при чем тут 12 бит?

Остановись -- кроме прямого сигнала с матрицы и фильм-сканера RGB нигде нет.

Ни в аналоговой, ни в цифровой Бете на ленту не ложится RGB -- везде
ложится YUV... -- причина уже была приведена, за счет арифметического преобразования -- в один и тот же объем закладывается БОЛЬШЕ информации.
Преобразование АРИФМЕТИЧЕСКОЕ т.е. без потерь.
Прореживание 4-4-4 в 4-2-2, 4-2-0, 4-1-1 -- это и есть JPEG сжатие конкретного формата -- к цветовому пространству не имеющее никакого отношения...

Перезахватывать цифровой YUV по аналогу в RGB (16-16-16) 4-4-4 -- это классное предложение... Воспроизводить будет камера/магнитофон -- это понятно, а ЗАХВАТЫВАТЬ кто? Список кандитатов в студию...
Можно без учета цен -- тут заинтересованые люди без ограничения бюджета бывают.

Если у Вас есть YUV идем в DF и преобразовываем. Он с 1998 работал с 16 а с четвертой версии уж и 32 битах работает (общий 128 бит с альфой).

Единственное сообщение по теме -- надеюсь Александр проверит, работу DF -- но подозреваю про реал-тайм можно будет навсегда забыть...

Тут ЛЮБИТЕЛЬСКИЙ форум... Да и для Профи реал-тайм иногда очень нужен...

А эти цифры - читал я про них давно. Что запомнилось - чем меньше последние цифры, тем более материал по цветовому разрешению теряет, опять как то восприятием человека связано.

Угу на самом деле это было связано радиотрактом вещания, который накладывает еще большие ограниченя на мелкие детали -- которые и было принято считать ЧЕРНО-БЕЛЫМИ дабы аналоговыми цепями помехи легче загасить... -- проская цепочка конденсатор-индуктивность гасит "цветной снег" помех...

Размер "мелких объектов которые человек видит только чб" на прямую зависит от размеров устройства отображения... Во времена создания эфирного стандарта никто про проекторы и плазму не задумывался поэтому ПОМЕХОЗАЩИЩЕННОСТЬ и выбрали исходя из этого прореживание.

А теперь и в кинотеатрах буду ДВД крутить... (утрирую).
И "мелкие детали" уже должены иметь цвет... Сколько "чиста" компьютерных видеомейкеров об эти мелкие детали мордой были приложены...

Оттуда это все и пошло включая исключенные зоны за пределами 16-235 которые были выделены для синхронизации и детектировния устойчивого отдения синхро от видео...

А тут и всплыл парадокс --- ДВ и ДВД или просто в цифре синхронизация ИДЕТ ОТДЕЛЬНО, ПОМЕХ НЕТ... И этот зазор тут же был выбран для улучшения качества картинки...

А софт за исключением специализированного для кино -- БЕЗНАДЕЖНО отстал...

Но ведь кодеки же виноваты...

Во всем виноваты евреи и велосипедисты...©Анекдот

Тебе уже несколько раз сказали -- ДВ кодек на ленту ленту ложит не смотря на JPEG 4-2-0 красивую картинку в цифре с которой НЕ УДАЕТСЯ работать в компоузинговых программах БЕЗ ПОТЕРИ ЕЕ СУЩЕСТВУЮЩЕГО КАЧЕСТВА...

За исключением КИНОМОНТАЖНЫХ программ которые любителю не по силам -- не только исходя из цены их, но и из-за сопутсвующих расходов на железо+время обработки.

ТЕ налицо противостояние -- ДЕШЕВАЯ КАМЕРА ДЛЯ СЪЕМКИ ЕСТЬ, МОНТАЖКИ ЕСТЬ (ликвид эдиус... и другие кроме ПремьераПро) А КОМПОЗИНГА НЕТ.

Проблема в умах программеров композинговых программ, а не в существующих кодеках.

Тут можно Билли обвинить -- почему это он не ввел своей властью RGB 16-16-16+16алфа формат своей властью... Но думаю ему хватило пинков за MS DV кодек чтобы игнорировать эту проблему мелкого сообщества любителей видео.

DF -- Александр думаю за недельку поганяет по солнышку и огласит вердикт...

[Gradov_Georg]

Александр -- формат хранения цветоразностного материала вместо RGB это физико-математический трюк позволяющий уложить больший диапазон в тот же объем.

Если очень грубо давать аналогию
если исходная RGB плоскость с ФИКСИРОВАНОЙ БИТНОСТЬЮ НА КАНАЛ -- это резиновая поверхность с маленькими дырочками...
то YUV это таже самая резиновая поверхность но расстянутая на БОЛЬШЕЕ в 4 раза площадь... -- дырочки при этом остались АБСОЛЮТНО НА ТЕХ ЖЕ МЕСТАХ И !ТЕХ ЖЕ РАЗМЕРОВ!

Другая аналогия -- это JoinStereo сжатие -- вместо двух 16 битных каналов записывается 16+разность. Объем будет в самом худшем случае РАВНЫЙ 16+16, а на реальных сигналах всегда будет МЕНЬШЕ.

Так что YUV -- это ТРАНСОПОРТ такой же как и ZIP... Тебя ведь не смущает что нет текстовых редакторов которые читают документы на прямую из ZIP? Хотя вру -- Акробат -- практически можно считать таковым 8-).

[Alf_Zetas]

DF -- Александр думаю за недельку поганяет по солнышку и огласит вердикт...

в списке поддерживаемых железок Т3К отсутствует
а рулить YUV без внешнего мониторинга, на RGB мониторе смысла мало

[Aleksandr_Oleynik]

Попытался в Киборге -
нет моих мозгов на эту программу не хватит. Импортировать файл научился, а вот Экспортировать - фиг, даже просто закрыть этого Киборга не могу, тольк через удаление процесса .

[antidemOOn]

2 All Неужели я что так неправильно говорю?
Я высказываю мысли - а меня все время тыкают носом в солнышко,
не посмотрев которое я лох последний.
За что??????
Хочется знать побольше и поделиться с другими
Разве форум не для этого предназначен????
Извините что весь форум не прочитал - недавно я тут.
(зато номер 7000 мне нравица )
А кто вам сказал что я профессионал? Мы все учились понемногу......
У меня и образования видеоинженера нет.
Я на телевидении и не работал никогда - дома работаю.
Просто хотел помочь решить проблнму с мерцанием в при рекомпрессии.
Матрица и всех цифровых прибором - RGB, а как преобразовывается дальше на усмотрение производителя.
YUV легко преобразовывается в аналоговых сигналах, причем его разностные сигналы легло компандируются - вот он и нашел применение в жизни.
Причем я был неправ - я думал в цифре он компандируется с логарифмической составляющей, а оказывается просто меньше бит используют.
Интерлейс оттуда же - что бы передавать 50 кадров в секунду, из-за ЭЛТ
А в цифре весь этот аналоговый геммор и всплывает - попробуйте блюрнуть интерлейс картинку. Тоже и YUV.
Все новые форматы идут уже без интерлейса, т.к. прогресс не стоит на месте и ЭЛТ потихоньку отмирают. Для качества останутся RGB, без преобразований. Современные каналы и ср-ва обработки уже позволяют.
Сигнал ловят элементы по красному, синему и зеленому - иначе бы матрицы называли YUV матрицы?
Вы правы YUV транспорт, НО ИСХОДНЫЙ rgb!!!!
YUV без компресии равен RGB но, исходя из области применения он применяется для сжатия!!!, т.е.
в DV и MPEG2 его УДОБНЕЕ сжимать нежели RGB.
А цветоразностные сигнал - с потерей!!!!!!
Это зависит от сложности картинки. На сложных для YUV представления АРТЕФАКТЫ !!!!! А в МПЕГ2 добавляются еще и артефакты динамики, из-за хранения в формате разности м/у опорным и междуопорными кадрами.
Солнышко скачал, камеру еще не вернули - на тв не посмотреть.
Броад каст деисвительно грохет картинку, одноко levels помогает.
Все понятно и без него было..... Да яркое доказательство.....

При ДВ камере на входе? Перестань повторять чужие рассуждия:
на одноматричной камере с "шахматки" пересчет сразу идет на "jpeg" YUV 4-2-0
который и лежит на пленке.
В трехматричной ДВ ты тоже получешь на пленке "jpeg" YUV 4-2-0 .

По поводу матриц - у раздельных матриц меньше ошибки, т.к. фотоэлементы могут распологаться ближе, о точней ловить цвет в одном и том же пикселе.
Я больше не спорю - каждый останется при своем мнении.

Оттуда это все и пошло включая исключенные зоны за пределами 16-235 которые были выделены для синхронизации и детектировния устойчивого отдения синхро от видео...

Несовсем верно, эти запасы были для коррекции пересвеченого или недосвеченого, а не для синхронизации. В DV нет синхро в видеокадре и не нужен, пишется одельно (не помню точно как).
DV сигнал - поток цифровой! А как он записывается в файле компьтера или на кассету - это уже особенность Реализации. В DV-CAM, как известно, дополнительно прописываютя еще данные избыточности, дабы избежать подрывов пленки, но по качеству они одинаковы - что на компе, что DV-CAM, что D8 - тоже самое - miniDV или просто DigitalVideo
Однако, как видим, реализация стандарта подвела.

По аналогу у камер и DVD проигрывателей на S-Video стоят 12 битные цапы которые дают YUV 4-4-4 которые !аналоговые! преобразователи в ТВ "превращают" в RGB (12-10-12)
== поэтому КАРТИНКА ЛУЧШЕ.

Естественно - так дешевле РЕАЛИЗАЦИЯ аппаратного декодера MPEG
Но преобразование НЕ в RGB 12-10-12 а в АНАЛОГ RGB, откуда эти цифры???
Вы ведь начинаете сами себе уже противоречить.
Каждый останется при своем мнении

Откуда ты получишь RGB (16*3)????

Это частный пример (почти единичный) с видеокамерой Thomson Viper для получения максимального качества
http://www.era.ru/ca...gueEC/1_2_1.asp

Перезахватывать цифровой YUV по аналогу в RGB (16-16-16) 4-4-4 -- это классное предложение... Воспроизводить будет камера/магнитофон -- это понятно, а ЗАХВАТЫВАТЬ кто? Список кандитатов в студию...

А зачем Вам 16-16-16???? Вам что RGB 8-8-8 не хватает????
RGB 16-16-16 не оправдано в даном случае. у Вас нет YUV БЕЗ компресии в ДАННОМ случае.
Любая плата без компрессии или с компрессией Выше DV.
Или выхотите сказать что там качество выше беты будет?
Уверяю - это не так.

2 Aleksandr_Oleynik
Выход: F1 - Setting - ExitCyborg - кнопка загорится красным - надо подтвердить, - все в доках есть.
F1, F2, F3, F4 - режимы работы программы
На ней если надо подвердить что то кнопка красным загорается.
Она под планшет - правых кнопок не используется.
Есть еще действия такие - если курсором рывки как бы за экран делать - меняется подрежимы и т.д. причем влево-вправо - дополнит функции.
Вниз - Увеличить - приубрать интерфейс,
Вверх - общая информация
Что бы фильтр наложить - перетащите его в сцену(режим CREATE), пока вы файл тащите можно спокойно м/у режимами переключаться, и киньте на рабочую область,
мышкой или пеном резко вправо (какбы за пределы рабочего стола) -InsertNewEffect - что бы фильтры посмотреть в графическом виде опять резко вправо.
И рулим.

Если работать с неимпортированым в кеш материалом DV например, возможны слеты.
Или импортировать или ракалывать в TGA, TiF
хотя с QuickTime такого не замечается.

Видимо она проектировалась как единственное приложение на рабочей станции.

Вам проще в АЕ walker Effect ColorSpace использовать.
т.е. Сначала настр. в YUV > фильтры обработок какие Вам надо сделать > YUV и галку Invert не забудте. Вот вам и работа с YUV. Фильтры обработок работают YUV как с RGB (я раньше писал это)

2 Alf_Zetas
С Велосити работает хорошо, прям из проекта можно вызавать, как в премьере фильтры AE

Сообщение отредактировано antidemOOn: 24 Aug 2004 - 01:29

[Aleksandr_Oleynik]

antidemOOn
Яж написал почему Георгий горячится, хотя конечно не прав.
Проект получил - покручу, но уже только завтра, СПАСИБО.

Сообщение отредактировано Aleksandr_Oleynik: 24 Aug 2004 - 01:28

[Gradov_Georg]

А кто вам сказал что я профессионал? Мы все учились понемногу......
У меня и образования видеоинженера нет.
Я на телевидении и не работал никогда - дома работаю.

Со этого и надо начинать... Незная основ несешь чушь...

Интерлейс, зазоры 16-235 -- 4-2-2 4-2-0 -- это все производные ЭФИРНОГО вещания обусловленные задолго до появления цифры пришедшие с реализацией ВЕЩАНИЯ в цветных форматах SECAM-PAL-NTSC... ЭТО ВСЕ БЫЛО СДЕЛАНО ЗАДОЛГО ДО ЦИФРЫ.

Интерлейс оттуда же - что бы передавать 50 кадров в секунду, из-за ЭЛТ

ЭЛТ - электронно лучевая трубка - в ТЕЛЕВИЗОРАХ была подогнана под параметры вещания, а не они подогнаны под нее!

ДВ и MPEG (ДВД а не DivX!!!) -- это наследники эфирного черезстрочного вещания, а не КИНО-КОМПЬЮТЕРНОГО прогрессивного видео. Самый характерный пример -- это раздожение кадров для NTSC...

Вам что RGB 8-8-8 не хватает????

даже если считать ТОЛЬКО по максимумам с ДВ ленты

yuv(255,x,255) = R = 480.982966
yuv(255,0,0) = G = 432.492977
yuv(255,255,х) = B = 534.476001

Как видишь ни одно число не укладывается в 0-255...

Можешь пересчитать сам на 16-235 и убедиться что и в этом случае ТОЖЕ в 0-255 не уложишься...

Я высказываю мысли - а меня все время тыкают носом в солнышко,
не посмотрев которое я лох последний.
За что??????

ЗА ЭТО САМОЕ которое даже не посмотрев можно было вычислить по формулам в которые и тыкали.

Про то что лежит в минимумах с отрицательными значениями (RGB) -- я вообще не хочу распинаться т.к. я там недостающие детали в абсоютно черных частях изображения элементарной матиматикой "проявлял" и знаю, что они там есть, и если мне понадобится получить на экране недостающие детали в черном -- аля кино гамма -- я знаю где их брать - но увы этого в стандартных программах не доступно, а плугинсы множить мне пока не интересно тк. в практическом применени никто не оказался заинтересован -- К сожалению для Александра текстовые ЕДЛ оказались не пригодными к использованию, а разбираться с форматом проектов Хрома в общем случае не по остаткам моих зубов...

Поэтому даже при использовании 8 битного цап на S-Video выходе ты получишь после (YUV АНАЛОГ)-(RGB АНАЛОГ) преобразования БОЛЬШИЙ динамический диапазон цветов, чем с того же 8 битного ЦАП работающего на RGB-аналог выход... Про математику и последствия применения передискретизации там-же -- это смотреть на скаллерах и удивляться.

Ты не дружишь так же со схемотехникой камер вообще и DV в частности:

МАТРИЦА, сама по себе аналоговый элемент с дискретным считыванием т.е. каждый элемент выдает АНАЛОГОВЫЙ сигнал, который нормируется и подается на АЦП уже НОРМИРОВАНЫМ -- именно АНАЛОГОВЫМ управлением устанавливается баланс белого яркость и контрастность и протчее...

Управление АНАЛОГОВЫМ нормированием задается по уровням ПОСЛЕ ПЕРЕСЧЕТА ЗНАЧЕНИЯ ВЫДАНОГО ЦАПОМ И ПРИВЕДЕНЫХ К РЕЗУЛЬТИРУЮЩИМ ЗНАЧЕНИЯМ YUV с прореживанием 4-2-0 -- это делается с элементарной целью -- пересчет приводящий сразу к нормированым значениям носителя (ленты на ней сразу YUV) ЭКОНОМИТ РАСХОДЫ НА ПРОМЕЖУТЧНУЮ ПАМЯТЬ и устраняет не нужные просчеты промежуточных значений те самые прореженые (2-0) -- удешевляя ВСЮ НАЧИНКУ КАМЕРЫ и повышая быстроту реакции на изменение картинки падающей на матрицу...

Это для тебя матрица "черный ящик" выдающий RGB заданой битностью -- на самом деле ЭТО СЛИШКОМ ПРИМИТИВНОЕ ПРЕДСТАВЛЕНИЕ РЕАЛЬНЫХ УСТРОЙСТВ -- своего рода "сферический конь в ваккуме"...

блок схема выглядит так=
матрица аналог -- детектор превышения абсолютного значения(возврат на аналоговоге управление матрицей) -- ЦАП -- пересчет в YUV выходе за диапазноны передача изменений -- на управление матрицей ПО АНАЛОГУ.

Последний пункт -- НИ ОДНА СВЯЗКА МАТРИЦА-ЦАП мини DV никогда не были 8 битными... цифровые камеры делали сразу с 12 битными цапами т.к. без данного запаса любой пересвет вылазил бы рывком наружу... и знаменитую "зебру"-индикатор пересвета вообще не было бы возможности реализовать...
=====================


Т.к. обвинение в горячности поддержано я умолкаю, можно считать это моим последним всхлипом на данную тему.

[antidemOOn]

Со этого и надо начинать... Незная основ несешь чушь...

У вас свое видение - через YUV

МАТРИЦА-ЦАП мини DV никогда не были 8 битными

Я и не спорю. цифруется YUV так ДЕШЕВЛЕ а не ЛУЧШЕ.
Обратное преобразование - так же.
Не надо синтетикой меня утомлять. У нас проблемы со СНЯТЫМ материалом.
Если ЗИПУ дать файл из одних нулей - очень хорошо сожмет.
Но это НЕ ЗНАЧИТ что так можно сжать ЛЮБОЙ ФАЙЛ.

Ты не дружишь так же со схемотехникой камер вообще и DV в частности:
Это для тебя матрица "черный ящик" выдающий RGB заданой битностью -- на самом деле ЭТО СЛИШКОМ ПРИМИТИВНОЕ ПРЕДСТАВЛЕНИЕ РЕАЛЬНЫХ УСТРОЙСТВ -- своего рода "сферический конь в ваккуме"...

А зачем мне дружить? Я не ремонтник видеокамер. Я не говорил что с заданой битностью. Оцифровывается ведь YUV, а не RGB. в данном случае. Вы ведь сами знаете почему.
Я говорю RGB - исходен !!!! (Аналог в данном случае) И конечен!.

Попробуйте DV сигнал через конвертор FireWare -> SDI(YUV) и обратно.
А YUV обработать ни в одном комозере не удасца. Они все RGB, но позволяют работать с каналами запросто - только результат невозможно контролировать, кроме как на RGB. В Киборге кеш можно хранить в YUV, для повышения работы с дисковой системой, но считаться будет ВСЕ и в RGB (!!!! если Вы дадите на вход YUV в формате как бы RGB например AVI, но вместо каналов RGB, там будет YUV, а потом преобразуете в RGB).
В этом основное отличие композа от Монтажных программ. В композе ВСЕ расжимется в RGB и обрабатывается, а в монтажке только места с эфектами, титрами или переходами. И только на DV срабатывает эффект мерцания из-за произвольного трактования стандартов между Hardware Codec и SoftWare Codec. Далее пример.
Проблема РЕШАЕТСЯ даже в ПРЕМЬЕРЕ если видео снятое Panasonic монтировать с кодеком Панасоник. А если взять видео снятое Canon и загнать через Panasonic - опять проблема: На ленте закодировано кодеком Canon, он без изменений, с кодированое кодеком Canon передасца в компьютер и опять проблемы.

Хотя даже S-Video (если Вы через него смотрите) далеко до YUV бетакама.
Хотя есть еще много спорных моментов.

P.S. Спасибо за уроки схемотехники.

Сообщение отредактировано antidemOOn: 24 Aug 2004 - 16:13

[Gradov_Georg]

Не надо синтетикой меня утомлять. У нас проблемы со СНЯТЫМ материалом.

Как все просто...

Александр --- ты оказывается подделал "солнышко" -- в нем есть указаные мной области выходящие за RGB(8-8-8)... -- по утверждению эксперта -- "синтетика"...

А мы тут понимаешь с этой синтетикой мучаемся...

[antidemOOn]

Cyborg работает с YUV D16 в доках описано.

С солнышком все понятно - рулить левелс.
А в областях виновато не совсем корректное YUV преобразование.
Выше уже сказано.

Это я про

yuv(255,x,255) = R = 480.982966
yuv(255,0,0) = G = 432.492977
yuv(255,255,х) = B = 534.476001

синтетикой назвал.

[Aleksandr_Oleynik]

antidemOOn

Проблема РЕШАЕТСЯ даже в ПРЕМЬЕРЕ если видео снятое Panasonic монтировать с кодеком Панасоник. А если взять видео снятое Canon и загнать через Panasonic - опять проблема: На ленте закодировано кодеком Canon, он без изменений, с кодированое кодеком Canon передасца в компьютер и опять проблемы.

Ошибочка.
В Premier если выбрать кодек Panasonic DV, а не MS DV, который он предлагает для реализации TV мониторинга по FW, то просто весь материал притерпит рекомпрес, весь, а не только участки переходов и фильтров. И весь материал будет загнан в 16-235 и естественно никаких скачков не будет, только мне это совсем не нужно, я хочу сохранить оригинальное качество материала, а не убитое RGB преобразованием и подсадкой диапазона яркости.
Понимашь?

С солнышком все понятно - рулить левелс.

Да нет, не работать с таким материалом в программах выходяших за YUV и загоняющих в диапазон 16-235.

Сообщение отредактировано Aleksandr_Oleynik: 24 Aug 2004 - 21:24

[TAB]

antidemOOn

Я и не спорю. цифруется YUV так ДЕШЕВЛЕ а не ЛУЧШЕ.

При чем тут дешевле? YUV - это такое же наследие аналогового ТВ как и интерлейс, цветовое прореживание и прочее. С точки зрения затрат абсолютно без разницы какое цветовое пространство использовать и YUV для цветного ТВ был принят из соображений совместимости с ТВ черно-белым. Тогда же было принято решение сузить вдвое полосу для цветоразностных компонент, в цифровом представлении это как раз 4:2:2.

Я говорю RGB - исходен !!!! (Аналог в данном случае) И конечен!.

RGB разный бывает, в данном случае в начале был RGB 12bit. Затем YUV 8bit. И вернуть его без потерь в RGB 8 bit - задача нетривиальная.

Проблема РЕШАЕТСЯ даже в ПРЕМЬЕРЕ если видео снятое Panasonic монтировать с кодеком Панасоник. А если взять видео снятое Canon и загнать через Panasonic - опять проблема

Вопрос не в Panasonic, Canon, Sony etc. Просто DV кодеки настроены для работы с разными диапазонами в разных цветовых пространствах, напр. Panasonic Software DV codec сжимает входной диапазон RGB и для корректной работы ему нужен RGB 0-255. Sony Software DV codec ничего сжимает: если подать ему RGB 0-255 то он так и сожмет. И если такой материал декодировать Panasonic'ом - пересвет гарантирован.

Но в данном, "солнечном" случае смена кодека никак не поможет: слишком далеко вылетают значения. У меня была мысль перейти в пространство HSB и клипировать солнце по яркости, оставив Hue без изменения. Это поможет вогнать сигнал в Rec.601 и сохранить цветовой оттенок. Но в любом случае, картинка будет отличаться от оригинальной, ИМНО здесь только RGB 16bit поможет.

[Aleksandr_Oleynik]

Когда?????
Когда же наконец на касеты будет ложится RGB прогресив, а последний черезстрочны TV полетит на помойку?

[antidemOOn]

2 TAB

При чем тут дешевле? YUV - это такое же наследие аналогового ТВ как и интерлейс, цветовое прореживание и прочее. С точки зрения затрат абсолютно без разницы какое цветовое пространство использовать и YUV для цветного ТВ был принят из соображений совместимости с ТВ черно-белым. Тогда же было принято решение сузить вдвое полосу для цветоразностных компонент, в цифровом представлении это как раз 4:2:2.

Дешевле в смысле меньшая полоса пропускания -> меньше стоимость оборудования.
Но это не значит ЛУЧШЕ. прямое цифрование RGB - хорошо но дорого.
Как для аналога, так и в цифре. Посчитайте сами, если хотите.

Я, к примеру, всего 1 камеру знаю которая RGB отдает причем отдает по 2 scsi одновременно, как Вы думаете сколько она стоит?
А YUV можно запихнуть и в SDI да еще в HD формате.

RGB разный бывает, в данном случае в начале был RGB 12bit. Затем YUV 8bit. И вернуть его без потерь в RGB 8 bit - задача нетривиальная.

Если конвертация реализована правильно, яркий пример бетакам или SDI, то тривиальная.
Основная задача транспортная, Правильно передать RGB от матрицы камеры на RGB ЭЛТ телевизора.
А Вы вот все говорите что YUV содержит больше информации, а кто у нас преобразованием занимается??????
КОДЕК. он и виноват и нет. он работает по одной версии стандарта, а аппаратный по другой. - Так кто виноват?
Не в этом ли причина столь множества sw кодеков? Да причем Pinnacle, Sony и др.
т.е. производителей аппаратных версий кодеков?
Что-то я от Sony кодека для бетакама не встречал, значит он не нужен?
Значит кодеки других компаний (DPS, Pinnacle) довольно правильно работают?

2 Aleksandr_Oleynik

В Premier если выбрать кодек Panasonic DV, а не MS DV, который он предлагает для реализации TV мониторинга по FW, то просто весь материал притерпит рекомпрес

в ПРО согласен - превью не будет. Но мой Панасоник и с MC работал корректно, а в не ПРО (6.5) если кодек в системе по умолчанию Panasonic (я его для примера взял, т.к. была история с Canon и Panasonic) будет и превью и отсутствие мерцания при титрах, при условии, что было снято на камеру с тем-же кодеком. И никакого рекомпреса нетроганых участков.
Да и кроме премьера монтажек полно, которые могут работать с кодеком по умолчанию.
В Вашем случае возможно поможет DV-SDI-DeckLink или если возможность DV-CAM -> YUV -> Любая плата оцифровки.
Вы не пробовали?

Когда?????
Когда же наконец на касеты будет ложится RGB прогресив, а последний черезстрочны TV полетит на помойку?

Никогда скорее всего, мы всегда будем работать с YUV сжатием, это ведь почти бесплатное сжатие, легко реализумое как в схемотехнике так и програмно.
То что были допущены рассогласования в DV формате по преобразования не позволяет ставить крест на таком удешевлении технологий.
И только профессионалам будет доступно прямое RGB.
А любителям отойдет SDI - технология правильная и недорогая. как FireWare в свое время.

Давайте теперь обсудим следующую тему:
у меня есть устройство Panasonic со своим аппаратным кодеком,
а у друга - Canon (для примера) он снял видео и принес кассету мне.
Я ее включаю на своем панасонике - что мы видим?
Тоже ли самое я увижу что и приятель у себя дома?

Сообщение отредактировано antidemOOn: 25 Aug 2004 - 01:26

[Aleksandr_Oleynik]

В Вашем случае возможно поможет DV-SDI-DeckLink или если возможность DV-CAM -> YUV -> Любая плата оцифровки.
Вы не пробовали?

Пробовал я все, и случай это не мой, а всех, кто снимает DV, и боюсь, что не только DV.
Я что-то не верю, что от типпа камеры и встроенного в нее Дака, что-то сильно в обсуждаемой проблеме зависит. У меня есть похожие фрагменты снятые и Панасоником и Сони и Кэнаном и JVC. И чем ты этот DV материал в комп не оцифровывай, хоть по SDI, хоть по Компоненте - картинка от этого не меняется.
Повторюсь, я этот фрагмент, как наиболее показательный, пробовал захватывать всем, чем угодно.

То что были допущены рассогласования в DV формате по преобразования не позволяет ставить крест на таком удешевлении технологий.

Видел полно отснятого Бэтакамами материала с пересветом, такчто это не только DV проблема.