СИСТЕМА ДЛЯ ОБРАБОТКИ НЕСКОЛЬКИХ HDR-ВИДЕОФОРМАТОВ Российский патент 2022 года по МПК H04N19/46 

ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ

Изобретение относится к способам и устройствам для обработки и, в частности, декодирования изменений во времени кодирования динамического диапазона видеоизображений или способам кодирования расширенного динамического диапазона (high dynamic range, HDR).

УРОВЕНЬ ТЕХНИКИ ИЗОБРЕТЕНИЯ

Еще несколько лет назад все видео (например, телевизионные программы или фильмы на дисках Blu-ray или видео для другого использования, такого как, например, видеотелефония) и большинство неподвижных изображений были закодированы в соответствии с так называемой философией пониженного динамического диапазона (LDR), также называемого стандартным динамическим диапазоном (SDR). Это означало, что имелся единый способ для создания изображений, при этом OETF Rec. 709 определяет 8- или 10-битные коды сигналов яркости цветов пикселей изображения YCbCr для передачи, и пиковая яркость кодирования (PB_C), т.е. яркость в видео самого яркого белого пикселя, который может быть закодирован, всегда были стандартными 100 нит, а самая темная кодируемая яркость была 0,1 нит. Все реальные дисплеи у конечных потребителей, а также мониторы предварительного просмотра в местах создания медиаконтента имели соответствующие самый белый белый (PB_D=100 нит) и самый темный черный, что делало создание и дальнейшую обработку видео на последующих этапах технологической цепочки относительно простой, поскольку производитель будет видеть на своем идентичном производственном мониторе то, что будет видеть конечный пользователь.

В последние несколько лет появились новые дисплеи с существенно отличающимися PB_D, например дисплей с PB_D, равным 2000 нит, который не менее чем в 20 раз более яркий, чем SDR-дисплей, и это может означать, что изображения будут выглядеть раздражающе яркими (например, при отображении SDR-изображения непосредственно на HDR-дисплее в условиях отображения относительной яркости с помощью кодированного белого, преобразованного к PB_D дисплея), или наоборот HDR-изображение (предположительно созданное для HDR-телевизора) может выглядеть слишком темным при прямом воспроизведении на HDR-телевизоре, т.е. без телевизора (TV), делающего некоторую (нестандартную) оптимизацию изображения, чтобы оно лучше смотрелось.

Все еще более усложнилось с введением за прошлые 4 года множества различных систем кодирования и обработки HDR-изображений.

Для удобства мы знакомим читателя с некоторыми базовыми аспектам HDR-кодирования и адаптации динамического диапазона с помощью фиг. 1, показывающей несколько архитипичных иллюстративных примеров множества возможных HDR-сцен, которые будущая HDR-система (например, соединенная с дисплеем с PB_D, равным 1000 нит) должна быть в состоянии правильно обрабатывать путем рендеринга подходящих яркостей для всех объектов/пикселей на изображении. HDR-изображения могут иметь множество нормальных цветов нормальной яркости (т.е. которые также могут быть кодированы в SDR, например, хорошо освещенное человеческое лицо), но, как правило, у них может быть по меньшей мере одна ультра-темная и ультра-яркая области пикселей.

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

Что отличает отображение HDR-изображений от того, как это всегда было в эпоху доминирования SDR, закончившуюся лишь пару лет назад, так это то, что SDR имел такой ограниченный динамический диапазон (PB_C=100 нит и отображаемый уровень черного приблизительно от 0,1 до 1 нит), что главным образом можно было показать только собственные отражающие способности объектов в SDR (которые находится между 90% для хорошего белого и 1% для хорошего черного цвета). Это было хорошо для распознавания объектов (имеющих определенное количество яркости от отражения и, конечно, их хроматичность) при равномерном технически контролируемом освещении, но не для красивых вариаций самого освещения, которое может присутствовать в естественных сценах, и того, какое воздействие это может иметь на зрителей.

В HDR можно по меньшей мере задать, чтобы отображались яркости, которые могут находиться, например, между 1/10000 и 10000 нит. Интересный вторичный вопрос тогда состоит в том, как такие яркости, как заданные в принятом изображении, т.е. яркости, как они должны в идеале отображаться, должны отображаться на любом дисплее с более низкой пиковой яркостью PB_D отображения, чем необходимо, например, 5000 нит для отображения солнца, как это в идеале предполагалось создающей стороной для солнца (и, предпочтительно, соответствующая более низкая отображаемая яркость для солнца на, скажем, дисплее с PB_D, равным 750 нит, должна быть определена так, что несмотря на то, что вид изображения не является идеальным, изображение с PB_C, равным 750 нит, при отображении по меньшей мере передает в максимально возможной степени исходное HDR-изображение-оригинал с PB_C, равным 5000 нит, по меньшей мере с корректной хроматичностью пикселей).

Несколько HDR-кодеков задают в дополнение к HDR-изображению-оригиналу соответствующее SDR-изображение (т.е. с оптимально заданным видом, означающим, что цвета пикселей изображения настолько визуально аналогичны цветам пикселей HDR-изображения, насколько это позволяет более ограниченный цветовой охват SDR); и некоторые кодеки также задают метод получения оптимально выглядящих так называемых изображений среднего динамического диапазона для предоставления дисплеям с PB_D между PB_D HDR-изображения-оригинала (например, 5000 или 10000 нит) и PB_C, равным 100 нит, для SDR (или для получения изображений для PB_D, который еще выше, чем PB_C изображения-оригинала). Это, как правило, делается с помощью дополнительной передачи в метаданных по меньшей мере функции преобразования яркости (фиг. 2, F_L; и, возможно, также спецификаций F_C преобразования цветов для, например, изменения насыщенности цветов SDR-пикселей, полученных из соответствующих цветов HDR-пикселей, в одном и том же пространственном местоположении), предписывающей, как яркость пикселей в HDR-изображении должна преобразовываться в некоторую соответствующую яркость SDR-пикселей (или в некоторых кодеках преобразование к некоторой яркости MDR-пикселей, тем самым не обязательно будучи преобразованием в SDR).

Слева мы видим ось яркости для кодирования HDR-изображения-оригинала с PB_C, равным 5000 нит (и соответствующим динамическим диапазоном DR_h, который может быть задан как самая большая яркость, деленная на самую низкую, хотя читатель должен понимать, что хорошая визуализация динамического диапазона зависит не только от этих двух конечных точек, но также и от оптимального определения для каждого типа HDR-сцены всех промежуточных яркостей пикселей для различных объектов HDR-сцены). Справа мы видим соответствующие яркости пикселей для типичных объектов изображения вдоль динамического диапазона DR_s яркости SDR.

Можно видеть, что иногда правило преобразования яркости состоит в «оставить яркость той же самой», а иногда яркость HDR должна быть уменьшена для сжатия большего диапазона яркостей HDR в меньший диапазон яркостей SDR. И, аналогично, механизм может получить вторичную функцию преобразования яркости для преобразования, например, принятых SDR-изображений или принятых HDR-изображений, например, в 750 или 1500-нитовые MDR-изображения (также называемого адаптацией для дисплея). Как будет более подробно показано ниже, обработка HDR-изображений сложна не только потому, что существует много различных видов дисплеев с различными PB_D, и хочется, чтобы каждый зритель получал оптимальное или по меньшей мере достаточно хорошее изображение на его конкретном дисплее исходного профессионального HDR-видеопроизведения, и что существует много различных видов HDR-сцен, которые можно создать и которые имеют различные HDR-эффекты и распределения яркости, которым нужна различная оптимизация перед отображением, но теперь также и потому, что были разработаны различные технические способы кодирования для HDR-видео, которые имеют различные EOTF и должны правильно декодироваться и координироваться, в частности, когда они перемежаются во времени.

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

