Выполнение просмотра hdr как процесса, согласованного с владельцем контента

Выполнение просмотра hdr как процесса, согласованного с владельцем контента

Иллюстрации

Показать все

Реферат

Область техники, к которой относится изобретение

Изобретение относится к устройствам и способам и итоговым продуктам, таким как продукты хранения, или передачи данных, или кодированные сигналы, для обеспечения улучшенной защищенной передачи изображений или видео расширенного динамического диапазона.

Уровень техники

В последнее время съемка изображений, отображение и в частности кодирование было улучшено от так называемой обработки изображений узкого динамического диапазона (LDR) (такого как классические системы, как PAL или MPEG2) до обработки изображений расширенного динамического диапазона (HDR). Освещенность в природе может варьироваться от 100 000 лк при солнечном свете, через типичную офисную или комнатную освещенность около 500 лк, до, например, 0,05 лк при четверти луны. Яркость (L) в природе варьируется от 1 миллиарда нит солнечного диска до десятков тысяч нит для ламп, до пары (десятков) тысяч нит для объектов в солнечном свете (таких как здание, края облаков или белая бумага), до сотен или десятков нит для объектов под (очень) пасмурным небом или внутри помещений, до 0,1 нит для белой бумаги под лунным светом, и т.д. Это не обязательно означает, что нужно представить эти яркости на дисплее точно таким же образом, скорее, изображение должно выглядеть художественно хорошо, означая, по меньшей мере, что должны быть приблизительно подобные различия во внешнем виде для региональных яркостей объектов при воспроизведении на экране. Следует понимать, что отображение тонов для воспроизведения на конкретном дисплее, с учетом множества дисплеев, существующих сегодня, отделено от съемки или кодирования, что приводит к трем связанным представлениям. В общем, требование того, чтобы обработка изображений HDR была способна воспроизводить, например, яркую белую стену отличным образом от соседней яркой лампы на дисплее, заключается в том, чтобы их соответствующие пиксели также были кодированы с различными значениями яркости (Y). Датчики или камеры становятся все более мощными в том, что они действительно могут точно снять большинство из этих многих различных яркостей в мире (будь то с большими глубинами скважин, по-другому экспонированными изображениями, и т.д.), и для простоты мы будем считать, что представление их собственного цвета будет линейным кодированием яркости в пределах [Lmin, Lmax] + цветовой информации. Мы может затем использовать совершенно произвольно заданное определение (в соответствии с желаемыми требованиями, конечно, такими как более поздняя возможность обработки закодированной информации, такой как местная подсветка или вопросы сжатия данных, и т.д.) для нашего кодека передачи. Наконец, эти закодированные данные (Y_C1C2 или подобные) затем снова могут быть преобразованы множеством способов в представление на стороне воспроизведения, которое мы можем для простоты приравнять к управляющим значениям, например, для цветов LCD пикселей. Дисплеи получают все более приспособленный для воспроизведения динамический диапазон, так что они могут сначала воспроизводить более яркие области, и затем одновременно или последовательно более темные области. Это позволяет размещать все эти объекты с различной яркостью вдоль отображаемой гаммы с оптимально воспроизводимыми выходными цветами.

