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

Изобретение относится к обеспечению улучшенной защищенной передачи изображений или видео расширенного динамического диапазона. Техническим результатом является повышение защиты контента от несанкционированного копирования. Устройство преобразования изображений выполнено с возможностью получения изображения (HDR_PRED) расширенного динамического диапазона из изображения (LDR_CONT) узкого динамического диапазона. Получение содержит отображение тонов яркости для пикселей в изображении узкого динамического диапазона в яркость пикселей изображения расширенного динамического диапазона путем применения заданного алгоритма (gam) отображения. Устройство преобразования изображений содержит вход (204) в систему (205) передачи данных, содержащий изображение узкого динамического диапазона, вход (206) с защитой данных к данным заданного алгоритма (gam) отображения и блок (202) управления, выполненный с возможностью управления доступом к данным заданного алгоритма отображения под управлением владельца художественного контента в изображении узкого динамического диапазона. 4 н. и 12 з.п. ф-лы, 2 ил.

 

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

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

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

В последнее время съемка изображений, отображение и в частности кодирование было улучшено от так называемой обработки изображений узкого динамического диапазона (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, и, например, не слишком ярко в определенных положениях, или в общем в некорректном цвете.

Теперь наша система позволяет создателю контента определить, какие алгоритмы отображения должны быть использованы для получения наилучшего внешнего вида, фактически их эталона. Они могли бы, например, определить различные алгоритмы отображения для различных дисплеев HDR, как можно представить, можно использовать различное отображение для отображения яркого солнечного внешнего вида через окно на дисплее 1000 нит по сравнению с дисплеем 25000 нит. Поэтому этим способом воспроизведение уже может быть адаптировано владельцем контента (это уже делает пиратство менее простым, поскольку пират должен собрать все версии отображения, поскольку в противном случае если он отправит неправильное отображение на новый дисплей, финальный результат может все еще быть далек от оптимального, не обеспечивая полного качественного задуманного создателем контента впечатления). И это даже позволяет создателю определять некоторые другие виды по некоторым причинам (например, можно предусмотреть более дешевый вид, который представляет собой своеобразный полу-HDR). Но кроме того, имея все это качество изображения в этом/этих алгоритмах отображения, позволяет создателю реализовывать значительно повышенную защиту контента в дополнение к существующим мерам, и следовательно получить справедливое возвращаемое значение за эти усилия. Конечно, пользователь может выбрать для просмотра версию низкого качества, установив любую пиратскую LDR версию (например, LDR_CONT, извлеченную где-либо из нормальной системы) на своем дисплее HDR, и действительно сделает так, если за впечатление HDR установлена завышенная цена. Но если он хочет оптимального качества, в соответствии с нашей настоящей системой он будет делать это при согласии владельца контента, при этом существует несколько вариантов баланса между защищенностью и простотой использования.

Теперь, возвращаясь к Фиг. 2, мы объясним некоторые из возможных вариантов осуществления. Таким образом, основное устройство 201 преобразования изображений, присущее всем вариантам осуществления, сначала имеет доступ через вход 204 к системе 205 передачи данных, содержащей изображение(я) LDR_CONT. В качестве примера мы показали купленный blu-ray диск. Интересно, что даже если пользователь купил этот диск, в некоторых вариантах осуществления он все еще не имеет полной информации для воспроизведения HDR, хотя диск утверждает, что это диск HDR (конечно, он всегда может посмотреть его в уже существующем режиме, например, на дисплее LDR). Блок управления заботится об этом, например, при каждой вставке диска. Опытному читателю понятно, что система передачи данных может иметь множество других форм, например, она может быть сетевым соединением к серверу, обеспечивающему видео. Она идентифицирует, что диск представляет собой (нормально купленный, разрешенный) диск, и может извлечь, например, уникальный идентификационный код. При необходимости, (мобильное) устройство 260 (соединенное или соединяемое) с возможностями ввода данных может использоваться для ввода, например, уникального кода, как уже в настоящее время присутствующее в программном обеспечении. Это устройство может даже усилить защитные меры, например, обмениваясь данными через сервер 207 владельца контента для подтверждения, что это устройство нормального пользователя (и блокируя устройства, которые, например, уникальным образом выделены для дисплея в случае неправильного использования, например, попытках пиратства). Блок управления обменивается данными с сервером 207 владельца контента и передает эту информацию. Этот сервер затем может определить, желает ли пользователь воспроизвести должным образом купленный продукт (например, с другого сервера владельца контента или некоторой организации, которой разрешено распространять копии, такие как, например, версии LRD на youtube), или продукт, полученный из пиратского источника 210 видео. Фактически, некоторые варианты осуществления устройства также позволили бы узаконить несоответствующий контент. Даже если пользователь получил изображение(я) из пиратского источника 210 видео (например, через другой вход 222 данных изображения), сервер может предложить заплатить за алгоритмы (gam) отображения перед просмотром, например, через мобильное устройство, которое может быть мобильным телефоном или портативным компьютером, после чего алгоритмы отображения в любом случае отправляются. Некоторые варианты осуществления блока управления и/или сервера могут дополнительно идентифицировать путем проверки того, какой LDR_CONT есть у пользователя, должны ли они отправлять ему версию более хорошего качества (например, если контент происходит из записи аналоговой камеры или некоторого воспроизведения, поведение цвета будет далеко от желаемых значений). Но если за изображение(я) HDR не было должным образом заплачено, устройство не даст требуемые алгоритмы отображения, и может даже сделать некоторые дополнительные действия, например, исследовать ситуацию и накопить системные данные, оповещая пользователя о его несоответствующем поведении, и т.д.

После получения данных алгоритма отображения, либо необработанных (gam), либо зашифрованных (gam_enc) в соответствии с некоторым согласованным алгоритмом, блок 280 отображения тонов может преобразовать изображение LDR_CONT в HDR изображение HDR_PRED и начать воспроизведение на дисплее 290. Соединение 217 может иметь различную форму, в зависимости от требований. Интересный вариант представляет собой тот, в котором устройство (например, встроенное в дисплей, такое как телевизор) запрашивает алгоритм отображения примерно в момент желаемого просмотра, т.е. в пределах временного интервала примерно во время воспроизведения. Временной интервал может быть определен системой, например, подтвержден по запросу от блока 202 управления сервером 207, и, например, быть парой дней заранее. Но в системе с более строгой защитой блок управления будет проинформирован о том, что временной интервал равен, например, 10 минутам заранее, и что в случае неиспользования, он должен удалить данные алгоритма в течение 2 часов. Поэтому в некоторых вариантах осуществления каждый раз, когда есть необходимость в воспроизведении, необходимо установить контакт с сервером 207, например, с помощью интернет соединения телевизора. Можно выполнять такие соединения с различными уровнями защищенности, например, можно даже выполнить https (протокол защищенной передачи гипертекстовой информации) соединение или подобный механизм защищенного обмена данными, снова уменьшая возможности взлома где-либо. Параметры алгоритма отображения также могут вместо того, чтобы быть предварительно загруженными до начала фильма, быть загруженными для сетей 207 с малой задержкой немного раньше, чем они необходимы, например за пару секунд или минут до того, как меняется сцена, нуждающаяся в другой стратегии отображения. Некоторые варианты осуществления устройства 201 преобразования изображений могут быть выполнены так, что они не только нуждаются в этих данных отображения правильно синхронизированным способом, но также через некоторое (возможно даже заданное сеть-сервер) соединение, делая взлом очень трудным (поскольку нужны не только различные алгоритмы отображения, но также необходимо выдать их через дополнительное пиратское устройство, которое эмулирует корректное получение; и поскольку может быть необходимо, чтобы оно было соединено с выводом(ами) интегральной схемы внутренним образом, вместо того, чтобы быть присоединенным, например, к шине USB, такие хорошо защищенные варианты осуществления могут быть слишком сложными для среднего пользователя для реализации в больших количествах). Специалист в данной области техники понимает различные способы, которыми корректная временная синхронизация изображений LDR и отображения может быть реализована, например, хранилище данных изображений и/или сигнал (например, BD диск, сигнал из карты памяти или удаленного видеосервера, и т.д.) может содержать временные коды, идентифицирующие и запрашивающие «только новые» или определенные алгоритмы отображения, при этом сервер 207, как правило, знает (например, из переданных временных отметок представления), какие данные отображения нужны, или сервер может управлять всем этим автономно, и активно отдавать указания блоку управления и/или выдать ему новые алгоритмы отображения. Так ряд вещей может происходить через блок управления. Он может, например, запросить новый вид стратегии отображения после того, как пользователь приглушил свет в комнате просмотра, или, с другой стороны спектра, он может просто отобразить сообщение, что просмотр HDR не возможен или не разрешен, и, как правило, предложить шаги, которые должны быть предприняты, чтобы получить в конечном итоге воспроизводимое изображение HDR. Поэтому управление владельца контента может быть таким же простым, как простое «продолжайте», как правило, реализованное в виде некоторых из множества возможных стратегий обеспечения данных алгоритма отображения в блок управления, или оно может влечь за собой сложную ситуацию определения, в которой сервер 207 анализирует детали ситуации просмотра пользователя (такие как, например, освещение в его комнате просмотра), и затем предлагает оптимизированные в реальном времени алгоритм(ы) отображения для оптимального воспроизведения на его дисплее HDR. Кроме того, в различных вариантах осуществления блок управления может отправлять (самостоятельно, но, как правило, по намерению сервера 207), в зависимости также от того, что согласовано на основе таких соображений, как, например, неприкосновенность частной жизни, ряд значений данных на сервер 207. Например, блок управления может быстро проанализировать видео, и проверить, является ли статистическое распределение яркости в LDR_CONT таким, каким оно подразумевается быть (в одном или одном из нескольких существующих вариантов контента изображения) или он может анализировать водяной знак в данных, чтобы получить больше информации об источнике контента (например, был ли он скопирован из распределения определенному кинотеатру). Он может читать административную информацию, хранящуюся или введенную в систему, такую как адрес от поставщика, и т.д. Когда это желательно, различные способы могут использоваться для идентификации покупки с настоящим воспроизведением, например, блок управления может спросить пользователя, была ли покупка фильма HDR (или фактически LDR_CONT) сделана кредитной картой (или просто напомнить ему, что была), и спросить последние четыре цифры, что сложно сделать для хакера, если только он тоже не отслеживал эту покупку, или это была его собственная покупка (но по меньшей мере это предотвращает кражу чьей-то еще копии, чей просмотр может быть отключен для обычного пользователя в некоторых системах). Наши варианты осуществления, в то же время ограничивающие использование фильма (например, может не присутствовать нормальный выходной сигнал, и устройство 201 может прекратить функционировать, если его корпус открыт или изменен), делают затруднительным делать что-либо, кроме самопросмотра, даже если пират маскируется как нормальный пользователь, и регулярно платит за одну копию. Все виды дополнительной информации могут быть сохранены, идентифицируя, как этот контент (только тот, который должен быть воспроизведен) был получен, что может привести к странным результатам, если он скопирован, например, путем отслеживания где-то некоторого сигнала. Например, может быть зарегистрировано, что нормально купленный LDR_CONT должен находиться вместе с определенным дисплеем (или несколькими дисплеями, позволяя, например, просмотр в месте известного и зарегистрированного/идентифицируемого друга), и не в другом месте. Во множестве сценариев не будет требоваться, например, чтобы пользователь представил какие-либо детали покупки (например, номер кредитной карты), поскольку система будет конфигурирована таким образом, что достаточно ясно, что контент был куплен нормально, но варианты осуществления могут быть полезны в других сценариях.

Но во-вторых, сервер 207 может получить (как правило, при явном согласии от пользователя) информацию от самого пользователя, например, его имя, сохраненное в памяти в устройстве преобразования изображений дисплея 290 HDR, или пароль для запуска системы, или чтобы пользователь вставил смарт-карту, и т.д. Усовершенствованные устройства 201 могут установить, по меньшей мере, подлинность пользователя, например, путем использования сканера отпечатков пальцев, который уже может быть встроенным. Блоку управления нет необходимости фактически отправлять все характеристики этого отпечатка пальцев на сервер 207, но только сводку данных, такую как «обычный_зритель_использует_систему». Но более усовершенствованные системы могут отслеживать, что если кто-то смотрит фильм больше, чем, например, 20 раз, он может быть пиратом, чем кем-либо, кто на самом деле любит этот фильм, особенно если одна и та же версия (если мелкий модуль идентифицирован на пользователя или группу пользователей) просматривается в других физических местоположениях, и даже также в одно и то же время. Т.е. сервер 207 может реализовать некоторые стратегии отслеживания в некоторых вариантах осуществления помимо обеспечения в большей степени защищенного распределения данных, и запросить необходимые данные из устройства 201. В-третьих, сервер может получить все виды информации, касающейся деталей системы воспроизведения (например, пиковая яркость или электро-оптическая передаточная функция дисплея, характеристики окружающего освещения), и т.д. Упомянутые выше данные, как правило, предназначены для регистрации и/или разрешения воспроизведения HDR (или отслеживания аспектов того, что происходит не в соответствии с нормальным использованием системы), тогда как третий вид параметров может помочь в оптимизации впечатления от воспроизведения HDR путем передачи наиболее подходящих параметров алгоритма отображения, если существует несколько вариантов (которые даже могут быть вычислены непосредственно в процессе). Конечно, в-четвертых, все виды информации могут быть переданы в зависимости от того, является ли сервер 207 или устройство 201 нормальными, например, чтобы предотвратить эмуляцию пиратским поставщиком видео всего сервиса проверки владельца контента, и это может быть сделано, например, путем жесткого кодирования ряда интернет адресов в устройствах 201.

Другие варианты осуществления с меньшей защитой могут обеспечить пользователям большую свободу. Хотя многие устройства, такие как, например, телевизоры, могут иметь доступ по меньшей мере к некоторой сети, такой как, например, интернет, может быть так, что некоторые пользователи (например, некоторые менее опытные) могут просто желать некоторого итогового контента, например, на BD, они также хотят воспроизводить (в HDR) на системе отображения, которая не имеет сетевого соединения (например, на заднем сидении машины). Кроме того, некоторые варианты осуществления могут позволять сохранять алгоритмы отображения в некоторой памяти 270 (либо глубоко в устройстве 201 или дисплее, либо в съемной, переносной памяти), например, на записываемой части BD или защищенной карте памяти, как правило, конечно, в сильно зашифрованном виде. Например, могут быть использованы ключи на основе паролей, или даже время загрузки данных алгоритма. Типичная система может подключать, например, переносной дисплей (либо фактически через присутствие на подключенном кабеле, либо путем обмена данными позже через карту памяти) к устройству 201 преобразования изображений, и затем определять стратегию шифрования для диска и переносного дисплея в это время. Например, данные алгоритма отображения на диске могут быть зашифрованы на основе сгенерированного ключа, который находится только в аппаратных средствах этого переносного дисплея. Обладание уникальным ключом для определенного дисплея (и средствами управления и генерирования (например, ключ может быть частично сгенерирован на основе идентификатора дисплея)) снова делает взлом очень трудным, поскольку даже если скопировать данные отображения, они могут быть непригодными для использования. В зависимости от того, насколько сильна защита данных, как правило, владелец контента (обычно в соглашении с производителем устройства и, надо надеяться, некоторым представлением пользователей) может хотеть, чтобы система могла работать, только если введен корректный пароль пользователя (в противном случае совместимый дисплей HDR или устройство преобразования изображений даже не читает, поскольку не может использовать, данные алгоритма отображения), но с другой стороны спектра, можно также считать систему достаточно защищенной с минимальным шифрованием данных алгоритма отображения (или для некоторой аппаратной конфигурации даже без шифрования для нормальных пользователей, например, если параметры в единственное время инициализации записаны непосредственно во внутреннюю память переносного дисплея, как правило, с идентификатором изображения(ий)/фильма, к которому они применяются). Таким образом, это действие регуляризации может произойти один раз, например, в момент, когда пользователь покупает диск, он немедленно регуляризует его дома, где у него доступны все необходимые технические компоненты (и записанные пароли или что-либо еще). Некоторые пользователи могут, однако, не хотеть этого, например, когда они покупают контент на каникулы, который они хотят немедленно посмотреть, или когда они имеют недостаточную систему (например, нет интернета дома), и т.д. Для этих пользователей вариант осуществления устройства преобразования изображений может быть помещен в магазине. Во время покупки регуляризуют, например, «пустой» BD (т.е., тот, который содержал только LDR кодирование LDR_CONT, но на данные алгоритма отображения), что может быть сделано поставщиком магазина с помощью его устройства, соединяющегося с сервером 207, и сохраняющим данные алгоритма, например, на записываемый сектор переносной памяти, содержащей фильм. Такой вариант осуществления устройства 201 может, например, быть соединен/соединяемым со вспомогательной клавиатурой для ввода личного кода пользователя, и т.д. Некоторые варианты могут запрашивать некоторую идентификацию пользовательского аппаратного обеспечения, например, телевизор записывает свой зашифрованный код на карту памяти, которая присоединена к устройству 201 в магазине. Предпочтительно, если магазин немедленно отправляет некоторую информацию о покупке на сервер 207, это может помочь в регуляризации второй раз (надо надеяться, в доме пользователя, а не снова в магазине), например, если пользователь забыл свой пароль.

Для простоты мы назовем алгоритм gam, поскольку нет путаницы с данными, определяющими его (например, по меньшей мере один коэффициент малой мощности или программный код, предписывающий какое-либо преобразование цвета, и т.д.). Также опытный читатель поймет, что блок 202 управления может содержать (или быть соединенным с) различные другие блоки, такие как блок связи, выполненный с возможностью применения требуемого протокола связи, выполнения форматирования и защиты данных, и т.д., или блок пользовательского интерфейса, позволяющий обмениваться данными с пользователем и, например, показывать окно для защищенного ввода финансовой информации на его переносном дисплее для регуляризации ненормального LDR_CONT, и т.д. Также должно быть ясно, как обработка изображений (отображение цветов (DCT), (де)компрессия, и т.д.) может быть выполнена, и нет необходимости углубляться в детали управления дисплеем, и т.д. Следует отметить, что, конечно, устройство 201 может соединяться с различными серверами, чтобы позволить нескольким владельцам, согласованно или независимо, определять данные отображения для субэлементов, например, фильма или программы. Можно, например, подумать о материале, в котором материал другого провайдера перемежается или даже, хотя некоторый Голливудский продюсер может владеть фильмом, отображение для графики в некоторых сценах может быть передано непосредственно с сервера студии специальных эффектов, тогда как другие данные отображения могут, например, приходить из централизованного сервера Disney или Paramount. Должно быть ясно, чтоб мы имеем в виду технически с отображением яркости представления цвета от первого ко второму. Яркость представляет собой технический код Y=[0,255], который имеет связь через кривую определения тона с финальной яркостью, либо, например, как снятой с помощью камеры, либо относящейся к воспроизведению дисплеем. Различные альтернативные технические реализации могут существовать, например, в линейном представлении эта третья цветовая координата может быть самой яркостью, но достаточно технически опытный читатель должен прекрасно понимать, что это такое (для простоты мы сделаем вид, что диапазоны яркости представляют собой числа с плавающей точкой (за исключением LDR_CONT, который, как мы предполагаем, представляет собой классические 8 бит с гаммой 2.2 и т.д.), но, конечно, можно также, например, выполнить отображение из примерно 10 бит примерно в 15 бит разрешения яркости).

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

Должно быть понятным специалисту в данной области техники из нашего представления, какие компоненты могут быть необязательными улучшениями и могут быть реализованы в комбинации с другими компонентами, и как (факультативные) этапы способов соответствуют соответствующим средствам устройств, и наоборот. Тот факт, что некоторые компоненты раскрыты в изобретении в определенной связи (например, на одной фигуре в определенной конфигурации) не означает, что другие конфигурации невозможны в качестве вариантов осуществления при тех же изобретательских взглядах, как описано в данном документе для патентования. Кроме того, тот факт, что по практическим причинам только ограниченный спектр примеров был описан, не означает, что другие варианты не могут подпадать под объем формулы изобретения. Фактически, компоненты изобретения могут быть реализованы в различных вариантах по любой цепочке использования, например, все варианты стороны создания, такие как кодер, могут быть похожими или соответствовать соответствующим устройствам на стороне потребления декомпозированной системы, например, декодеру, и наоборот. Несколько компонентов вариантов осуществления могут быть закодированы как определенные данные сигнала в сигнале для передаче или дальнейшего использования, такого как координация, в любой технологии передачи между кодером и декодером, и т.д. Слово «устройство» в этой заявке используется в его самом широком смысле, а именно группа средств, позволяющих реализацию определенной цели, и может, следовательно, например, быть (маленькой частью) интегральной схемой, или выделенным прибором (таким как прибор с дисплеем) или частью сетевой системы, и т.д. «Установка» или «система» также предназначена для использования в самом широком смысле, поэтому она может содержать помимо прочего единое физическое, покупаемое устройство, часть устройства, набор (частей) взаимодействующих устройств, и т.д.

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

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

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

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

Любая ссылочная позиция в скобках в формуле изобретения не предназначена для ограничения формулы изобретения, также как и любой конкретный символ на чертежах. Слово «содержащий» не исключает присутствия элементов или аспектов, не перечисленных в формуле изобретения. Использование единственного числа при описании элемента не исключает наличия множества таких элементов.

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

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

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

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

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

3. Устройство (201) преобразования по п. 2, в котором заданный временной интервал составляет пару секунд.

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

5. Устройство (201) преобразования изображений по п. 4, в котором блок управления дополнительно выполнен с возможностью отправки на сервер (207) данных идентификации устройства (201) преобразования изображения или дисплея (290) HDR.

6. Устройство (201) преобразования изображений по п. 1, в котором блок (202) управления выполнен с возможностью хранения по меньшей мере одних данных заданного алгоритма отображения в памяти (270) зашифрованным способом.

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

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

9. Сервер (207), обеспечивающий данные (gam, gam_enc) заданного алгоритма отображения, выполненный с возможностью приема информационного соединения, открывающегося из устройства (201) преобразования изображений по одному из пп. 1-8, и выполненный с возможностью выполнения проверки на основании переданных данных (id_rend) идентификации контента из устройства (201) преобразования изображений, проверяя, является ли второе изображение (LDR_CONT) авторизованным, и выполненный с возможностью после этого обеспечивать данные (gam, gam_enc) заданного алгоритма отображения в устройство (201) преобразования изображений.

10. Сервер (207), обеспечивающий данные (gam, gam_enc) заданного алгоритма отображения, по п. 9, выполненный с возможностью выполнения дополнительных проверок, в частности, является ли устройство (201) преобразования изображений авторизованным устройством.

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

12. Сервер (207), обеспечивающий данные (gam, gam_enc) заданного алгоритма отображения, по одному из пп. 9 или 11, выполненный с возможностью приема от устройства (201) преобразования изображений информации по меньшей мере одного аспекта из

- второго изображения (LDR_CONT),

- устройства (201) преобразования изображений,

- соединенного дисплея (290) HDR для воспроизведения первого изображения (HDR_PRED),

- оптических характеристик окружения дисплея (290) HDR и

- пользователя устройства (201) преобразования изображений,

и определения из этого, какие, если они есть, данные (gam, gam_enc) заданного алгоритма отображения следует отправить в устройство (201) преобразования изображений.

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

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

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

14. Способ получения первого изображения (HDR_PRED) по п. 13, в котором создают частное защищенное соединение по сети с сервером (207) в заданном временном интервале перед временем воспроизведения на дисплее (290) первого изображения.

15. Способ получения первого изображения (HDR_PRED) по п. 14, в котором блок (202) управления в местоположении воспроизведения первого изображения (HDR_PRED) отправляет данные (id_rend) идентификации контента, идентифицирующие второе изображение (LDR_CONT), на сервер (207).

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