Все такие HDR-видеокодеры имеют такое свойство (которое рассматривалось как необходимое требование, которое должно быть выполнено для обеспечения быстрого распространения на рынке, учитывая огромное количество уже развернутых технологий обработки видео из эпохи SDR), что HDR-изображение может на самом деле передаваться «как будто это нормальное SDR-изображение», т.е., например, с помощью HEVC или аналогичного сжатия видео.

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

Простейшим кодеком является кодек HDR10. Он генерирует сигналы Y яркости цветов пикселей с использованием новой опто-электрической передаточной функции (OETF), которая является намного более крутой, чем OETF Rec. 709, и поэтому способна кодировать больший диапазон яркостей входного изображения. Но для видеокомпрессора 203 это просто сигналы яркости, ему все равно (только декодер должен иметь правильную обратную OETF, так называемую EOTF, чтобы иметь возможность реконструировать правильные яркости HDR-пикселей). Следует отметить, что для упрощения понимания, EOTF в этом тексте не обязательно является лишь функциональной зависимостью между нормализованными сигналами яркости и яркостями, но также может учитывать пиковую яркость PB_C кодирования яркостей.

Другие видеокодеки передают HDR-изображение на самом деле как соответствующее SDR-изображение (обратно совместимые с традиционными декодерами для пользователей, например, вещательные компании, для которых то, как выглядит SDR-изображение является столь же важным или более важным чем то, как выглядит HDR-изображение), и декодер может преобразовывать принятые яркости SDR обратно в близкую реконструкцию HDR-изображения-оригинала, созданного производящей стороной. Примером такого кодека является кодек с гибридной лог гаммой (Hybrid LogGamma, HLG), который использует фиксированную функцию для преобразования (с такими недостатками, как цветовые ошибки, но для настоящей заявки это не так важно) и, следовательно, не требует отправки метаданных, по крайней мере теоретически.

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

Фиг. 2 будет объяснена с помощью типичной системы с передачей SDR, например, кодека SL_HDR1 (ETSI TS 103 433-1 v 1.2.1 (AUG 2017)) авторов изобретения. Функции F_ct преобразования цвета, будучи по меньшей мере одной функцией F_L преобразования яркости и, потенциально, также F_C (хотя некоторые системы могут задавать хорошо работающую F_C, соответствующую передаваемой F_L на принимающей стороне), могут быть заданы цветовым корректором-человеком (или, альтернативно, автоматическим программным обеспечением анализа изображений) для получения достаточно хорошо выглядящего SDR-изображения (Im_LDR), соответствующего HDR-изображению-оригиналу MAST_HDR, одновременно гарантируя, что при помощи обратных функций IF_ct исходное HDR-изображение-оригинал (MAST_HDR) может быть реконструировано с достаточной точностью в реконструированное HDR-изображение (Im_RHDR). Функции IF_ct могут быть определены из передаваемых прямых функций F_ct преобразования HDR-SDR, или система может даже непосредственно передавать функцию(и) IF_ct.

Преобразователь 202 цветов, как правило, применяет преобразование F_ct яркости к относительным яркостям пикселей HDR-изображения-оригинала (MAST_HDR), т.е. нормализованным так, чтобы максимальная яркость была равна 1.0. Для более легкого понимания концепций настоящего изобретения для простоты можно предположить, что он использует функцию преобразования яркости 4-й степени (L_out_SDR=степень(L_in_HDR;¼)) для получения нормализованных выходных яркостей SDR-пикселей для выходного SDR-изображения Im_LDR (т.е. правой стороны фиг. 1) с PB_C, равным 100 нит, т.е. что такая функция дает достаточно хороший вид соответствующих откалиброванных в SDR изображений для HDR-изображения-оригинала сцены (достаточно хороший означает, что для конкретной сцены такие аспекты как, например, большой процент темных областей не будет выглядеть слишком темным, лампы и другие яркие объекты будут выглядеть как требуется, так как они будут иметь все еще достаточный контраст между областями, при этом более темные области изображения на SDR-изображении будут на одном уровне, по меньшей мере насколько это позволяет динамический диапазон яркости SDR и т.д.; для других изображений могут иметь значение другие факторы, но такие подробности не являются ограничивающими или существенными для объяснения технических компонентов настоящего изобретения). Очевидно, функции преобразования яркости в целом могут быть более сложными, но такие подробности не являются необходимыми для понимания методик настоящего изобретения.

Так как приемники должны иметь возможность реконструировать HDR-изображение-оригинал из принятого соответствующего SDR-изображения или по меньшей мере близкую реконструкцию, но для некоторых связанных со сжатием артефактов, помимо самих пикселизированных изображений, в видеокодер 203 также должны быть введены функции F_ct преобразования цвета. Без ограничения мы можем предположить, что видео сжимается с помощью видеокомпрессора MPEG HEVC (или, аналогично, AVS и т.д.), и функции хранятся в метаданных, например, посредством механизма SEI или аналогичной методики.

Таким образом, после действия устройства 221 создания медиаконтента, с точки зрения технологии передачи изображения, видеокомпрессор 203 притворяется, что он получил нормальное SDR-изображение в качестве входной информации, и что более важно: выводит данные, которые технически являются SDR-изображением, декодируемым с помощью стандартных спецификаций Rec. 709 сигнала яркости SDR. Таким образом, далее дополнительная технология, например, средство 204 форматирования передачи, применяющая все необходимые преобразования для форматирования данных для передачи через некоторую передающую среду 205 (например, кодирующее для хранения на BD-диске или применяющее частотное кодировании для передачи по кабелю и т.д.), может просто применить все типичные этапы, которые оно раньше выполняло в парадигме SDR-кодирования.

Далее данные изображений передаются через некоторую передающую среду 205, например, спутник, кабель или интернет, например, в соответствии с ATSC 3.0, DVB или любым другим принципом передачи видеосигнала, одной или нескольким принимающим сторонам.

Как на потребительской, так и на профессиональной стороне приемник 206, который может входить в состав различных физических устройств, таких как, например, телеприставка, телевизор или компьютер, выполняет декодирование канала путем применения восстановления после форматирования и декодирования канала. Затем видеодекомпрессор 207 применяет, например, декодирование HEVC для получения декодированного SDR-изображения Im_RLDR и метаданных функции F_ct преобразования цвета. Затем преобразователь 208 цветов выполнен с возможностью преобразовывать SDR-изображение в изображение любого динамического диапазона не-SDR. Например, 5000-нитное исходное изображение-оригинал Im_RHDR может быть реконструировано путем применения обратных преобразований IF_ct цвета для преобразований F_ct цвета, используемых в кодирующей стороне для создания Im_LDR из MAST_HDR. Или, может иметься блок 209 адаптации для дисплея, который преобразовывает SDR-изображение Im_RLDR в другой динамический диапазон, например, Im3000n (в этом примере имеющее PB_C=3000 нит, но в целом любое PB_C ниже или выше, чем PB_C входного изображения, как правило, отличающееся по меньшей мере на 10%), оптимально откалиброванное в случае, если подключенный дисплей 210 является дисплеем с PB_D, равным 3000 нит, и т.д. Мы предположили, без ограничения, что видеодекодер и преобразователь цветов находятся в одном устройстве 220 переопределения видео. Хотя в этом примере мы предположили, что декодер был в конечной точке использования видео, соединенной с дисплеем для просмотра медиаконтента (например, HDR-телевизором или портативным дисплеем и т.д.), те же самые принципы могут применяться, например, в транскодере, в котором приемник находится в промежуточной точке цепочки обработки видео, например, в станции перераспределения оператора кабельного телевидения, или вместо отображения на дисплее выходное видео может сохраняться в энергонезависимой памяти и т.д.