Существенной проблемой для создателей контента является то, что, несмотря на их усилия по защите их контента, чтобы он мог быть должным образом продан вместо того, чтобы быть незаконно скопированным, все виды пиратов распространяют контент, а иногда и в больших количествах. При проектировании нового стандарта кодирования изображений, кроме взгляда на то, как представлять цвета пикселей, например, с точки зрения сжатия данных, можно иметь целью одновременно спроектировать в новых требованиях, например, защищенность стандарта. Мы придумали способ кодировать изображения HDR таким образом, что они фактически представлены как изображения LDR, плюс набор стратегий преобразования для восстановления из всей информации эффектов HDR, заключенной в исходном изображении HDR, заново. Затем мы можем несколько ослабить ограничения защиты контента. Сами данные изображения (текстура/пиксел) могут быть взломаны, но затем пират получит отвратительную картинку, не исходную оригинальную HDR градацию. Стратегия преобразования - которая в нашей инфраструктуре в одно и то же время является со-кодированием оригинального изображения уровня HDR и уже существующим применимым вариантом LDR - может быть сильно защищена, например, эта другая половина информации HDR в нашем новом кодеке может быть передана безопасно только во время просмотра (и, например, никогда не выходить за пределы аппаратных средств интегральной схемы обработки изображения, если она также перемещается по расшифрованным информационным соединениями, и удаляться из расположенной внутри интегральной схемы временной памяти как можно быстрее). Это позволит приложениям лучше контролировать, когда автор материала хочет продать HDR фильмы, например, он может продать на самом деле только функции или алгоритмы восстановления HDR.

Раскрытие изобретения

Задачи реализованы с помощью устройства (201) преобразования изображений, выполненного с возможностью получения первого изображения, содержащего сигналы яркости, которые закодированы для вывода на дисплей первого динамического диапазона желаемых корректных (например, не слишком ярких цветов лица или усиленных подсветок) яркостей, при этом первое изображение является, например, изображением расширенного динамического диапазона (HDR_PRED) для дисплея 4000 нит, или например, изображением 2000 нит опорного пика белого, если начинать от входного изображения, определенного по отношению к более высокому опорному пику белого, при этом опорный пик белого определяет, что эти сигналы яркости обозначают, в том, что воспроизводимые яркости должны быть корректными при отображении на таком экране, фактически имеющем физический опорный пик белого, скажем 6000 нит, соответствующий опорному пику белого, в соответствии с которым входные данные изображения были определены, от изображения второго динамического диапазона (LDR_CONT), например, являющегося изображением более узкого, например 100 нит, динамического диапазона в случае повышающего преобразования яркости от входного изображения более узкого динамического диапазона, но это также может быть определенное с помощью более высокого динамического диапазона входное изображение, например, сигнал уровня оригинала с опорной пиковой яркостью 6000 нит, в том случае, если отображение представляет собой отображение с понижением к оптимальному изображению, например, для дисплея с 2000 нит физического пика белого, причем получение содержит отображение тонов сигналов яркости пикселей в изображении узкого динамического диапазона в сигналы яркости пикселей изображения расширенного динамического диапазона путем применения по меньшей мере одного заданного алгоритма отображения (gam), при этом устройство преобразования изображений содержит:

- вход (204) в систему (205) передачи данных, содержащий изображение узкого динамического диапазона;

- вход (206) с защитой данных по меньшей мере к одним данным заданного алгоритма отображения (gam); и

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

