ППро диапазон яркости 0-235
#151
Отправлено 28 Dec 2005 - 02:06
«Точнее говоря ведете себя как будто Премьер -- жена Цезаря и вне подозрений»
А я и не муж Премьера, чтоб за него переживать-дело не в нем, а в принципе работы с видео на ПК.
«Y=255 U=255 V=255 чему равны соотвестующие этим значениям R=? G=? B=?
Y=0 U=0 V=0 чему равны соотвестующие этим значениям R=? G=? B=?»
Ссылку в студию на наличие цифр меньше 16 и больше 235 для Y, и больше 128 для U и V.Я нигде не встречал этих цифр, кроме как у вас.
«Вместо того, чтобы закидывать меня цитатами и требовать от меня ЦИТАТ можно было просто проверить в соседней ветке опубликованые мной расчеты.»
Я ж сказал, что все прочитано и давно.
«теперь по ЛОГИКЕ:
ты ВИДЕЛ скачки яркости при монтаже одного и того же ДВ материала через переход или НЕТ.»
ДА ДА и еще раз ДА-видел.
»Если ДА то ЧТО происходит в месте где материал не изменяется и ЧТО происходит в месте ГДЕ МАТЕРИАЛ ИЗМЕНЯЕТСЯ?»
в местах изменения происходит генерация нового материала, ранее не существовавшего, в остальных местах-остается как есть.
»Если RGB движек ПРЕВЫШАЕТ по точности и охвату YUV то в месте где премьер производит преобразование видимого искажения НЕ ДОЛЖНО БЫТЬ == тогда почему оно есть?»
по той же причине, что и оцифровка винила будет звучать хуже оригинала, хотя точность «оцифровщика» несомненно выше аналогового источника.
«Перевожу, компонентный видео сигнал состоит из ТРЕХ НЕПРЕРЫВНЫХ АНАЛОГОВЫХ ФУНКЦИЙ БЕЗ РАЗРЫВОВ -- напоминает синусуоиду ...можно посчитать в 75% хуже чем если бы было 4:4:4. И спорить с этим НИКТО НЕ БУДЕТ.»
Это понятно.
«Если же тебе нужен ЭКСПЕРТ, в смысле любой парень не из этой деревни утверджающий, что он эксперт, только потому что пишет на английском... то поищи его сам или оставайся в убежденности что виноваты всякие кодеки...»
эти парни делают Кинг-Конга, а другие парни-«Мастера и Маргариту»
«PS @переводя его в ЛАБ-у Маргулиса это описано@
Solving color inconsistency with color management == это глава из Хелпа Фотошопа, однозначно рассказывающая что все преборазования в том ...охвату информации...»
Я догадался, что это из хелпа...
#152
Отправлено 28 Dec 2005 - 02:10
[b]И что ты не делай, а благородный оранжевый цвет записанный камерой в 8Bit YUV сохранить при пересчёте в 8Bit RGB - не возможно.
Но на мониторах подключенных через DVI тоже 8бит RGB, там тоже нет оранжевого? И если переключить на аналоговый вход он появится? Т.е. у монитора подключенного через DVI цветовой диапазон уже чем у подключенного через аналог?
#153
Отправлено 28 Dec 2005 - 02:16
"Цветовое пространство описываемое 8Bit YUV шире того, что заложено в 8Bit RGB и получается так, что в 8Bit YUV сигнале снятом в диаппазоне 0-255 есть цвета, которым нет соответствия в 8Bit RGB"
Пространство шире или же просто нет соответствия?Последнее понятно, потому то и цвета меняются, я бы сказал "битности" не хватает "8Bit YUV в скажем 12Bit RGB" как подтверждение ваших слов.
Это как в звуке-диапазон 44,1, 48, 96 это одно, а 12 бит, 16, 24-другое?
#154
Отправлено 28 Dec 2005 - 02:17
НУ наберись ты терпения и пригласи на пиво к себе кого-то с техническим образованием и прочти ветку -
Корректная работа с Dv (bt601, Yuv и Rgb)
И посмотри ещё раз на приведенные мной скриншоты -
#155
Отправлено 28 Dec 2005 - 02:20
видимо без этого никак
Сообщение отредактировано alexgrig: 28 Dec 2005 - 02:21
#156
Отправлено 28 Dec 2005 - 02:29
У любого компьютерного монитора сигнал RGB. что через DVI, что через RGB (он же по твоей терминологии - аналог).Но на мониторах подключенных через DVI тоже 8бит RGB, там тоже нет оранжевого? И если переключить на аналоговый вход он появится? Т.е. у монитора подключенного через DVI цветовой диапазон уже чем у подключенного через аналог?
Естественно - на комп. мониторе того оранжевого не увидеть и я ПРО ЭТО в указанной ветке писал 100 раз.
Это одна из основных причин - почему все профи работают ТОЛЬКО с контролем изображения по внешнему CRT TV умеющему отображать YUV сигнал.
"и пригласи на пиво к себе кого-то с техническим образованием... "
видимо без этого никак
А чтож ты думаешь в институте народ по шесть лет только штаны протирает .
Ну смотри -
На приведенных скриншотах (сделанных с вектроскопа встроенного в Liquid) средняя колонка обозначена как YUV Correct -
это ТОТ YUV материал, который БЕЗ никаких проблем может быть пересчитат в RGB и обратно. А потому - ЧТО Сигнал находится в границах описываемых RGB цветовым пространством (вто эти вот ромбики и прямоугольничьки).
А вот правая колонка, где сигнал за эти границы вышел - это сигнал какраз того оранжевого солнышка снятого мной, кстати, в Египте на горе Моисея . И такой сигнал при преобразовании в RGB превращается в то, что видно на левой колонке. Разницу видишь? А говоришь негде посмотреть . И как ты думаешь, такая вот разница скажется на ВИЗУАЛЬНОМ ряде?
Сообщение отредактировано Aleksandr_Oleynik: 28 Dec 2005 - 02:30
#157
Отправлено 28 Dec 2005 - 02:43
Ты просил ссылку?
Вот ссылки:
http://rapidshare.de....601-5.pdf.html
http://rapidshare.de...7/ch03.pdf.html
калькулятор и переводчик не прилагаются.
Георгий
Может эти файлики где-то прикрепить?
Сообщение отредактировано marat_k: 28 Dec 2005 - 02:48
#158
Отправлено 28 Dec 2005 - 03:16
Сообщение отредактировано Shooo: 28 Dec 2005 - 03:19
#159
Отправлено 28 Dec 2005 - 04:41
Единственный способ боротся с такими цветами - это загонять их в субъективно соответсвующий, находящийся в диапазоне. Если не особо жалко цвет - бродкаст фильтрами. Если жалко - в гистограмме зажимать черный и белый на выходе + подгонка, при необходимости. Цветовосприятие - вещь очень относительная.
Сообщение отредактировано marat_k: 28 Dec 2005 - 04:46
#160
Отправлено 28 Dec 2005 - 12:20
Matrox DigiSuite поганит материал по цвету.
Первый раз слышу, честно говоря... Если Digisuite "поганит материал по цвету", то что остается тем кто работает на DV, сразу повесится? Факт, что сигнал YUV там цифруется в 4:2:2, а потом гонится в 8 бит RGB, так с ним и работают в Премьере, который для Дигисьюта штатная монтажка, и никаких проблем, во всяком случае никто не жалуется на изменения цвета на переходах.
Хотелось бы узнать, у обладателей Decklink, есть ли подобные проблемы при использовании 8 битного RGB при захвате с YUV. Или проблемы и впрямь только в DV и его кодеках?
#161
Отправлено 28 Dec 2005 - 13:02
Сочувствую, но факт остается фактом.Первый раз слышу.
Учится снимать, и учится обрабатывать. Тем, кому лень, повеситься.то что остается тем кто работает на DV, сразу повесится?
Ага, вот именно так с ним и работают
Я не о цвете переходов, а о том, что МАТРОКС ПОГАНИТ ЦВЕТ без премьера, спид рэзора, эдита и инсайта. Конечно не жалуются, на них затем ОТК жалуется.никто не жалуется на изменения цвета на переходах.
Первый вопрос лучше задать не здесь. Второй вопрос, прости, - ГЛУПОСТЬ. Прочитай ветку, прочитай выложенные файлы, прочитай соседние ветки по этой проблеме, потом спрашивай, чтобы над тобой не смеялись.Хотелось бы узнать, у обладателей Decklink, есть ли подобные проблемы при использовании 8 битного RGB при захвате с YUV. Или проблемы и впрямь только в DV и его кодеках?
#162
Отправлено 28 Dec 2005 - 13:13
marat_k
Gradov_Georg
Господа, прошу прощения, я, кажется понял в чем фишка.
цветовое пространство YUV определяет цветность двумя компонентами-U и V, но их нельзя рассматривать изолированно друг от друга, а только вместе.Т.е. 128+128 и дают нам ~ 255.В то же время РГБпространство как бы репрезентирует цвета изолированно по каждому цвету.В идеале, комбинация U+V должна всегда бы соответствовать определенному значению отдельно R, отдельно G и отдельно B.Но в реале мы всегда сможем подобрать эквивалент одного из составляющих компонентов РГБ для комплекса UV, но в таком случае другой компонент РГБ обязательно «поплывет».Скажем красный в норме, но вылезет за диапазон 255 зеленый, зеленый в пределах 255, красный вылезет за 255.
При этом совсем необязательно, чтобы уровни U и V превышали свои максимальные значения, определяющим является их комбинация.
Я правильно понял???если нет, то боюсь-это уже клиника и мне это просто не дано от природы.
Aleksandr_Oleynik
Спасибо за скриншоты и разъяснение.
Мне было непонятно природа перехлеста уровней-ведь световой поток, преобразуясь матрицей в электрический сигнал и оцифровываясь в АЦП камеры должен был бы находится в диапазоне...
А он, если я верно понял и находится в границах, да только не тех...
marat_k
Огромное спасибо за ссылки.
калькулятор одолжил у соседа...
Gradov_Georg
так все-таки, существуют ли уровни U и V больше 128???
Если все так, то огромное спасибо за попытку наставить меня на путь истинный
#163
Отправлено 28 Dec 2005 - 13:37
Нет, тремя компонентами Y, U и V. Это цветоразностное представление. RGB - адитивное.цветовое пространство YUV определяет цветность двумя компонентами-U и V
НЕТ. Ссылки прилагаются (см. ch3.pdf). На английском, как и было спрошено. Со всеми формулами и понятиями.В идеале, комбинация U+V должна всегда бы соответствовать определенному значению отдельно R, отдельно G и отдельно B.
Остальные выводы, соответственно, мимо.
Это не клиника. Просто надо внимательно прочесть и осмыслить. Ну, посчитать чего-нибудь попробовать.если нет, то боюсь-это уже клиника и мне это просто не дано от природы.
А нафига ссылки просил? Прости, что грубовато. ch03.pdf, 3-я страница, первый абзац.так все-таки, существуют ли уровни U и V больше 128???
Сообщение отредактировано marat_k: 28 Dec 2005 - 13:38
#164
Отправлено 28 Dec 2005 - 14:00
А нафига ссылки просил? Прости, что грубовато. ch03.pdf, 3-я страница, первый абзац."
Я условно написал-имелось в виду, что не существует уровней U=255 и V =255
"цветовое пространство YUV определяет цветность двумя компонентами-U и V
Нет, тремя компонентами Y, U и V. Это цветоразностное представление. RGB - адитивное."
Понятно, что три компонента, имелось в виду, что Y влияет на скачки яркости, а дефекты цвета определяются U и V.
Т.е. преобразование U+V в РГБ определяет цветовые артефакты.
"В идеале, комбинация U+V должна всегда бы соответствовать определенному значению отдельно R, отдельно G и отдельно B.
НЕТ. Ссылки прилагаются (см. ch3.pdf). На английском, как и было спрошено. Со всеми формулами и понятиями.
Остальные выводы, соответственно, мимо."
Ладно, если я пока и не понял-запомним как аксиому.
"Это не клиника. Просто надо внимательно прочесть и осмыслить. Ну, посчитать чего-нибудь попробовать"
проблема не в лени посчитать-просто мне нужно любое явление абстрактно-ассоциативно представить, а не только математически...
Альтернативно-комбинация U+V должна всегда бы соответствовать определенному значению комбинации R+G+B-так???
"При этом совсем необязательно, чтобы уровни U и V превышали свои максимальные значения, определяющим является их комбинация."-это то хоть верное замечание.???
Сообщение отредактировано alexgrig: 28 Dec 2005 - 14:01
#165
Отправлено 28 Dec 2005 - 15:56
Aleksandr_Oleynik
Спасибо за скриншоты и разъяснение.
Мне было непонятно природа перехлеста уровней-ведь световой поток, преобразуясь матрицей в электрический сигнал и оцифровываясь в АЦП камеры должен был бы находится в диапазоне...
А он, если я верно понял и находится в границах, да только не тех...
Производителям камер НАПЛЕВАТЬ на стандарты с ними не согласованные, тем более, что 16-235 нужен ТОЛЬКО телевизионщикам.
Также им НАПЛЕВАТЬ, что производители софта не удосужелись предложить Корректный способ преобразования 8Bit YUV в RGB которое бы смогло вместить все цвета вписавшиеся в стандарт 0-255.
В теме на которую давалась ссылка - также это обсуждалось и советы типпа -
давались не раз. Только я МНОГО РАЗ видел именно Профессиональные съёмки выходящие за 16-235 по яркости и за RGB по цвету, а что говорить о любительской съёмке.Учится снимать
А вот совет -
ПРИМЕНИМ Всегда и Везде.учится обрабатывать
Его расшифровкой может быть следующее -
1. Работать в монтажках имеющих фильтра и переходы работающие в YUV.
2. Если всётаки нужно воспользоваться программами или фильтрами работающими только в RGB - то, не ставить в стык одноплановый материал обработанный в RGB и оставшийся в YUV -
это должна быть смена планов. Либо всю сцену пропускать через RGB.
3. Если материал готовится для вещания - проверять на соответствие стандарту 16-235 на всех этапах, а лучше уже на входе всё загнать в диаппазон и забыть об этой проблемме.
#166
Отправлено 28 Dec 2005 - 16:04
Понятно, допустим с выбором монтажки понятно, но как быть без композера???
видимо все же лучше "...всю сцену пропускать через RGB"
Спасибо...
#167
Отправлено 28 Dec 2005 - 16:22
Все эти мои вопросы не нашли практической заинтересованности у ПРОФИ, так как они эти проблеммы для себя раз и на всегда решили и не собираются тратить время на то, чтобы изменить создавшееся положение вещей - они ведь решение нашли .
#168
Отправлено 28 Dec 2005 - 16:29
Диапазон видимых человеческим глазом цветов знаешь? считай, что это RGB 888
диапазон прибора ночного виденья на базе преобразования ифракраного в видимый знаешь?
Так вот YUV -- сумма того и другого.
Хочешь КОНКРЕТНА ЖИВОЙ ПРИМЕР?
солнышко
х=413 y=250
Y=236 U=45 V=222
R=365 G=198 B=92
Возьми остальные кадры которые у тебя даю скачек яркости и померяй.
===========
А ты кроме композера от фирмы адоб других не знаешь? тех которые работаю и с 16 битами на цвет и вообще с логарифмическим цветом?
Как уже давно говорилось все дело в цене на билет. Киношники НИКОГДА не будут работать в ДВ формате, а аналоговым телевизионщикам важен 601 который уже даже чем RGB 8бит на канал == вот и считай это ВОДОРАЗДЕЛОМ
ТВ == самый плохой 601
Комьютерная графика = RGB 8 бит
ДВ ДВД == YUV 8 бит на канал
Кино == от 16бит (HDRI) на канал до логарифма
У каждого своя цена.
#169
Отправлено 28 Dec 2005 - 17:11
забыть не получится - есть огромное количество эффектов норовящих вылезти из диапазона (напр. Glow) - достаточно вспомнить последние новогодние огоньки на первом российском - после двух песен глаза начинают слезиться ...а лучше уже на входе всё загнать в диаппазон и забыть об этой проблемме
ЗЫ интересно как будет в этом году
#170
Отправлено 28 Dec 2005 - 21:02
В чёрных очках смотри - и всё будет ОК .ЗЫ интересно как будет в этом году
#171
Отправлено 28 Dec 2005 - 23:26
Сообщение отредактировано Shooo: 28 Dec 2005 - 23:30
#172
Отправлено 28 Dec 2005 - 23:55
"Все-равно какая-то во всем этом странность... "
Да уж...
Я тоже пока не представил себе сей процесс, надо будет порыться в физиологии цвето-восприятия-там должна быть разгадка.Проблема только в том, что насколько мне известно, не существует удовлетворительной теории по цвето-восприятию человеком.
Если что нарою-сообщу...
#173
Отправлено 29 Dec 2005 - 01:01
а откуда ты взял, что ВСЕ камеры имеют 8Bit-ные RGB матрицы и 8Bit-ую обработку?
И кто тебе сказал, что при переводе с RGB матрицы в 8Bit YUV сигнал после электроники не происходит расжатие диаппазона цветности?
И вообще - разве про это всё хоть гдето можно прочесть?
#174
Отправлено 29 Dec 2005 - 11:53
Shooo,
а откуда ты взял, что ВСЕ камеры имеют 8Bit-ные RGB матрицы и 8Bit-ую обработку?
И вообще - разве про это всё хоть гдето можно прочесть?
Я не сказал, что ВСЕ... ну судя по обрывкам инфы найденной гуглем, в бытовом классе это так, как и 8-битные процессоры, по крайней мере, у Sony... Во-первых, надо сразу оговорится, что мы подразумеваем под RGB - sRGB? Adobe RGB? Он шире, конечно (в смысле, что сделана такая привязка а CIE LAB, чтоб не пропадали нужные для полиграфии цвета), но вряд ли используется в видеокамерах (хотя в фотоаппаратах, приличного класса он есть). Остается предположить, что производители камер на АЦП матриц используют фирменные расширенные RGB, например, являющеся надмножеством для 8-битного sRGB (я бы сделал так). Но это прокатывает, естественно, при битности выше 8...
Что касается разжатия диапазона, то ведь оно новых цветов не дает, если в каком -либо стандарте RGB нет привязки к конкретному цвету из LAB, например, глубокому оранжевому, соответствущего в LAB конкретной частоте источника, то какие кривые не применяй он не появится, нужно расширение стандарта - или передвинуть цвета (как в Adobe RGB), или увеличить битность. Т.е. создать надмножество 8-битного цвета
Сообщение отредактировано Shooo: 29 Dec 2005 - 12:20
#175
Отправлено 29 Dec 2005 - 12:30
ну и что? сколько битный процессор в калькуляторе? сразу скажу 4 и что разве это означает что на нем можно считать только от 1 до 16?
ответь себе, за счет чего ты в цифро-камере можешь менять баланс белого? светофильтры внутри меняются или пересчетом за счет запаса битности сигнала с матрицы?
если бы было иначе, то гистограмма цветов была бы с дискретными провалами как только ты применишь любой сдвиг ББ относительно родного для матрицы...
#176
Отправлено 29 Dec 2005 - 14:06
@8-битные процессоры@
ну и что? сколько битный процессор в калькуляторе? сразу скажу 4 и что разве это означает что на нем можно считать только от 1 до 16?
ну пожалуй, да... оперировать 8 битный процесор и может с любой длинной операндами, лишь бы все это укладовылось в реальном времени в обработку потока
ББ, имхо, выставляется аппаратно на уровнях сигналов с АЦП (как и на аналоговых камерах), думаю это проще всего... т.е. фактичнски еще до оцифровки, и тогда прекрасно хватит и 8-битной матрицы
#177
Отправлено 10 Jan 2006 - 04:02
#178
Отправлено 10 Jan 2006 - 15:16
Когда появится == посмотрим.
#179
Отправлено 21 Mar 2006 - 18:08
Хочется вернутся к этой старой проблеме пересвета. Есть решение этой проблемы. Предложено не мной. Делается просто: Домножаем Y на 0,92. тем самым мы пиковые величины 255 возвращаем на уровни 235. Какого-то смещения цвета я не заметил. Сама операция запросто выполняется в Avisynth:
coloryuv(gain_y=-20)
#180
Отправлено 26 Apr 2006 - 17:18
Универсального решения, к сожалению, нет. Переводить весь материал в диапазон 16-235 тоже не выход. Да это поможет от пересвета, но просто убъет видео в том же AAE, который использует 0-255 и, следовательно, все эффекты будут просчитаны в этом диапазоне, а видео на их фоне просто поблекнет.
В итоге схему преобразования диапазонов придется подбирать в зависимости от схемы (последовательности) обработки видеоматериала.
Что для этого нужно:
1. Знать яркостный диапазон исходного материала;
2. Знать в каком диапазоне работает программа, в которой предполагается обработать видео;
3. Какой диапазон нужен кодеру, которым будем сжимать результат.
#181
Отправлено 05 Feb 2007 - 14:24
С альтом не просматривается, только после полного превью.
АР тут ни при чем, похожее возникало в particleIllusion и даже в QuickTime при переконвертации.
Зашел к коллеге на другой компьютер проверить как у него - нет такого эффекта.
Разница похоже в SP1 и SP2 перебил винду на SP2 сейчас о нём забыл.
Сообщение отредактировано vuec: 05 Feb 2007 - 15:50
#182
Отправлено 02 Apr 2015 - 13:08
Всем привет, немного подниму тему.
Есть проблема - ролики смонтированные в premiere при закачке на youtube теряют контраст. Я так понял это происходит из-за того, чтоPremiere экспортирует видео с диапазоном уровней 16-235 а youtube при закачке такого видео не расширяет его диапазон до 0-255. Вопрос - как быть? Есть ли возможность экспортировать видео из Adobe Premiere с уровнями 0-255?
#183
Отправлено 20 May 2015 - 22:31
Всем привет, немного подниму тему.
Есть проблема - ролики смонтированные в premiere при закачке на youtube теряют контраст. Я так понял это происходит из-за того, чтоPremiere экспортирует видео с диапазоном уровней 16-235 а youtube при закачке такого видео не расширяет его диапазон до 0-255. Вопрос - как быть? Есть ли возможность экспортировать видео из Adobe Premiere с уровнями 0-255?
премьер экспортирует ровно в тех уровнях, в которых материал
#184
Отправлено 21 May 2015 - 21:36
выгрузка в стандатный пресет в Adobe Media Encoder CC 2014 для выгрузки в ютюб приводит к потере контрастности... просто факт...
#185
Отправлено 22 May 2015 - 04:12
Возможно проблема локальная, так как у себя я разницы не заметил.
#186
Отправлено 22 May 2015 - 11:30
гм только что прогнал стандартный колорбар искажения нет... а проекта на котором "осветлило" под руками увы нет... может там был глюк
Управление цветом и Dynamic LinkЕсли управление цветом включено для проекта After Effects, композиции, просматриваемые через Dynamic Link, преобразуются с помощью цветового профиля Rec. 709. Это предотвращает сдвиги цвета или гаммы во внешнем виде этих композиций в Premiere Pro и Adobe Media Encoder.
Dynamic Link всегда допускает, что все входящие фреймы находятся в цветовом пространстве Rec. 709. В After Effects CC (июнь 2014 г.) и более ранних выпусках композиции в проектах с управлением цветом отправлялись в Dynamic Link в рабочем цветовом пространстве проекта; они не корректировались для этого допущения Dynamic Link в отношении цветового пространства Rec. 709. Такое несоответствие приводило к значительным сдвигам цвета и гаммы, если рабочим цветовым пространством проекта было не Rec. 709 или когда был включен параметр Линеаризовать рабочее пространство (Файл > Настройки проекта).
В самом последнем выпуске After Effects CC преобразование цветов применяется к композиции на последнем этапе, до того как изображения передаются в Dynamic Link для использования в Adobe Premiere Pro или Adobe Media Encoder. Таким образом достигается согласование образа композиции и цветового пространства, используемого в Dynamic Link, аналогично тому, как параметр «Вид» > «Включить управление цветами экрана» в After Effects помогает скорректировать образ для отображения на мониторе.
#187
Отправлено 07 Oct 2015 - 12:12
https://en.wikipedia.org/wiki/Rec._709
Rec. 709 coding uses SMPTE reference levels (a.k.a. "studio-swing", legal-range, narrow-range) levels where reference black is defined as 8-bit interface code 16 and reference white is defined as 8-bit interface code 235.
Interface codes 0 and 255 are used for synchronization, and are prohibited from video data. Eight-bit codes from 1 through 15 provide footroom, and can be used to accommodate transient signal content such as filter undershoots. Eight-bit interface codes 236 through 254 provide headroom and can be used to accommodate transient signal content such as filter overshoots.
In some camera systems, headroom in the signal is used to contain specular highlights, however, these "extended-range" signals are not allowed in the broadcast system and are clamped during final mastering.Bit-depths deeper than 8 bits are obtained by appending least-significant bits. Ten-bit systems are commonplace in studios. (Desktop computer graphic systems ordinarily use full bit-depth encoding that places reference black at code 0 and reference white at code 255, and provide no footroom or headroom.) The 16..235 limits (for luma; 16..240 for chroma) originated with ITU Rec. 601.[1]
Kак правильно перевести второй абзац ? Что такое footroom, headroom ?
filter undershoots, filter overshoots, to accommodate transient signal content such as filter overshoots - это что такое ?
Объясните пожалуйста. Не могу нигде найти информацию об этом.
#188
Отправлено 22 Oct 2015 - 00:14
включаем четверокласника (я англ учил в советской школе... или точнее не учил?) -- футбол -- он же football -- он же нога-шар
footroom -- foot room -- комната ноги, headroom -- head room -- комната головы...
в сочетании с графиком у которого внизу 0 вверху 255
Осталось угадать как называют диапазон от 0-16 и как диапазон от 235 до 255?
filter under shoots аналогично...
filter over shoots аналогично...
не понятная фраза -- о том что в указаных румах можно прятать все возможные другие данные "content" -- тк видео данные обязательно будут удалены соотвествующими фильтрами До попадания в вещательный тракт и после прохождения тракта ПЕРЕД передачей на отображающий элемент,
Соотвественно туда могут быть внедрены всякие данные -- без нанесения вреда отображению непосредственно видео данных...
В 601 НЕ ЦИФРОВОМ виде туда ничего затолкать было нельзя тк там были аналоговые сигналы синхронизации и попытки туда чего-нибудь впихнуть было черевато срывами синхронизации у "отображающего элемента".
0 человек читают эту тему
0 пользователей, 0 гостей, 0 скрытых пользователей