Если бы все системы в мире передавали такую динамически изменяющуюся функцию F_L преобразования яркости для каждого изображения, проблем бы не было, даже если изменяется кодирование изображений, и, например, принимающий дисплей был бы в состоянии выполнить адаптацию для дисплея переданного изображения, имея информацию о яркостях пикселя до, например, 5000 нит, в оптимальное изображение, соответствующее дисплею, на который должны быть поданы HDR-изображения, независимо от того, какое у него PB_D (PB_C оптимального изображения равен конкретному PB_D, но также и все более низкие яркости должным образом преобразуются, в зависимости от того, какая конфигурация объектов фактически на изображении).

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

В WO2016/162095 говорится, что входное HDR-изображение (захваченное датчиком камеры) может быть закодировано в конечное изображение путем применения одной из нескольких возможных функций OETF для определения кодов сигналов яркости заключительного изображения. Например, значение гаммы степенной функции может быть выбрано в зависимости от того, какой в точности пиксельный медиаконтент (яркости или значения RGB) присутствует во входном изображении, например, если он имеет большой динамический диапазон, потому что он содержит глубоко черные, а также яркие пиксели. Эти глубоко черные пиксели могут квантоваться более точно, то есть визуально более совершенным образом для зрительной системы человека, если используется гамма-функция с более сильным наклоном для более тусклых яркостей (например, ¼ вместо ½). В этом документе описывается возможность выбора оптимальной OETF для каждого (отдельного) видео, которая затем должна передаваться в виде метаданных, указывающих, какой вариант был выбран кодировщиком, здесь не описывается, как изменять OETF в пределах одного и того же видео, которое было кодировано или, потенциально, принято.

US2017/0026646 описывает оптимальное нелинейное квантование, реализованное с помощью оптимально изменяемых OETF. Помимо некоторых преобразований цветов предварительной обработки, в основе этой идеи лежит кодированная передаточная функция 208 и, где это применимо, также 210.

Предположим 210 применяет фиксированную OETF, например, SMPTE 2084. Такая фиксированная OETF в основном хороша для любого HDR-видео, но ее можно еще улучшить путем предварительной обработки, когда известно, что только некоторые конкретные яркости присутствуют в конкретной части входного видео-оригинала, который должен быть закодирован. Например, предположим, что снимок между 10 минутами 40 секундами и 12 минутами 20 секундами это ярко освещенная планета с семью солнцами, яркости всех пикселей которого находятся в верхней части общего диапазона яркости (например, 100-10000 нит). Зная, что фиксированная OETF 2084 имеет относительно меньше квантованных кодов для яркого конца диапазона, передаточная функция 208 может выполнять предварительное преобразование яркостей, распределяя их по большему поддиапазону, сильнее в более темные яркости, так что больше кодов сигнала яркости в конечном счете используется для пикселей, которые существуют, давая более высокую точность. Если для отображения используется только входное HDR-изображение при реконструкции путем выполнения всех этих обработок в обратную сторону, ничего из того, что происходит в промежутке, не имеет большого значения для яркости конечного результата, за исключением качества кодирования HEVC.

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

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

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

Эта проблема решается с помощью видеодекодера (341), выполненного с возможностью декодирования видео с большим динамическим диапазоном, состоящего из последовательных во времени изображений, при этом видео состоит из последовательных временных сегментов (S1, S2), состоящих из многих последовательных во времени изображений (I1, I2), которые имеют цвета пикселей, при этом цвета пикселей в различных временных сегментах задаются с помощью сигналов яркости, соответствующих яркостям пикселей в соответствии с различными электрооптическими передаточными функциями, при этом изображения в некоторых сегментах задаются в соответствии с динамически изменяемыми электрооптическими передаточными функциями, которые передаются как отдельная функция для каждого последовательного во времени изображения, и при этом изображения в других сегментах имеют сигналы яркости, заданные фиксированной электрооптической передаточной функцией, информация о которой дополнительно передается в пакетах (DRAM) данных, которые передаются менее часто, чем частота повторения изображений, и при этом по меньшей мере один из упомянутых пакетов (DRAM) данных, характеризующих электрооптическую передаточную функцию сигналов яркости пикселей изображения после момента (t1) изменения между первым и вторым сегментом, передается до момента (t1) изменения, и при этом видеодекодер (341) имеет память (343) и выполнен с возможностью хранения в этой памяти пакета (DRAM) данных из упомянутых пакетов данных, принятого в момент времени раньше на число (N) повторений изображений, чем момент (t1) изменения.

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

Во-первых, для удобства читателя определена концепция EOTF, потому что в последнее время в эпоху HDR-видео она стала более сложной, чем классическая EOTF SDR.

По сути EOTF означает, что «электрические» коды (первоначально напряжения в аналоговом телевидении, но теперь в цифровом видео, как правило, M-битовые коды, где M обычно равно 10 или более; и коды могут быть кодами различных цветов, например, сигналами яркости 3×10 R, G и B или цветовым кодированием YCbCr) с помощью функционального вычисления могут быть преобразованы в оптические коды, а именно в отображаемую яркость, следовательно:

L=EOTF(Y’), где L является яркостью, определенной в колориметрии CIE, а Y’ является кодом сигнала яркости.

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

Y’=OETF(L).

В SDR была только одна единственная EOTF, задающая SDR телевизионной системы, которая была так задана, потому что электронные пушки ЭЛТ (CRT), облучающие люминофоры, имеют поведение преобразования приблизительно как степень 2 при преобразовании входного напряжения в выходную яркость, отображаемую на экране телевизора.

Говоря более точно, OETF Rec. 709 (SDR) был стандартизирован следующим образом (когда входная яркость нормализирована к [0.0-1.0]):

Y’=Если(L<0.018; 4.5*L; иначе 1.099степень(L;0.45)-0.099) [Ур. 1]

Однако, вычисляя яркости, соответствующие кодам 0-1023 сигналов яркости, можно показать, что эта OETF может кодировать только динамический диапазон 1000:1, или, точнее говоря, яркости LDR между 0,1 нит и 100 нит (что достаточно для получения достаточно хорошо выглядящих изображений при равномерном освещении, но не для впечатляющих HDR-изображений, например, со сверхъяркими световыми мечами в темных пещерах, для которых хотелось бы, чтобы создатель медиаконтента указал в качестве новых кодов Y’* сигнала яркости яркости от 1/10000 до 10000 нит, что хотя и не охватывает все яркости, встречающиеся в природе, но считается достаточным для задания изображений, которые будут просматриваться на дисплеях).

Таким образом, начали определять по меньшей мере одну новую HDR EOTF, которая была EOTF перцепционного квантователя (Perceptual Quantizer, PQ), стандартизированную как SMPTE ST.2084:

Y’*=СТЕПЕНЬ((C1+C2*СТЕПЕНЬ(L;A))/(1+C3*СТЕПЕНЬ(L;A));B) [Ур.2],

со следующими константами: C1=0,8359375; C2=18,8515625; C3=18,6875; A=0,1593017578125; B=78,84375.

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