Может быть желательным существование максимально трудных и неустойчивых данных заданного алгоритма отображения (gam), таким образом, чтобы к ним было трудно получить доступ, и даже при копировании варианты осуществления затруднят фактическое использование этих данных при воспроизведении, поскольку та вторая фаза также всегда присутствует. Может быть несколько сценариев, в которых второе изображение (хотя оно может содержать ту же информацию в отношении пиксельной текстуры) имеет меньшее качество в отношении воздействия на яркость воспроизведения. Например, может быть ситуация, в которой преобразуют с помощью параметров отображения изображение LDR более низкого качества (например, в соответствии с любым стандартом, который привязывает коды сигналов яркости к 100 нит пику белого) в изображение HDR более высокого качества, в котором, например, лазерные лучи могут иметь высокую яркость, отражения на воде могут оптимально искриться при воспроизведении на дисплеях более высокого динамического диапазона, и т.д. Но также когда второе изображения уже является изображением более высокого качества, например, кодированием цвета, привязанным к оригинальному опорному пику белого 6000 нит (т.е. теоретически оптимальному для воспроизведения на фактическом дисплее в 6000 нит пика белого, но не намного выше или ниже), то параметры отображения могут быть предназначены для отображения по направлению к дисплею, например, 2000 нит или около этого пика белого, и, например, вторые параметры отображения могут быть использованы для получения (более) оптимального изображения воспроизведения на дисплеях в диапазоне 2500-3500 нит пика белого, т.е. около 3000 нит. Мы опишем принципы ниже без ограничения с примером преобразования LDR в HDR, при этом специалист в данной области техники, несомненно, поймет, как затем при перестановке та же самая технология работает в другом направлении отображения цвета/яркости. Т.е. различные варианты осуществления всегда могут проверять, является ли все нормальным и авторизованным при каждом использовании данных отображения. Т.е. система делает ненормальное использование настолько трудным, если, конечно, не построить всю систему, но пользователи обычно покупают обычное устройство преобразования изображений, или дисплей, которые затем можно заставить работать строго в соответствии с авторизованным способом. Но это может даже ослабить систему в том, что в некоторых вариантах осуществления данные заданного алгоритма отображения (gam) могут быть относительно свободно доступны, но нормальность ситуации все еще проверяется устройством (201) преобразования изображений во время или перед каждым воспроизведением. Управление владельца может быть реализовано различными способами (фактически, владелец не обязательно должен быть владельцем авторских прав как таковым, поскольку управление могло было быть делегировано, но кто-то или какое-либо устройство, функционирующее для выгоды кого-либо, должно дать сигнал к старту, что данные отображения для создания HDR могут быть освобождены), но блок управления должен это проверить. Например, владелец может указать, что этот контент является бесплатным (это может быть, например, информация, которая была показана по телевидению раньше и сохранена в памяти устройства преобразования изображений), в этом случае данные преобразования могут быть извлечены из любого сервера или источника (в таком сценарии может иметься необходимость только в создании соединения к стандартному серверу компании по производству фильмов, чтобы увидеть, что название это фильма является бесплатным (и любая дополнительная информация, относящаяся к нему, может быть получена бесплатно, без какого либо дополнительного вмешательства, после этой проверки). Конечно, более сложные спецификации того, какие права имеются по отношению к содержимому изображений (например, каким серверам или объектам разрешено выдавать данные отображения) могут быть определены сервером, или, например, желаниями такого владельца, предварительно сохраненными в памяти устройства преобразования изображений из более ранней сессии связи. Например, набор правил управления может быть определен для копирования предварительно загруженных данных отображения на другое устройство пользователя в том же домене (например, при подключении для проверки на лету аспектов с устройством преобразования изображений), например, что это второе устройство также должно выполнять некоторые проверки с сервером, быть то в синхронизации со связью от устройства преобразования изображений или нет, и т.д.

Предпочтительно устройство (201) преобразования изображений имеет блок (202) управления, выполненный с возможностью получения по меньшей мере одних данных заданного алгоритма отображения через вход (206) с защитой данных во временном интервале около времени воспроизведения на дисплее изображения расширенного динамического диапазона (HDR_PRED). Удаление всех следов алгоритма отображения, даже из памяти глубоко в аппаратных средствах, может повысить защищенность для некоторых сценариев. Например, нельзя выполнить обратное проектирование любого устройства.

Предпочтительно устройство (201) преобразования изображений имеет блок (202) управления, выполненный с возможностью формирования частного защищенного соединения по сети, такой как интернет, с сервером (207) владельца художественного контента. Хотя многие системы не нуждаются в такой строгой защите, можно реализовать меры связи, избегающие перехвата, даже если другие меры делают украденные данные отображения непригодными, например, потому что они соответствуют определенному дисплею или устройству преобразования изображений.

Предпочтительно устройство (201) преобразования изображений имеет блок (202) управления, выполненный с возможностью отправки данных (id_rend) идентификации контента, идентифицирующих по меньшей мере аспекты изображения узкого динамического диапазона (LDR_CONT), такие как, например, номер версии или где оно было куплено, и при необходимости кроме этого данные идентификации устройства (201) преобразования изображений или дисплея (290) HDR или владельца этих устройств. Путем идентификации ситуации воспроизведения каждый раз, сервер 207 увеличил возможность оценивать ситуацию. Например, если внезапно пользователь и контент и/или устройства больше не соответствуют, возможно, каким-то образом контент был скопирован, и используется ненормально. Конечно, если пользователь нормально перепродал свой контент новому владельцу, он мог зарегистрировать это на сервере (но затем, например, особенности устройства могут быть проверены при первом воспроизведении этого контента, и быть перезаписаны, так что в следующий раз ситуация не будет оценена как несоответствующая).

Предпочтительно устройство (201) преобразования изображений имеет блок (202) управления, выполненный с возможностью хранения по меньшей мере одних данных заданного алгоритма отображения в памяти (270) зашифрованным способом, при этом память может быть фиксированной или съемной. Некоторые пользователи или сценарии могут не хотеть проверки нормальности при каждом воспроизведении, но, например, один раз во время так называемой инициализации контента. Это может быть выполнено посредством, например, сохранения данных отображения заново настолько защищенным способом, насколько это возможно или желаемо.

Предпочтительно устройство (201) преобразования изображений имеет блок (202) управления, выполненный с возможностью получения характеризующей информации от пользователя изображения расширенного динамического диапазона (HDR_PRED), такой как, например, персональный код или биометрическая информация. Чтобы сделать систему более защищенной, например, путем разрешения серверу 207 делать больше в углубленных исследованиях, некоторые варианты осуществления могут получать и даже работать, только если они получают различные дополнительные данные, относящиеся к ситуации воспроизведения.

Также сервер (207), обеспечивающий данные (gam, gam_enc) заданного алгоритма отображения, выполнен с возможностью приема информационного соединения, открывающегося из любого варианта устройства (201) преобразования изображений, и выполнен с возможностью выполнения проверки на основании переданных данных (id_rend) идентификации контента из устройства (201) преобразования изображений, проверяющего, нормально ли куплено или получено изображение (LDR_CONT) узкого динамического диапазона, и выполненный с возможностью вслед за этим обеспечивать данные (gam, gam_enc) заданного алгоритма отображения устройству (201) преобразования изображений. Сервер будет выполнять простую или более сложную проверку перед тем, как он освободит данные отображения для одного использования или навсегда для этой ситуации аппаратного воспроизведения. Как правило, он по меньшей мере хочет выполнить несколько простых проверок в отношении того, как контент был получен, например, он может проверить, что он содержит идентификатор, утверждающий, что этот контент был выдан массово бесплатно, или считается больше не защищенным авторским правом. Но контент также может быть распространен (например, как анонс) таким образом, что позже люди купят данные отображения для впечатления HDR. Или контент может быть ранее передан самим сервером 207, или известным сервером, и т.д. В более сложных вариантах сервер может делать больше проверок для оценки ситуации, и не обеспечивать параметры отображения, если он решает, что ситуация ненормальная, или начинать процесс, где он предлагает пользователю нормализовать ситуацию, например, дать больше информации, делающей сервер уверенным, что он является нормальным пользователем и/или сделал нормальную покупку, например, на основе заданного опросника, показанного на дисплее.

Предпочтительно сервер (207), обеспечивающий данные (gam, gam_enc) заданного алгоритма отображения выполнен с возможностью выполнения дополнительных проверок, в частности, является ли устройство (201) преобразования изображений нормальным устройством или устройством, ведущим себя ненадлежащим образом. Это может быть сделано различными способами. Например, сервер может проверить, освобождает ли он данные отображения для устройства, спроектированного хакером, имитирующего нормальное устройство (201) преобразования изображений от производителя потребительской электроники. Простой способ сделать это заключается в том, чтобы согласовать секретные коды, идентифицирующие, например, что устройство было сконструировано компанией Philips, чей код затем отправлен блоком управления. Могут быть выполнены различные дополнительные проверки, которые позволяют оценить, происходит ли общение с недавно припаянным эмулятором PCS или некоторым программным обеспечением эмуляции, например, сервер может проверить, входят ли его сообщения в определенную интегральную схему.

Предпочтительно сервер (207), обеспечивающий данные (gam, gam_enc) заданного алгоритма отображения выполнен с возможностью поддержки точной временной связи с устройством (201) преобразования изображений частичной информации данных (gam, gam_enc) заданного алгоритма отображения. Если данные отображения отправлены в интервалах, это не только позволяет делать копирование более трудным, но это также может позволить дополнительные проверки. Например, копировальное устройство может потребовать, чтобы данные отправлялись быстрее, будь то из-за того, что оно торопится, чтобы не быть раскрытым и заблокированным, или у него недостаточно деталей о согласованном временном порядке подачи данных (например, отправить данные для первых трех сцен, и затем ничего точно до начала четвертой сцены, или не позже чем 10 секунд перед четвертой сценой). Держится это в секрете или нет, не все пираты могут взять на себя труд построения системы, которая эмулирует все такие возможные аспекты, что означало бы, чтоб они могут заранее иметь содержимое для впечатления HDR для части фильма, что позволило бы им создать хорошие рекламные анонсы.

Предпочтительно сервер (207), обеспечивающий данные (gam, gam_enc) заданного алгоритма отображения выполнен с возможностью анализа ситуации на стороне воспроизведения на основании информации по меньшей мере одного аспекта из {изображения (LDR_CONT) узкого динамического диапазона, устройства (201) преобразования изображений, подключенного дисплея (290) HDR для воспроизведения изображения (HDR_PRED) расширенного динамического диапазона, оптических характеристик окружения дисплея (290) HDR и пользователя устройства (201) преобразования изображений}, и из этого определить, какие, если таковые есть, данные (gam, gam_enc) заданного алгоритма отображения отправить в устройство (201) преобразования изображений. В зависимости от всех желаемых аспектов, некоторые варианты осуществления могут отправлять различные данные, будь то по меньшей мере для отслеживания и регистрации, как распространяется нормальный и ненормальный контент, даже если обеспечение данных отображения является простым.

Аспекты нашего изобретения могут дополнительно быть реализованы посредством способа получения изображения (HDR_PRED) расширенного динамического диапазона из изображения (LDR_CONT) узкого динамического диапазона, где получение включает в себя выполнение отображения тонов сигналов яркости пикселей в изображении узкого динамического диапазона в сигналы яркости пикселей изображения расширенного динамического диапазона путем применения по меньшей мере одного заданного алгоритма (gam) отображения, при этом способ состоит в том, что:

- получают из системы (205) передачи данных изображение узкого динамического диапазона; и

- управляют доступом к данным заданного алгоритма отображения, полученным через вход (206) с защитой данных под управлением владельца художественного контента в изображении узкого динамического диапазона, и способа обеспечения данных (gam, gam_enc) заданного алгоритма отображения для преобразования изображения (LDR_CONT) узкого динамического диапазона, оптимального только для воспроизведения на LDR дисплее, в изображение (HDR_PRED) расширенного динамического диапазона, оптимального для воспроизведения на HDR дисплее, посредством источника таких данных (gam, gam_enc) заданного алгоритма отображения, соединяемых с устройством (201) преобразования изображений, имеющим блок (202) управления, выполненный с возможностью управления доступом к данным заданного алгоритма отображения под управлением владельца художественного контента в изображении низкого динамического диапазона, при этом способ выполняется посредством проверки источника в отношении того, использует ли устройство (201) преобразования изображений авторизованное изображение (LDR_CONT) узкого динамического диапазона, и при положительной проверке отправляет в устройство (201) преобразования изображений данные (gam, gam_enc) заданного алгоритма отображения.

Предпочтительно способ получения изображения (HDR_PRED) расширенного динамического диапазона создает частное защищенное соединение по сети к серверу (207) во временном интервале около времени воспроизведения на дисплее (290) изображения расширенного динамического диапазона. Особенно, если данные отображения уходят сразу глубоко внутрь (защищенных от вмешательства) интегральных схем, и уничтожаются сразу, как только они больше не нужны, можно создать очень защищенные системы. Но, конечно, можно варьировать различные компоненты и защитные меры, чтобы сделать менее строгие системы управления для данных отображения, и результирующие способы, которыми можно или нельзя создать изображение(я) HDR.

Предпочтительно способ получения изображения (HDR_PRED) расширенного динамического диапазона имеет блок (202) управления в местоположении воспроизведения изображения (HDR_PRED) расширенного динамического диапазона, который отправляет данные (id_rend) идентификации контента, идентифицирующие изображение (LDR_CONT) узкого динамического диапазона, на сервер (207). Чем больше данных передается о том, какие отличительные особенности есть на стороне воспроизведения, тем больше выводов может сделать сервер владельца контента, например, разрешая определенную информацию при определенных условиях, обеспечивая другие более подходящие данные отображения, и т.д.

Предпочтительно способ обеспечения данных (gam, gam_enc) заданного алгоритма отображения для преобразования изображения (LDR_CONT) узкого динамического диапазона, оптимального для воспроизведения на LDR дисплее, в изображение (HDR_PRED) расширенного динамического диапазона, анализирует аспекты ситуации воспроизведения как идентифицируемые из информации о той ситуации воспроизведения, принятой через блок (202) управления на той стороне воспроизведения. Как сказано, сервер может делать вывод о различных вещах на основе типов информации, которую он получает, например, пробовать отследить, как пользователь получил определенные, например, пиратские, данные (например, если появляется множество одинаковых пиратских фильмов, сервер может попробовать, может ли он также загрузить их - например, если устройство преобразования изображений (временно) сохранило веб-сайт, с которого оно загрузило фильм, оно может сообщить это серверу). Конечно, другие варианты устройства могут не хотеть хранить или раскрывать так много информации. Переданная информация может быть в большей степени определена по инициативе устройства преобразования изображений, или при запросе от сервера.

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

Краткое описание чертежей

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

На чертежах:

Фиг. 1 схематически иллюстрирует, каким образом мы кодируем изображение HDR как фактически изображение LDR, которое применимо на LDR, но с недостаточным качеством изображения на дисплее HDR, до тех пор, пока не будут получены данные алгоритма отображения нашего способа кодирования; и

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

Осуществление изобретения

Фиг. 2 схематически иллюстрирует систему воспроизведения, позволяющую воспроизводить изображение(я) HDR при повышенном контроле владельца художественного контента. У нас есть в качестве разъясненного примера устройство 201 преобразования изображений нашего заявленного изобретения в качестве, например, телевизионной приставки или любого устройства на стороне потребителя, имеющего способность обработки изображений. Читатель, конечно, понимает, что в зависимости главным образом от того, какая степень защиты является желаемой для любого конкретного применения, эта конфигурация может быть реализована различными способами. Например, в очень защищенной системе все (от блока обработки связи, обменивающегося данными с памятью, хранящей алгоритм отображения, через вход 206 с защитой данных, включающий в себя фактический блок 280 отображения тонов, и даже возможно устройства форматирования сигналов для вычисления фактических сигналов управления дисплеем) может быть включено в сам дисплей, даже в одну интегральную схему. Вход с защитой данных может в таком случае быть, например, выводом или шиной этой интегральной схемы, соединенным с антенной. Если бы хакер, например, перехватил управляющие сигналы дисплея, выходящие из некоторых выводов интегральной схемы, эта информация была бы в значительной степени непригодна для него с учетом зависимости от дисплея. Но, конечно, когда менее сильная защита является достаточной, можно отправить само HDR изображение HDR_PRED, например, в стандартизованной кодировке, либо по внутренней шине дисплея, либо как в примерном объяснении на Фиг. 1, по общей линии 291 видеосвязи, как, например, соединение HDMI. В таком случае изображение HDR может, конечно, быть зашифрованным посредством согласованного алгоритма между телевизионной приставкой и дисплеем. Действительно, устройство 201 преобразования изображений может быть даже профессиональным устройством, которое может быть, например, использовано в магазине, предлагающем услуги по продаже фильмов, или на стороне сервера системы распространения изображений/видео, и т.д.

Сначала мы с помощью Фиг. 1 объясним, как работает наш способ кодирования изображений/видео HDR. Создатель контента, например, Голливудская киностудия, сделала эталонный оригинальный HDR сигнал HDR_ORIG, который может быть закодирован, например, с помощью кодека, имеющего 20 бит линейное представление яркости. Это изображения является HDR, потому что оно имеет такой уровень, что оно будет выглядеть оптимально на дисплеях, имеющих по меньшей мере более высокую яркость (как правило, больше 1000 нит пика белого), и обычно также более глубокое черное, более высокую точность воспроизведения цветов, и т.д. (мы сосредоточимся в объяснении для простоты на составляющей сигнал яркости/яркость пикселей изображения, но конечно, как правило, система также будет выполнять отображение цветов, чтобы прийти к оптимально воспроизводимым цветам). Такой сигнал не является легко используемым на уже существующем дисплее LDR. Прежде всего, потому что он не закодирован соответствующим образом. В нашем подходе мы, как правило, кодируем изображения, а также изображения HDR, в обратной совместимости, с 10 бит или даже 8 бит яркости. Игнорируя фактические цвета пикселей, такое изображение может затем быть сжато и обработано классической системой передачи изображений, например, кодированием MPEG2, AVC, VPS, JPEG, и т.д. Но фактические цвета пикселей также важны, и здесь наш способ кодирования добавляет вторую фазу, в противном случае он бы пошел не так, как надо. Мы кодируем изображение HDR таким образом, что оно является непосредственно воспроизводимым на уже существующем дисплее, другими словами, оно имело бы вид достаточного качества изображения на таком дисплее (цвета объектов изображения приемлемо приближались бы к тому, как они бы выглядели в оригинальной сцене, или по меньшей мере наилучшим образом, который LDR дисплей может воспроизвести, учитывая, однако, важное ограничение не потерять информацию эффекта HDR изображения в этом сигнале). Мы, следовательно, применяем преобразования, которые в принципе являются обратимыми (т.е. отображение из HDR_ORIG в LDR_CONT не может быть отменено, чтобы получить HDR_PRED из LDR_ORIG путем применения обратной стратегии отображения яркости/цвета) или по меньшей мере так, что из нашего полученного LDR кодирования LDR_CONT мы можем идеально (или по меньшей мере с минимальной ошибкой) извлечь как соотнесенную оценку HDR изображения HDR_PRED, оригинальный эталонный HDR_ORIG. Это означает, что алгоритмы, выполняющие отображение яркости (и цвета) должны быть такими, чтобы не уничтожить информацию HDR. Чтобы подчеркнуть эту важный момент более точно: эта информация HDR, хотя и не является идеально воспроизводимый (например, можно втиснуть вместе некоторые более темные части изображения так, что они не будут больше различимы для глаза на LDR дисплее с низкой пиковой яркостью при определенных окружающих условиях), является все еще восстановимой путем применения алгоритмов отображения (яркости 10, 11, 12, …, 15 могут быть, например, отображены в HDR яркости 25, 30, 48, …, 100, особенно если не очень много артефактов, таких как полосатость, таким образом видимы в оценочном/восстановленном посредством отображения HDR изображении). Поэтому, хотя мы можем сказать, что LDR_CONT представляет собой изображение уровня LDR, это особое изображение в том, что оно все еще содержит - потому что мы использовали должным образом ограниченное отображение, чтобы связать HDR_ORIG и LDR_CONT - (по меньшей мере почти) всю информацию HDR эталонного HDR_ORIG.

Неприменение такого корректировочного отображения яркости даже к 8 битовому кодированию HDR_ORIG привело бы к непригодным изображениям для уже существующих устройств, поскольку они бы выглядели слишком искаженными колориметрически. Например, можно иметь темную основную сцену с яркими бликами. Поскольку HDR дисплей с высокой пиковой яркостью может воспроизводить коды пикселей с более низкой яркостью с относительно высокой выходной яркостью, можно выделить низкие пиксельные яркости всем этим пикселям (например, 0 … 10), и затем не иметь пикселей с промежуточной яркостью, и значения (250-255) для яркого света (если мы должны были закодировать уровень HDR в 8 битовом представлении). Показ этого сигнала на дисплее LDR, однако, преобразует его в двоичную форму. Все темные значения, как правило, видны как одинаково черные. Поэтому мы должны применить отображение F_TM1 яркости, которое предварительно увеличивает яркость у более темных сигналов яркости (например, 0 … 5 становится 10 … 20 с аддитивным и мультипликативным отображением), так что темная комната все еще видна на дисплее LDR, когда это кодирование HDR непосредственно воспроизводится, как если бы оно было изображением LDR. Поэтому мы кодируем изображение HDR как если бы оно было изображением LDR, или другими словами, мы кодируем изображение HDR и LDR с одинаковым представлением изображения. Но это изображение LDR_CONT не является непосредственно используемым для воспроизведения корректного эталонного HDR_ORIG на дисплее HDR. Поскольку мы, например, увеличили яркость темных частей комнаты, так что они выглядят различимо на дисплее LDR, они будут выглядеть очень ярко на дисплее HDR, и потеряют все страшное настроение по замыслу создателя контента. Решение сделать их корректными заново заключается в алгоритме FL2H обратного отображения яркости.

Этот алгоритм может быть в некоторых сценариях быть таким простым, как применение единственной гамма функции (например, HDR яркость Y_HDR=a*Y_LDR^g), даже для всей сцены или фильма, или он может быть более сложным, учитывающим также локальную цветовую оптимизацию, поскольку система воспроизведения видит внешний вид цветов относительно. Например, грубая стратегия сегментации может определить некоторые границы до наборов блоков в изображении. В зигзагообразном сканировании до того как блок (X,Y) один использует первую функцию отображения яркости, затем до того как определены границы g_l и g_h яркости LDR блока (X, Y) два, указывающие, что для областей в положениях от (X, Y) вперед, имеющих яркости пикселей между этих границ, должны рассматриваться по-разному, например, с помощью второй стратегии/алгоритма отображения яркости. Например, если LDR яркость Y_LDR, равная 128, была отображена в Y_HDR=2099 (в некотором согласованном представлении, например, 20 бит; для простоты на чертеже мы сделали диапазон восстановленных HDR яркостей плавающим [0.1] диапазоном) первой функцией отображения яркости, она теперь может быть отображена вторым алгоритмом отображения, например, Y_HDR=200. Например, можно обработать белый цвет рубашки, так что он не будет светиться слишком сильно. Позже в том же самом изображении после блока (X+K, Y+L) может быть такой же диапазон значений Y_LDR в представлении LDR_CONT изображения LDR, но это может быть очень яркая лампа. Она может быть обработана по-другому, чтобы получить очень яркие сигналы яркости Y_HDR посредством третьего локального алгоритма отображения.

В любом случае, вся информация алгоритмов отображения (функциональные параметры, числа изображений, такие как, например, времена представлений, информация определения локальной формы, и т.д) представляет собой ключ для получения оригинального эталонного HDR_ORIG заново, или по меньшей мере HDR уровня HDR_PRED, которая выглядит (очень) близко к нему. Этот уровень будет выглядеть, как предполагалось, оптимально на эталонном дисплее HDR, или любом ярком дисплее, имеющем физические характеристики, близкие к эталонному дисплею HDR, и, например, не слишком ярко в определенных положениях, или в общем в некорректном цвете.

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