Как говорилось выше, для компрессора HEVC входом являются пиксели с сигналом яркости Y, равным 10-битному числу, независимо от того, был ли сигнал яркости SDR-сигналом Y’ яркости, вычисленным в соответствии c Ур. 1, или HDR-сигналом Y’* яркости, вычисленным в соответствии с Ур. 2. Однако декодер, видя тот же самый код сигнала яркости, например 721, должен использовать правильную декодирующую EOTF для каждого соответствующего различного кодирования изображения, потому что хотя код сигнала яркости для двух разных сценариев может быть одинаковым, различная яркость, которая в конечном итоге должна быть отображена, должна вычисляться декодером путем применения соответствующей EOTF (фактически, поскольку PQ EOTF может давать гораздо большие или меньшие яркости, например, ненадлежащее применение PQ EOTF к сигналу яркости, который был закодирован в соответствии с OETF Rec.709 - и, следовательно, который должен декодироваться с помощью EOTF Rec.709 - может дать декодированную яркость, которая может быть более чем в 10 раз слишком яркой или слишком темной, даже только для этих двух фиксированных возможных EOTF).

Следует кратко отметить, что существуют также различные способы определения цветов HDR-пикселей, например гибридная лог гамма (Hybrid LogGamma, HLG) использует OETF для трех цветовых компонентов RGB по отдельности, т.е. давая, например, красный сигнал яркости R’**=OETF_HLG(R), где R является линейным количеством красного цвета в определении RGB-цвета (процентом красных фотонов в приблизительной непрофессиональной терминологии). Но для простоты пояснения концепций этого изобретения в следующем далее объяснении мы предполагаем, что цвета пикселей заданы в классическом кодировании цвета видео Y’CbCr, и Y’ может быть определен с помощью множества других OETF помимо стандартных OETF Rec. 709, с которыми он изначально был определен (и аналогично для соответствующих цветностей Cb и Cr).

Для читателя важно понимать, что более продвинутые (более высокое качество, соответствующее требованиям завтрашнего дня) HDR-видеокодеки, такие как SL-HDR1 (ETSI TS 103433-1 v 1.2.1 (AUG 2017)) и SL_HDR2 (ETSI TS 103 433-2) авторов изобретения имеют взаимосвязь между передаваемыми сигналами яркости и яркостями, которые в конечном итоге должны отображаться, которая определяется переменными функциями, то есть форма которых может изменяться в зависимости от особенностей HDR-изображения, что является значительным большим шагом по сравнению с фиксированным SDR или HDR10-кодированием (и такое преобразование может быть сформулировано в соответствии со старым названием как переменная EOTF). Чтобы читатель мог убедиться в том, что он понял все тонкости новой парадигмы, на фиг. 4 приведен один пример.

Предположим, что входное HDR-изображение является несколько более сложным (но не очень нетипичным, и в любом случае, если оно правильно обрабатывается любой технологией кодирования или обработки HDR) HDR-изображением сцены, состоящим из средне освещенных областей между темной областью пещеры и яркой освещенной солнцем областью и другой яркой областью Rsm). Вот как в общем может быть построено HDR-изображение сцены, будь то какая-то найденная окружающая обстановка, захваченная в локальной доступной ситуации освещения, или красивое художественно созданное изображение (возможно, компьютерная графика (CGI)). Существует несколько критериев для преобразования значительно более низкого диапазона яркости SDR, например, с помощью функции F_L(t1) преобразования яркости, оптимальной для этого конкретного момента времени (t1) изображения, которая задается цветовым корректором-человеком в месте создания медиаконтента. Преобразование показано с использованием стандартных яркостей, потому что читатель может представить, как такие яркости будут соответствовать, например, PQ-сигналам яркости на горизонтальной оси, а сигналы яркости Rec. 709 для вертикальной оси яркости SDR (что будет соответствовать нелинейному растяжению на оси и соответствующую деформацию формы преобразования яркости, но точка, необходимая для создания переменной EOTF, остается той же самой, как проиллюстрировано ниже в примере). Например, в самой темной области Rd изображения имеется человек с едва видимым спрятанным в тени ножом. При кодировании HDR-изображения (с его яркостями, показанными на горизонтальной оси нижнего графика преобразования яркости) яркости кодируют в соответствии с разумным предположением, что хорошая дисплейная HDR-система будет иметь возможность визуально оптимальным образом показать этого человека с яркостями, например, от 0.01 до 0.1 нит (следует отметить, что 0.1 нит уже является минимумом диапазона яркости SDR, поэтому не следует выполнять преобразование в соответствии с идентичностью яркостей в SDR и HDR). Чтобы этот человек был виден правильно в диапазоне яркости SDR, то есть не слишком явно видным, но и не полностью черным, необходимо выделить поддиапазону HD яркостей HDR поддиапазон RD яркостей SDR оптимально между 0.5 и 1 нит в этом примере, так что это уже определяет эту часть динамически изменяемой функции преобразования яркости изображения (или, соответственно, EOTF). Человек, лежащий в средней освещенной области Rwo изображения, должен быть преобразован в хорошо контрастные, яркие и красочные цвета диапазона SDR, то есть которые обычно лежат в области около 50 нит (даже на SDR-изображении мы хотели бы, например, чтобы контрастность глаз была хорошей как на более, так и на менее освещенной стороне лица). Фактически, если бы это было просто SDR-произведением, можно было бы придать лицу этого человека яркость, например, в 60 нит, а белой рубашке этого человека яркость в 90 нит, но для всех гораздо больших HDR-яркостей останется только 10 нит диапазона SDR для правильного отображения всего, что невозможно (и, как правило, будет обрезка по максимальному белому - сигналу яркости 1023 или яркости 100 - например, солнечной области Ros снаружи, поэтому деревья и кустарники не будут видны в однородно белых областях, не говоря уже о том, чтобы было красивое яркое желтоватое солнце). Следовательно, если мы хотим показать достаточно хорошо несколько более ярких областей HDR-изображения на SDR-изображении, мы должны снизить самую большую яркость диапазона RW, например, максимум до 50 нит (в зависимости от того, является ли хорошая насыщенность цветов лежащего человека более или менее предпочтительной по сравнению с насыщенностью цветов более ярких областей изображения). Проблемы ярких областей могут стать довольно сложными (требующими особого внимания к частичной форме кривой F_L(t1) для этого поддиапазона), как проиллюстрировано с помощью яркой области Rsm. Эта часть пещеры находится в очень ярком тумане, поэтому человек может показаться как едва видимая слабоконтрастная тень, модулирующая ярко-белый цвет («человек-тень»). Очевидно, что мы должны настроить эту часть кривой так, чтобы в SDR также была разница более чем на 2% между более темными пикселями человеческого тела и окружающим белым туманом, потому что это является порогом различимости. Однако если имеется статическая кривая OOTF_fix, можно видеть, что преобразование в самом темном поддиапазоне RD может привести к SDR-изображениям, на которых человек с ножом слишком виден, тогда как наклон верхней части кривой для поддиапазона HS слишком низкий, так что становится невидимым человек-тень. Следовательно, перекалибровка яркости HDR-изображения иногда может быть не очень сложной, а иногда может быть и довольно сложной, и решением, способным справиться со всеми возможными ситуациями с хорошим качеством, являются динамически настраиваемые функции преобразования яркости (но это может повлечь за собой риск того, что слишком чрезмерное преобразование будет применяться к изображению, которое не может поддерживать его, хотя, как мы покажем ниже, это не должно быть проблемой).

То, что мы показываем на графике на фиг. 4, на самом деле является опто-оптической передаточной функцией, но читателю должно быть понятно, как ее можно преобразовать в соответствующую электрооптическую передаточную функцию: яркости L_SDR могут быть преобразованы в стандартные сигналы яркости SDR в соответствии с OETF Rec. 709. Если затем применить кривую F_L(t1) к значениям яркости пикселей, например, согласно SL_HDR1, первоначально передаваемым как сигналы яркости в распакованном SDR-изображении HEVC, для получения восстановленных яркостей HDR, будет определена эквивалентная электрооптическая передаточная функция между входными кодами сигналов яркости SDR и выходными оптическими яркостями HDR (на самом деле наша предпочтительная обработка цвета также выполняет преобразование с помощью перцепционно унифицированных сигналов яркости, но эти детали не важны для данного изобретения, поскольку конечным эффектом является переменная EOTF).

Также в варианте SL_HDR2 есть эквивалент EOTF, который преобразует начальные, например, PQ-заданные сигналы яркости, в конечной выход, который является адаптированными для дисплея яркостями, которые должны отображаться на MDR-дисплее, и это аналогичным образом является примером переменной EOTF.

Работа только с динамическими функциями преобразования яркости в принципе не создает больших проблем: но все еще могут возникнуть проблемы с согласованием яркости двух видео, если бы они были, например, по-разному освещены, но, по меньшей мере можно декодировать две последовательности изображений правильно в некоторое эталонное представление, например PB_C_x и PB_C_y реконструированного HDR). Это связано с тем, что с каждым изображением будет ассоциирован свой пакет 313 динамических метаданных, содержащий, например, информацию о динамической функции F_L(t00) преобразования яркости (например, в качестве параметров, задающих форму функции в некоторых вариантах осуществления ETSI SL_HDR1 или SL_HDR2, или функции LUT в других вариантах осуществления) для момента времени t00 изображения.

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

Таким образом, для некоторых систем кодеков, например, системы передачи HDR-видео на основе исключительно HDR10 (статических PQ-заданных сигналов яркости), дающих такое HDR-видео, перемежающееся с SDR-видео (заданным с помощью OETF Rec 709) (или с другим статическим HDR-видео, закодированным в соответствии с другой статической OETF, чем PQ-функция), имеется неразрешимая проблема: плохое декодирование по меньшей мере некоторых кадров второго видеосегмента после смены сегмента (t1 или t2 и т. д.), что приводит к (потенциально серьезным) визуальным дефектам, например, в средней яркости изображений до и после времени изменения (также в SDR может произойти смена сцены, например, если создатель медиаконтента не создал хорошего перехода между, например, действием в темной пещере и яркой сценой на открытом воздухе или наоборот, но теперь, например, на 2000-нитном телевизоре это может стать довольно неприятным для зрителя, потому что пещера может быть намного темнее, чем 1 нит в среднем, а яркая область в несколько десятков раз ярче, чем 100 нит).

Однако система, имеющая динамические метаданные, может изящно решить проблему декодирования. Таким образом, пакеты динамических метаданных будут содержать всю информацию для применения переменного преобразования яркости для каждого изображения, следовательно, каждое изображение может быть правильно декодировано (или потенциально дополнительно или иначе обработано, если это является альтернативной целью приемного устройства, например, приведено в соответствие с конкретной эталонной ситуацией, которая может требовать различных, локально оптимизированных функций преобразования яркости, но смысл входных данных яркости в любом случае должно быть однозначно ясен, поэтому такие вторичные локально оптимизированные функции преобразования яркости для приведения в соответствие, как правило, определяются на основании дополнительно передаваемых динамически изменяемых функций преобразования яркости, которые преобразуют в эталонное HDR-изображение декодера, то есть, например, из принятых сигналов яркости SDR в яркости HDR в эталонном диапазоне яркости с PB_C, равным 5000 нит). Следовательно, если есть изменение между статически определенным HDR (например, HDR10) или SDR до времени (t1) изменения и динамически определенным HDR (например, SL_HDR1 или SL_HDR_2 авторов изобретения), после изменения первое изображение может быть правильно обработано, потому для него есть дополнительно передаваемая динамическая функция яркости в подходящим образом определенном зарезервированном пакете, детали которого будут зависеть от того, какой используется стандарт передачи видео (и видео до t1, как правило, также будет нормально декодироваться, потому что приемник лучше определил, какова декодирующая EOTF этого видеосегмента ко времени этого последнего сегмента).

Но возникает интересная ситуация, когда начинается новый статически определенный сегмент HDR или SDR, потому что создатель такого видео не создал динамических метаданных, а также будет нелегко или не будет гарантировано, что конечный вещатель объединенного выходного видео изящно решит эту проблему, поэтому обычно будут возникать ситуации, когда первое изображение не имеет достаточно данных для его декодирования. Такие данные в конечном итоге будут получены, но это приведет к тому, что новый динамический HDR-декодер будет вести себя так же проблематично, как и декодер HDR HDR10-типа.

Такой (статический) пакет данных (например, DRAM11) на практике обычно будет содержать по меньшей мере EOTF, а именно статическую EOTF, с помощью которой должны декодироваться сигналы яркости нового сегмента после времени (t1) изменения.

Новый динамический HDR-декодер предназначен для работы с соответствующим новым HDR-кодировщиком, который должен уже несколько заранее передавать пакет DRAM11, до времени t1 изменения (что кажется немного экзотичным, поскольку обычный способ реализации видео состоит в том, что видео содержит свои собственные метаданные, поэтому добавление сегмента откуда-то еще будет приводить к тому, что пакеты DRAM будут находиться после времени изменения, которое является их логичным местом). Новый HDR-декодер будет постоянно искать такие пакеты и помещать их в память 343 на случай, когда внезапно, неожиданно динамические метаданные (313) исчезнут, так что соответствующая EOTF для декодирования изображения после времени t1 изменения будет доступна для мгновенной загрузки в подветвь обработки яркости блока вычисления цветов изменяющего динамический диапазон декодера (процессор (344)).

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

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

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

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

Выгодно, если декодер выполнен с возможностью сохранения в памяти последнего пакета (DRAM) данных, принятого до момента (t1) изменения, чтобы использовалась правильная EOTF.

Варианты осуществления видеодекодера могут содержать видеовход (342), выполненный с возможностью приема видео, передаваемого по HDMI- или DisplayPort-кабелю, так, например, HDMI имеет возможности определения пакетов метаданных для передачи как динамических пакетов для каждого изображения, которые могут содержать оптимизированную для каждого изображения функцию F_L(t0) преобразования яркости, так и статических (редких) пакетов, которые могут задавать фиксированную EOTF. Этот механизм HDMI передачи видео может создавать свои собственные проблемы. Например, даже если входящий поток от телевещательной компании, поступающий в телеприставку, относительно хорошо структурирован, с плотной дополнительной передачей пакетов DRAM, при передаче видео на телевизионную приставку в восходящем направлении может быть потеряна хорошая синхронизация, потому что некоторые (например, более старые) версии такой технологии передачи видео не обеспечивает хорошей синхронизации. И декодер может принимать пакет DRAM и, например, помещать его в память для использования при декодировании в неопределенный момент времени по сравнению с номером изображения видеопотока.

В соответствии с новой возможностью декодера существует видеокодер (3010), выполненный с возможностью кодирования видео с большим динамическим диапазоном, состоящего из последовательных во времени изображений, при этом видео состоит из последовательных временных сегментов (S1, S2), состоящих из многих последовательных во времени изображений (I1, I2), которые имеют цвета пикселей, при этом цвета пикселей в различных временных сегментах задаются с помощью сигналов яркости, соответствующих яркостям пикселей в соответствии с различными электрооптическими передаточными функциями, при этом изображения в некоторых сегментах задаются в соответствии с динамически изменяемыми электрооптическими передаточными функциями, которые передаются как отдельная функция для каждого последовательного во времени изображения, и при этом изображения в других сегментах имеют сигналы яркости, заданные фиксированной электрооптической передаточной функцией, информация о которой дополнительно передается в пакетах (DRAM) данных, которые передаются менее часто, чем частота повторения изображений, и при этом по меньшей мере один из упомянутых пакетов (DRAM) данных, характеризующих электрооптическую передаточную функцию сигналов яркости пикселей изображения после момента (t1) изменения между первым и вторым сегментом, передается до момента (t1) изменения. Такой кодер может быть расположен в различных местах типичной цепочки передачи HDR-видео, при условии, что конечное устройство, которое содержит новый декодер, может правильно декодировать смешанное HDR-видео (которое оно принимает, например, по HDMI-кабелю). Так, например, это может быть кодировщик телевещательной компании, например Британской радиовещательной корпорации, или кодировщик может находиться в промежуточном устройстве 321 обработки видео (таком как телеприставка или компьютер, или, возможно, даже в устройстве чтения памяти, таком как BD-плеер и т. д.), и в этом случае он может исправлять плохое смешанное во времени HDR-видео в декодируемое смешанное видео согласно настоящему изобретению и его вариантам осуществления.

Также интересен способ декодирования видеосигнала, выполненный с возможностью декодирования видео с большим динамическим диапазоном, состоящего из последовательных во времени изображений, при этом видео состоит из последовательных временных сегментов (S1, S2), состоящих из многих последовательных во времени изображений (I1, I2), которые имеют цвета пикселей, при этом цвета пикселей в различных временных сегментах задаются с помощью сигналов яркости, соответствующих яркостям пикселей в соответствии с различными электрооптическими передаточными функциями, при этом изображения в некоторых сегментах задаются в соответствии с динамически изменяемыми электрооптическими передаточными функциями, которые передаются как отдельная функция для каждого последовательного во времени изображения, и при этом изображения в других сегментах имеют сигналы яркости, заданные фиксированной электрооптической передаточной функцией, информация о которой дополнительно передается в пакетах (DRAM) данных, которые передаются менее часто, чем частота повторения изображений, и при этом по меньшей мере один из упомянутых пакетов (DRAM) данных, характеризующих электрооптическую передаточную функцию сигналов яркости пикселей изображения после момента (t1) изменения между первым и вторым сегментом, передается до момента (t1) изменения, и при этом пакет (DRAM) данных из упомянутых пакетов данных, принятый в момент времени раньше на число (N) повторений изображений, чем момент (t1) изменения, сохраняется, и способ кодирования видео, выполненный с возможностью кодирования видео с большим динамическим диапазоном, состоящего из последовательных во времени изображений, при этом видео состоит из последовательных временных сегментов (S1, S2), состоящих из многих последовательных во времени изображений (I1, I2), которые имеют цвета пикселей, при этом цвета пикселей в различных временных сегментах задаются с помощью сигналов яркости, соответствующих яркостям пикселей в соответствии с различными электрооптическими передаточными функциями, при этом изображения в некоторых сегментах задаются в соответствии с динамически изменяемыми электрооптическими передаточными функциями, которые передаются как отдельная функция для каждого последовательного во времени изображения, и при этом изображения в других сегментах имеют сигналы яркости, заданные фиксированной электрооптической передаточной функцией, информация о которой дополнительно передается в пакетах (DRAM) данных, которые передаются менее часто, чем частота повторения изображений, и при этом по меньшей мере один из упомянутых пакетов (DRAM) данных, характеризующих электрооптическую передаточную функцию сигналов яркости пикселей изображения после момента (t1) изменения между первым и вторым сегментом, передается до момента (t1) изменения.

В зависимости от технологии, если до момента изменения метода HDR-кодирования передается только один пакет DRAM, лучше всего, если пакет будет отправлен ни слишком близко ко времени изменения, ни слишком рано до него. Как правило, четверть секунды, полсекунды и/или секунда могут быть хорошим временем передачи, следовательно, это будет, например, для видео с частотой 50 Гц соответствовать, например, 10 кадрам, 25 кадрам или 50 кадрам перед первым кадром, который закодирован в соответствии с новым способом статического кодирования HDR. В объяснении ниже также будет подробно описано, как декодер может легко определить, к какому моменту времени изображения будет принадлежать такой предварительно отправленный DRAM.

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

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

На чертежах:

Фиг. 1 схематично изображает ряд типичных преобразований цвета, происходящих, когда оптимально преобразуют изображение с большим динамическим диапазоном в соответствующее оптимально откалиброванное по цвету и выглядящее похоже (настолько похоже, насколько желательно и возможно, учитывая различия в первом и втором динамических диапазонах DR_h и DR_s) изображение с низким или говоря более точно стандартным динамическим диапазоном, которое в случае обратимости также будет соответствовать преобразованию SDR-изображения, кодирующего HDR-сцену, в реконструированное HDR-изображение этой сцены;

Фиг. 2 схематично изображает пример технологии для кодирования изображений с большим динамическим диапазоном, т.е. изображений, способных иметь, как правило, яркость пикселей по меньшей мере до 700 нит (т.е. по меньшей мере в 7 раз больше PB_C SDR-изображения) или больше (на самом деле в настоящее время HDR-изображение, как правило, имеет PB_C, равный 1000 нит или больше), которая может, например, передавать HDR-изображение(я) на самом деле как SDR-изображение плюс метаданные, например, в сообщениях SEI, кодирующих функции преобразования цвета, содержащих по меньшей мере соответствующее определенное преобразование F_L яркости для цветов пикселей, которое должно использоваться декодером для преобразования принятого SDR-изображения(й) в HDR-изображение(я), которые являются точной реконструкцией исходного HDR-изображения(й)-оригинала(ов), созданное на стороне создания изображений, и повторно использующую типичные технологии передачи изображений, уже разработанные для передачи SDR, такие как, например, кодирование HEVC;

Фиг. 3 схематично показывает пример системы в соответствии с настоящим изобретением с новым декодером 341 и кодером смешанного во времени видео 3010;

Фиг. 4 схематично изображает концепцию динамически изменяющихся функций преобразования яркости, которая в рамках настоящего изобретения соответствует динамическим EOTF (и OETF); и

Фиг. 5 схематично изображает вариант осуществления кодера в соответствии с настоящим изобретением.

ПОДРОБНОЕ ОПИСАНИЕ ВАРИАНТОВ ОСУЩЕСТВЛЕНИЯ

Фиг. 3 показывает пример новой экосистемы HDR-кодека с новым декодером 314, способным декодировать все имеющиеся способы кодирования HDR-сегментов (а также перемежающееся SDR-видео). Создатель медиаконтента, или чаще, говоря более точно, распространитель-посредник может, конечно, попытаться преобразовать все входящее видео к общему диапазону яркости и передать его с помощью одного кода, но это требует других, не обязательно простых методик, и это не всегда будет делаться. В ближайшие годы наверняка может стать типичным, что, например, телевещание спортивных событий ведется в высоком качестве в HDR, но промежуточная реклама, например, в SDR (и создатель этого медиаконтента может не хотеть или даже запрещать преобразование в HDR, потому что его не устраивает, скажем, что произойдет с яркими областями, которые обрезаются в его записи SDR при увеличении яркости в области HDR). Кроме того, не все технологии доставки уже могут быть способны выполнять фактические преобразования кодека, тем более, когда несколько новых кодеков продолжают появляться со своей собственной философией и техническими особенностями (особенно дорогие профессиональные устройства, которые не так часто изменяются, как, например, потребительские мобильные телефоны).

В качестве примера устройства доставки видео (читатель может аналогичным образом представить себе другие варианты осуществления, такие как, например, доставка OTT через Интернет и т.д.) имеется телевизионная вещательная компания, которая на своей территории управляет видеомикшером 301, который может микшировать видео из первого источника 302 видео (например, предварительно записанную мыльную оперу, закодированную в HDR10) и второго источника 303 видео (например, локально хранящиеся рекламные ролики, которые должны транслироваться в этот момент времени). Видеомикшер в его простейшем воплощении будет просто последовательно соединять различные кодированные сегменты во времени. В принципе не так плохо, если это произойдет (как в эпоху SDR, когда были только однозначно определенные сигналы яркости SDR для всех возможных видео) в цветовом пространстве кодированного видео, т.е. HEVC-изображения сегмента HDR10 передаются с помощью Y’*CbCr цветов, при этом эти цветовые компоненты вычисляются для исходных линейных цветов пикселей RGB в соответствии с OETF PQ, как определено в SMPTE ST.2084, и сигналы яркости SDR в соответствии с Rec. 709 и т.д. Как уже говорилось, последовательно встречающиеся одинаковые 10- или 12- битные коды сигналов яркости могут означать что-то совершенно разное в последовательных сегментах в качестве фактического линейного цвета RGB, но если все сделано правильно, эти окончательные цвета RGB могут быть правильно определены любым приемником (а если что-то сделано неправильно, то нет). Видеокодер 3010 может просто применять, например, компрессию HEVC для всех цветов YCbCr пикселей во всех последовательных изображениях, но если кодер должен функционировать в соответствии с настоящим изобретением, он должен быть осторожен в отношении генерации информации функции декодирования, а именно пакетов метаданных динамической функции преобразования яркости, таких как пакет 313, и статических пакетов с соответствующей кодификацией EOTF, таких как пакет DRAM11, которые в этом примере будут передавать EOTF PQ. Динамические функции F_L(t00), F_L(t01) и т.д. будут - для динамически кодированного HDR, такого как сегмент SL_HDR1 в этом примере - передаваться для каждого соответствующего изображения I1, I2 и т.д. Статические пакеты DRAM11 и, как правило, несколько других повторений могут быть закодированы в синхронизированные или синхронизируемые метаданные различным образом, но в соответствии по меньшей мере с одним принципом, которому необходимо следовать: по меньшей мере один пакет DRAM11 должен быть вставлен в исходящий поток до момента t1 изменения, когда начинается HDR10-кодированное видео, на число N раз повторений изображения (например, 2 изображения или 10 изображений до, в зависимости от того, что обычно делает система или стандарт), то есть в предыдущий момент времени t0X.

Следовательно, выход видеокодера, например, передаваемый антенной 304 как объединенный HDR-видеосигнал Scmb, будет передаваться как три части во времени: видеопоток 310 с сегментами с S1 по S4, поток 311 динамических метаданных (если, конечно, передаются динамические функции яркости, при этом кресты указывают время, когда такие динамические метаданные отсутствуют) и нерегулярные пакеты данных (DRAM), содержащие информацию только об одной фиксированной EOTF во втором потоке 312 метаданных, например, показаны два пакета DRAM31 и DRAM32, которые характеризуют HLG-кодированный сегмент HDR-видео, т.е. которые указывают в своих метаданных EOTF HLG (специалисту в данной области техники будет понятно, что существуют различные способы сделать это, но, как правило, динамические функции должны иметь определенную форму, тогда как фиксированные EOTF существуют только в нескольких разновидностях, поэтому пакет DRAM может содержать только номер версии EOTF, например, 1 означает HDR10, 2 означает HLG и т. д.).

Пример нового видеокодера 510 показан на фиг.5 (без потери общности для следующего примера читатель может предположить, что он находится в телеприставке и «исправляет» входящий смешанный HDR-поток перед выводом несжатых смешанных HDR-видеоданных через свой выход 521, например, через HDMI-кабель (для ясности: несжатый не означает, что цвета не могут быть закодированы с помощью цветового кодирования, отличающегося от стандартного аддитивного цветового кодирования, являющегося линейным RGB; это просто означает, что видео, идущее через HDMI-кабель, не является HEVC- или AVC-сжатым, но приемник, например телевизор, может все еще нуждаться в преобразовании цвета в соответствующие линейные цвета RGB для управления его дисплейной панелью 345).

Тройное смешанное HDR-видео, поступающее на вход 520 (т.е. пикселизированные данные видеоизображений и два потока метаданных, содержащие информацию для правильного декодирования кодов сигналов яркости пикселей изображения или в целом их цветовых кодов), описано на фиг. 3, но имеет неправильный тип, потому что пакет DRAM11, например, перекрывается во времени с его соответствующим сегментом S2 HDR10-видеоданных (предположим, что вещательная компания просто перемешала одно видео с другим при их поступлении, например, с помощью простого переключателя).

На выходе 521 создается новый смешанный HDR-видеосигнал, что является правильным, и даются две иллюстративные возможности. Пакет DRAM11 просто сдвигается на предыдущий момент времени передачи, что означает, что он не будет повторно посылаться в его исходном положении, обозначенном в виде пунктирного пакета после t1. Для HLG показана возможность дублирования. Копия DRAM311 передается до момента изменения t3, но исходный пакет DRAM31 также посылается в свое исходное время, поскольку может быть полезно дублировать статические пакеты несколько раз.

Возвращаясь к фиг.3, показан иллюстративный вариант осуществления принимающей стороны. Он содержит промежуточное устройство 321 обработки видео, которое принимает через свой вход 320, например, спутниковое вещание (демодулирует и т. д.) и передает демодулированное и, как правило, декомпрессированное видео через свой выход 322 в дисплейную систему 340 через линию 330 передачи видео, например HDMI-кабель, но потенциально также установленное беспроводное соединение и т.д. Специалисту в данной области техники будет понятно, как будет работать другой вариант осуществления, если система отображения будет заменена энергонезависимой памятью, например, если правильно отформатированное смешанное видео сохраняется для дальнейшего использования и т. д.

Дисплейная система содержит часть, обрабатывающую видео, которая через вход видеодекодера принимает смешанное видео HDR, она содержит память 343 для хранения по меньшей мере одного из нескольких DRAM для последующего использования процессором 344 для применения правильного преобразования цвета, обычно включающего преобразование динамического диапазона, например, декодирования видео в изображение с другим динамическим диапазоном, чем у входного изображения, или декодирования как такового из сигналов яркости в яркости, оставаясь в пределах одного и того же кодирования, то есть одного и того же динамического диапазона, например SDR, и т.д. Такой декодер может обрабатывать все ситуации, в которых для декодирования по-прежнему требуется информация по меньшей мере из одного пакета DRAM (даже если часть информации может быть динамической, но недостаточной для хорошего декодирования); для простоты мы предполагаем, что динамические метаданные означают полную информацию, позволяющую декодировать текущее входящее изображение в любое MDR-изображение, включая SDR- и HDR-изображение, а статические означает требующие по меньшей мере некоторой статической информации для его декодирования, которая будет включена в редко доступную и/или несинхронизированную информация DRAM. Некоторые варианты осуществления могут полезно содержать детектор (346) изменения видео такого типа, который сконструирован для обнаружения такого изменения сегмента путем обнаружения исчезновения или появления динамических метаданных, то есть, как правило, динамической функции преобразования яркости для последовательных изображений.

Альтернативно, декодер может быть инициирован (или синхронизирован), когда происходит изменение на следующий новый статический (т.е. не имеющий всю информацию всегда синхронизированной с входящими изображениями) кодек изображений путем обнаружения присутствия синхронного нового пакета метаданных, который указывает на такое изменение (в случае, если он передается передатчиком, чей пакет CHOC указания смены кодека показан пунктиром на фиг. 5 из-за опциональной природы такого улучшенного варианта осуществления). Например, вариант осуществления детектора (346) изменения видео может проверять либо недоступность метаданных динамической функции преобразования яркости, либо пакета CHOC, либо и того, и другого, а некоторые варианты осуществления могут дополнительно проверять другие свойства принятых видеоданных. Если пакет CHOC уже доступен на его входе, любое исходное или промежуточное устройство, содержащее соответствующий вариант осуществления настоящего кодера, может просто скопировать его в тот же самый момент времени в своем выходном потоке как пакет CHOC2, а в противном случае он может создать такой правильно синхронизированный пакет CHOC2 (выходной пакет указания смены кодека).

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

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

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

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

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

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

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

Изобретение относится к способам и устройствам для обработки и, в частности, декодирования изменений во времени кодирования динамического диапазона видеоизображений или способам кодирования расширенного динамического диапазона (high dynamic range, HDR). Техническим результатом является возможность обработки по-разному заданного HDR-видео из различных источников с различными параметрами кодирования. Результат достигается тем, что видеодекодер выполнен с возможностью декодирования видео с большим динамическим диапазоном, состоящего из последовательных во времени изображений, в которых видео состоит из последовательных временных сегментов (S1, S2), состоящих из множества последовательных во времени изображений (I1, I2), которые имеют цвета пикселей, при этом цвета пикселей в различных временных сегментах задаются сигналами яркости, соответствующими яркостям пикселей в соответствии с различными электро-оптическими передаточными функциями (EOTF), при этом изображения в некоторых сегментах задаются в соответствии с динамически изменяемыми электрооптическими передаточными функциями, которые передаются как отдельная функция для каждого последовательного во времени изображения, и при этом изображения в других сегментах имеют сигналы яркости, задаваемые фиксированной электрооптической передаточной функцией, информация о которой дополнительно передается в пакетах данных (DRAM), которые передаются менее часто, чем частота повторения изображений, и при этом по меньшей мере один из упомянутых пакетов данных (DRAM), характеризующий электрооптическую передаточную функцию сигналов яркости пикселей изображения после момента (t1) изменения между первым и вторым сегментом передается до момента (t1) изменения; и, аналогично, соответствующий кодер, который составляет сегментированный видеопоток, гарантируя, что по меньшей мере один правильный пакет (DRAM), описывающий EOTF, в соответствии с которым кодируются сигналы яркости более позднего видеосегмента, принимается приемниками до перехода к сегменту с другим методом кодирования HDR. 4 н. и 5 з.п. ф-лы, 5 ил.

1. Видеодекодер (341), выполненный с возможностью декодирования видео с большим динамическим диапазоном, состоящего из последовательных во времени изображений, при этом видео состоит из последовательных временных сегментов (S1, S2), состоящих из многих последовательных во времени изображений (I1, I2), которые имеют цвета пикселей, при этом цвета пикселей в различных временных сегментах задаются с помощью сигналов яркости, соответствующих яркостям пикселей в соответствии с различными электрооптическими передаточными функциями, при этом изображения в некоторых временных сегментах задаются в соответствии с динамически изменяемыми электрооптическими передаточными функциями, которые передаются как отдельная функция для каждого последовательного во времени изображения, и при этом изображения в других временных сегментах имеют сигналы яркости, заданные фиксированной электрооптической передаточной функцией, информация о которой дополнительно передается в пакетах (DRAM) данных, которые передаются менее часто, чем частота повторения последовательных во времени изображений, и при этом по меньшей мере один из упомянутых пакетов (DRAM) данных, характеризующих фиксированную электрооптическую передаточную функцию сигналов яркости пикселей изображения после момента (t1) изменения между первым и вторым сегментом, передается до момента (t1) изменения в момент времени раньше на число (N) повторений изображений, и при этом видеодекодер (341) имеет память (343) и выполнен с возможностью хранения в этой памяти упомянутого пакета (DRAM) данных, переданного до момента (t1) изменения в момент времени раньше на число (N) повторений изображений.

2. Видеодекодер (341) по п. 1, выполненный с возможностью хранения в памяти последнего пакета (DRAM) данных, принятого до момента (t1) изменения.

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

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

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

6. Видеодекодер (341) по одному из упомянутых выше пунктов, содержащий видеовход (342), выполненный с возможностью принимать видео, переданное с помощью HDMI- или DisplayPort-кабеля.

7. Видеокодер (3010), выполненный с возможностью кодирования видео с большим динамическим диапазоном, состоящего из последовательных во времени изображений, при этом видео состоит из последовательных временных сегментов (S1, S2), состоящих из многих последовательных во времени изображений (I1, I2), которые имеют цвета пикселей, при этом цвета пикселей в различных временных сегментах задаются с помощью сигналов яркости, соответствующих яркостям пикселей в соответствии с различными электрооптическими передаточными функциями, при этом изображения в некоторых временных сегментах задаются в соответствии с динамически изменяемыми электрооптическими передаточными функциями, которые передаются как отдельная функция для каждого последовательного во времени изображения, и при этом изображения в других временных сегментах имеют сигналы яркости, заданные фиксированной электрооптической передаточной функцией, информация о которой дополнительно передается в пакетах (DRAM) данных, которые передаются менее часто, чем частота повторения последовательных во времени изображений, и при этом по меньшей мере один из упомянутых пакетов (DRAM) данных, характеризующих электрооптическую передаточную функцию сигналов яркости пикселей изображения после момента (t1) изменения между первым и вторым сегментом, передается до момента (t1) изменения.

8. Способ декодирования видеосигнала, выполненный с возможностью декодирования видео с большим динамическим диапазоном, состоящего из последовательных во времени изображений, при этом видео состоит из последовательных временных сегментов (S1, S2), состоящих из многих последовательных во времени изображений (I1, I2), которые имеют цвета пикселей, при этом цвета пикселей в различных временных сегментах задаются с помощью сигналов яркости, соответствующих яркостям пикселей в соответствии с различными электрооптическими передаточными функциями, при этом изображения в некоторых временных сегментах задаются в соответствии с динамически изменяемыми электрооптическими передаточными функциями, которые передаются как отдельная функция для каждого последовательного во времени изображения, и при этом изображения в других временных сегментах имеют сигналы яркости, заданные фиксированной электрооптической передаточной функцией, информация о которой дополнительно передается в пакетах (DRAM) данных, которые передаются менее часто, чем частота повторения последовательных во времени изображений, и при этом по меньшей мере один из упомянутых пакетов (DRAM) данных, характеризующих фиксированную электрооптическую передаточную функцию сигналов яркости пикселей изображения после момента (t1) изменения между первым и вторым сегментом, передается до момента (t1) изменения в момент времени раньше на число (N) повторений изображений, и при этом пакет (DRAM) данных из упомянутых пакетов данных, принятый в момент времени раньше на число (N) повторений изображений, чем момент (t1) изменения, сохраняется.

9. Способ кодирования видео, выполненный с возможностью кодирования видео с большим динамическим диапазоном, состоящего из последовательных во времени изображений, при этом видео состоит из последовательных временных сегментов (S1, S2), состоящих из многих последовательных во времени изображений (I1, I2), которые имеют цвета пикселей, при этом цвета пикселей в различных временных сегментах задаются с помощью сигналов яркости, соответствующих яркостям пикселей в соответствии с различными электрооптическими передаточными функциями, при этом изображения в некоторых временных сегментах задаются в соответствии с динамически изменяемыми электрооптическими передаточными функциями, которые передаются как отдельная функция для каждого последовательного во времени изображения, и при этом изображения в других временных сегментах имеют сигналы яркости, заданные фиксированной электрооптической передаточной функцией, информация о которой дополнительно передается в пакетах (DRAM) данных, которые передаются менее часто, чем частота повторения последовательных во времени изображений, и при этом по меньшей мере один из упомянутых пакетов (DRAM) данных, характеризующих электрооптическую передаточную функцию сигналов яркости пикселей изображения после момента (t1) изменения между первым и вторым сегментом, передается до момента (t1) изменения.