ПРОСТОЕ, НО ГИБКОЕ КОДИРОВАНИЕ ДИНАМИЧЕСКОГО ДИАПАЗОНА
SIMPLE BUT FLEXIBLE DYNAMIC RANGE ENCODING

Область техники, к которой относится изобретение
Изобретение относится к устройствам и способам, а также к конечным продуктам, таким как продукты либо сигналы для хранения или передачи данных (например, Blu-Ray-диск), которые обеспечивают преобразование изображения или видео из изображений с первым динамическим диапазоном яркости в изображение или видео со вторым динамическим диапазоном яркости (который в большинстве нижеприведённых вариантов осуществления ниже первого диапазона входного изображения на стороне кодирования и выше на стороне декодирования), в частности начиная с эталонного изображения с расширенным динамическим диапазоном (HDR) (например, с пиковой яркостью на 1000 нит, представляющей собой пиковую яркость ассоциированного опорного дисплея), что без ограничений может представлять собой, например, эталонную HDR-коррекцию, созданную с конкретным внешним видом цвета, заданным цветокорректировщиком, или захват необработанной телевизионной программы, готовой к широковещательной передаче и т.д., и затем кодирование и передачу через изображение со вторым динамическим диапазоном или в конкретном наборе изображений (видео), которые кодируются в динамическом диапазоне, отличном от динамического диапазона входного эталонного изображения, и, например, обычно могут кодироваться как изображения со стандартным динамическим диапазоном (SDR; которые задаются с помощью ранее созданного стандарта Rec. 709 OETF; и корректируются таким образом, что они выглядят оптимально на опорном мониторе с пиковой яркостью (PB) на 100 нит), либо также любое кодирование изображений с LDR (узким динамическим диапазоном) и на другой стороне соответствующих декодеров изображений или видео любой системы передачи изображений (1), чтобы обеспечивать декодированное изображение, например, подходящее для рендеринга на доступном на приёмной стороне HDR-дисплее с PB на 3000 нит. Варианты осуществления способа и устройства, в частности, являются подходящими для любого кодирования и, соответственно, декодирования видео, которое должно иметь возможность справляться с более высокими требованиями по яркости, чем кодирование ранее созданного (LDR-)видео (которое также может называться в данном документе стандартным SDR-кодированием). Кодирование SDR-(LDR-)видео обычно должно выполняться с помощью стандарта Rec. 709 EOTF, который оптимально соответствует обычным характеристикам LDR-дисплея, имеющего пиковую яркость с приблизительно стандартным значением в 100 нит и уровень чёрного в 0,1 нит, и предполагается, что LDR-коррекция должна осуществляться с этими стандартными значениями. Изображение с расширенным динамическим диапазоном представляет собой любое изображение, не кодируемое исключительно посредством ранее созданного SDR-кодирования (хотя некоторые инструментальные средства и устройства на месте могут многократно использоваться, как пояснено ниже), поскольку оно обычно имеет характеристики с более высоким качеством изображений, в частности, пиковая яркость изображения может быть более высокой (по меньшей мере в 2 раза выше, чем 100 нит, но для обычных HDR-изображений более высокого качества, например, составлять PB на 1000 нит или PB на 5000 нит и т.д.). В случае если не упоминается дополнительная конкретика в отношении нижнего конца динамического диапазона яркости, неявно предполагается, что по меньшей мере для понимания вариантов осуществления этой заявки специалисты в данной области техники могут предполагать, что он составляет 0 нит.
Уровень техники
В последнее время на рынке появился ряд существенно отличающихся дисплеев, в частности, приёмные дисплеи для телевизионных сигналов (телевизионные приёмники) с существенно отличающейся пиковой яркостью. С учётом того, что в прошлом пиковая яркость (PB) так называемых ранее созданных дисплеев с узким динамическим диапазоном (LDR) отличалась самое большее примерно на коэффициент 2 (где-то между 80 и 150 нит), недавний тренд к постоянно повышающейся пиковой яркости приводит к так называемым телевизионным приёмникам с расширенным динамическим диапазоном (HDR) на 1000 нит и выше и к дисплеям с PB на 5000 нит, и предполагается, что скоро различные дисплеи с такими более высокими PB должны появиться на рынке. Даже в кинотеатрах в последнее время изучаются способы увеличивать окончательный динамический диапазон яркости, воспринимаемый зрителем. По сравнению со стандартным ранее созданным LDR-телевизором на 100 нит, например, дисплей на 2000 нит имеет на коэффициент 20 большую пиковую яркость, что составляет более 4 дополнительных доступных остановок, т.е. дополнительные способы подготавливать посредством рендеринга более яркие объекты в различных изображениях. С одной стороны, если также используется система формирования или захвата HDR-изображений нового поколения, она обеспечивает гораздо лучший рендеринг HDR-сцен или эффектов. Например, вместо (мягкого) отсечения солнечного мира вне здания или транспортного средства (что осуществляется в ранее разработанной LDR-коррекции), можно использовать дополнительную доступную яркость на оси яркости телевизионной HDR-палитры для того, чтобы отображать яркие и красочные области вне помещения. Это означает то, что создатель контента, который в неограничивающем смысле называется цветокорректировщиком (но он может быть осуществлён различными способами, например, при производстве телевизионного вещания вживую кто-либо, возможно, иногда регулирует только одну шкалу, затрагивающую некоторые свойства цвета, в частности, кодирования), имеет запас для того, чтобы создавать очень красивое выделенное HDR-изображение или видеоконтент (обычно более яркое, возможно, более контрастное и более красочное). Тем не менее, с другой стороны, это создаёт проблему: кодирование LDR-изображений спроектировано относительно начала с белого цвета и хорошо освещается согласно среднему серому цвету с 18%-м отражением, что означает то, что обычно подготовленные посредством рендеринга на дисплее яркости ниже 5% от относительно низкой PB, скажем, в 100 нит, обычно наблюдаются зрителем, поскольку трудно различать темно-серые цвета или даже, в зависимости от окружающего освещения, неразличимые чёрные цвета. На дисплее на 5000 нит, проблемы не возникают с этим оптимально скорректированным HDR-изображением: 5% от 5000 нит по-прежнему составляет 250 нит, так что это выглядит как обычное внутреннее пространство, например, и верхние 95% диапазона яркости могут использоваться просто для HDR-эффектов, таких как, например, ярко светящиеся лампы или области, близкие к таким лампам. Но в LDR, рендеринг этой HDR-коррекции будет проводиться совершенно неправильно (поскольку он также не создан для такого дисплея), и зритель, например, может только видеть чёткие пятна, соответствующие самым ярким областям на почти чёрной области.
В общем, требуются повторные коррекции для создания оптимальных изображений для дисплеев, которые в достаточной степени отличаются (разность в PB по меньшей мере на коэффициент 2). Это должно осуществляться при повторной корректировке изображения для дисплея с более узким динамическим диапазоном, чтобы обеспечивать его применимость для рендеринга на дисплее с более широким динамическим диапазоном (что представляет собой, например, повышение качества входного изображения(й) опорного дисплея на 1000 нит, т.е. которое должно выглядеть оптимальным на фактическом дисплее с PB на 1000 нит, которое затем подвергается обработке цветов для рендеринга на фактическом дисплее с PB на 5000 нит), в качестве обратного действия, т.е. понижения качества изображения таким образом, что оно является подходящим для отображения на фактическом дисплее с более низкой PB, чем опорный дисплей, ассоциированный с коррекцией, которая кодируется в качестве видеоизображений (причём эти изображения обычно передаются некоторым способом в приёмную сторону). Для краткости описан только сценарий, в котором качество HDR-изображения или изображений должно быть понижено до LDR.
Технология HDR (под которой подразумевается технология, которая должна позволять обрабатывать по меньшей мере некоторые HDR-изображения, которые могут иметь значительную сложность, т.е. высокую пиковую яркость, например, в 10000 нит, но которая также может работать с LDR-изображениями или изображениями со средним динамическим диапазоном и т.д.) проникает в различные области бытовых и профессиональных вариантов использования (например, камеры, устройства обработки данных как Blu-Ray-проигрыватели, телевизионные приёмники, компьютерное программное обеспечение, проекционные системы, системы безопасности или проведения видеоконференций и т.д.) требует технологии, допускающей обработку различных аспектов различными способами.
В WO2013/144809 (и WO2014/056679) заявитель обобщённо сформулировал технологию для выполнения обработки цветов для получения изображения (Im_res), которое подходит для динамического диапазона другого дисплея (обычно для PB, достаточной для того, чтобы характеризовать различные динамические диапазоны отображения и в силу этого оптимально скорректированные изображения, поскольку для нескольких сценариев можно игнорировать чёрную точку и допускать, что прагматично она составляет 0) по сравнению с динамическим диапазоном опорного дисплея, ассоциированного с входным изображением (Im_in), т.е. которая по существу формулирует PB дисплея, для которого изображение создано как оптимально выглядящее, что формирует хороший уровень техники для описанного ниже изобретения, в который следует вносить усовершенствования. Принципы кратко переформулированы снова на фиг. 1. Тем не менее, читатели должны понимать, что некоторые свойства примера уровня техники являются релевантными в контексте настоящих вариантов осуществления, а некоторые не присутствуют в общем HDR-кодировании, и в настоящих вариантах осуществления и идеях отсутствуют ограничения, поскольку можно работать с такими различными технологиями на основе кодеков HDR-видео (или изображений).
В частности, релевантным является то, что предусмотрено два внешних вида с различным динамическим диапазоном, которые могут быть связаны между собой через преобразование цветов (например, как поясняется на фиг. 4, можно выбирать значительное понижение яркости или эквивалентно сигнала яркости (которые представляют собой коды, кодирующие соответствующие сигналы яркости, например, обычно в 10- или 12-битовое представление) уличного освещения, и сжимают все такие объекты изображений с высокой яркостью в небольшом поддиапазоне LDR-диапазона яркостей). Хотя варианты осуществления также могут работать в системах, которые передают некоторую кодификацию эталонного HDR-изображения в любую приёмную сторону, предполагается, что в нижеприведённых пояснениях используется вариант осуществления передачи LDR-коррекции вместо HDR-изображений, но вместе с метаданными, которые кодируют функции преобразования цветов (некоторые из которых могут работать в плоскости цветности, но внимание акцентируется главным образом на преобразованиях яркости), позволяющие приёмному устройству повторно вычислять близкое восстановление эталонного HDR-скорректированного изображения (Im_in_HDR) HDR-сцены. Это позволяет приёмному устройству с HDR-характеристиками подготавливать посредством рендеринга HDR-изображения на соединённом HDR-дисплее, но также и подготавливать посредством рендеринга ранее созданные LDR-изображения для людей, которые по-прежнему имеют LDR-телевизор или компьютерный монитор, проектор, портативный дисплей и т.д.
Этот принцип является применимым (собираемым) обобщенно, т.е. не должны предполагаться какие-либо конкретные ограничения относительно цветового формата входного изображения, как и выходного изображения, и цветового пространства, в котором происходит обработка цветов, в частности, если предшествующий уровень техники упоминает некоторую конкретную линейную RGB-обработку, в данном документе явно указывается то, что было изобретено, и описаны некоторые обработки в нелинейном цветовом пространстве и стратегии кодирования на основании вышеуказанного.
Различные пикселы входного изображения Im_in последовательно подвергаются обработке цветов посредством преобразователя 100 цветов (который, как здесь предполагается, постоянно размещается в видеокодере, получает HDR-видео, которое должно быть кодировано, в качестве ввода, и выводит LDR-изображения, которые, несмотря на это, по-прежнему оптимально также содержат HDR-информацию, хотя находятся в повторно скорректированном внешнем LDR-виде), посредством умножения линейных RGB-значений на коэффициент (a) умножения посредством умножителя 104, чтобы получать выходные цвета RsGsBs пикселов в выходном изображении Im_res. Коэффициент умножения устанавливается из некоторой спецификации тонального отображения, которая обычно может создаваться человеком-цветокорректировщиком, но также может исходить из алгоритма автоматического преобразования, который анализирует характеристики изображения(й) (например, гистограмму или свойства цвета специальных объектов, таких как лица и т.д.). Функция отображения, например, может быть приблизительно гаммаобразной, так что более тёмные цвета усиливаются (что требуется для того, чтобы делать их более яркими и более контрастными для рендеринга на LDR-дисплее), за счёт снижений контрастности для ярких областей, которые должны становиться пастелизованными на LDR-дисплеях. Корректировщик дополнительно может идентифицировать некоторый специальный объект, такой как лицо, для яркостей которого он создал часть с увеличенной контрастностью на кривой. В частности, эта кривая применяется к максимуму цветового R-, G- и B-компонента каждого пиксела, называемому M (определённому посредством блока 101 оценки максимумов), посредством блока 102 применения кривых (который в недорогом варианте может представлять собой, например, LUT, которая может вычисляться, например, в расчёте на снимок изображений на приёмной стороне, которая выполняет обработку цветов, обычно после приёма параметров, кодирующих функциональную форму отображения, например, гамма-коэффициент), но идентичные принципы также могут работать, если M является яркостью или некоторым нелинейным представлением светлоты или яркости, таким как, например, сигнал яркости или степень 1/N яркости, при этом N, например, является некоторым целым числом и т.д. Затем блок 103 вычисления коэффициентов умножения вычисляет подходящий коэффициент (a) умножения для каждого текущего обрабатываемого пиксела. Он, например, может представлять собой вывод функции F тонального отображения, применяемой к M, т.е. F(M), деленную на M, если изображение должно подготавливаться посредством рендеринга на первом целевом дисплее, скажем, например, на LDR-дисплее на 100 нит. Если изображение необходимо, например, для промежуточного дисплея, например, с PB на 800 нит (или с другим значением, возможно выше PB опорного дисплея входного HDR-изображения Im_in), то дополнительная функция G может применяться к F(M)/M, повторно масштабирующая объем мультипликативного отображения входного цвета в значение, подходящее для динамического диапазона отображения, для которого годится изображение (независимо от того, непосредственно оно подготавливается посредством рендеринга на дисплее либо передается или сохраняется в некотором запоминающем устройстве для последующего использования). Он представляет собой способ для того, чтобы представлять некоторое отображение яркости, которое может быть достаточно сложным, в качестве умножения. Хотя в уровне техники, который приведён для пояснения знания уровня техники для этого изобретения, обычно возможно умножение линейных RGB-компонентов, следует подчеркнуть, что варианты осуществления настоящего изобретения также могут продолжать работать для нелинейных, например, обычно RGB, представлений цветов, например, преобразованных по стандарту Rec. 709 OETF R'G'B'-компонентов или степеней R, G и B обычно со значением степени, меньшим 1, например, 1/2.
Часть, которая описана выше, составляет глобальную обработку цветов. Это означает то, что обработка может осуществляться только на основании конкретных значений цветов (и внимание акцентируется только на яркостях этих цветов) последовательного набора пикселов. Таким образом, если пикселы получаются просто, например, из набора пикселов в рамках круговой подвыборки изображения, обработка цветов может выполняться согласно вышесформулированному принципу. Тем не менее, поскольку человеческое зрение является очень относительным, а также пространственно относительным, за счёт чего цвета и яркость объектов определяются относительно колориметрических свойств других объектов в изображении (а также с учетом различных технических ограничений), усовершенствованные системы HDR-кодирования имеют такой вариант, чтобы выполнять локальную обработку. В некотором изображении(ях), желательно изолировать один или более объектов, таких как лампа или лицо, и выполнять выделенную обработку для этого объекта. Тем не менее, снова следует подчеркнуть, что в представленной здесь технологии, это является частью кодирования по меньшей мере одной дополнительной коррекции, извлекаемой из изображения пикселов эталонной коррекции (здесь LDR, извлекаемый из HDR), а не просто некоторой изолированной обработки цветов. Поскольку более простые варианты на рынке не используют локальную обработку (хотя она концептуально является аналогичной, но приводит к более сложным интегральным схемам), и нижеприведённые принципы могут поясняться без этой конкретики, далее не приводится более подробная информация по этому аспекту.
Эталонная коррекция или извлечённая коррекция может фактически передаваться в приёмную сторону, в качестве изображений, кодирующих пространственную структуру т.е. объекты изображенной сцены, и если функции преобразования цветов, кодирующие взаимосвязь между двумя внешними видами, также передаются в метаданных, то другие коррекции затем могут повторно вычисляться на приёмной стороне. Иными словами, обработка цветов, например, требуется для того, чтобы конструировать посредством декодирования LDR-изображение при необходимости в случае, если HDR-изображения приняты, или наоборот, посредством восстановления HDR-изображений в случае, если пара внешних видов LDR-изображения передана или сохранена. Тот факт, что принцип локальной обработки используется в технологии кодирования, имеет такие технические последствия, в числе прочего, что требуется простой набор базовых математических способов обработки, поскольку все IC или программное обеспечение для декодирования в работе должны реализовывать это и за приемлемую цену, чтобы иметь возможность понимать кодирование и создавать LDR-изображение(я) декодера.
При проектировании прагматично полезных технологий кодирования для различных рынков применения изображений или видео, техническое ограничение заключается в том, что с точки зрения IC (поскольку также дешевым устройствам, возможно, требуются простые IC либо части площади IC, либо программное обеспечение), инструментальных средств функции кодирования должно быть немного, и они должны интеллектуально выбираться, чтобы выполнять то, что больше всего необходимо для создания и кодирования изображений внешнего вида с различным динамическим диапазоном на сцене (так что любой «корректировщик» или создатель контента в любом варианте создания контента получает требуемый результат в виде создания (достаточно близко к своим потребностям) пары внешних видов HDR/LDR-изображения и их соответствующего кодирования для хранения или обмена). С другой стороны, другая проблема означенного состоит в том, что при использовании вышеописанной философии, в которой, например, цветокорректировщик-человек указывает повторную коррекцию, кодированную, например, посредством LDR-изображения, и действует с возможностью повторной корректировки в подходящее HDR-изображение в любом приёмном устройстве на приёмной стороне, в наборе оптимальных параметров для конкретного вида данной сцены, корректировщик также должен иметь правильные инструментальные средства коррекции/кодирования и в правильном порядке, так что он может легко работать с ними (он должен не только получать хорошую точность требуемого внешнего вида цвета, но он должен достигать этого за минимально возможное количество операций, с тем чтобы быстро и эффективно получать желательный внешний вид, поскольку время также является существенным). Этот двойной противоположный набор ограничений должен обеспечиваться разумным способом. Кроме того в случае, если LDR-изображения передаются в любое приёмное устройство, предусмотрен даже третий критерий, который следует рассматривать, и технологические решения, как указано ниже, должны по меньшей мере примерно удовлетворять ему, а именно, что при проектировании некоторого изображения(й) внешнего LDR-вида, восстановление HDR-изображений посредством декодера HDR приёмного устройства должно по-прежнему иметь достаточную точность, так что это также обеспечивает влияние результирующих оптимальных технических блоков устройства для общих кодеров и декодеров HDR по мере того, как они изобретаются.
Источник Hattori и др.: "HLS: SEI message for Knee Function Information", 16. JCT-VC MEETING; 01.09.2014, Сан-Хосе, описывает новое SEI-сообщение для указания взаимосвязи между входными HDR-яркостями, во входном динамическом диапазоне, например, вплоть до 1200% от уровня белой сцены (т.е. кодами вплоть до 1200 нит) и LDR-сигналами яркости, на основании одной или более точек перегиба. Точка перегиба представляет собой искусный приём для решения проблемы, состоящей в том, что цифровые датчики, при освещении согласно допущению мира со средним серым цветом, имеют проблематичную тенденцию жёсткого отсечения объектов сцены, которые лишь немного ярче белой сцены (которая примерно в 5 раз ярче средней серой сцены). Идея состоит в том, что если имеется лучший датчик с меньшим шумом для меньших яркостей сцены, то можно немного недоэкспонировать сцену, что обеспечивает возможность различения различных, более ярких, чем белая сцена (например, белое платье невесты при оптимальном освещении сцены), яркостей сцены, например, до 4-кратного уровня белой сцены (вместо прямого отсечения до кодирования белого цвета, сигнал яркости Y'=255 в 8 битах, выше, например, 1,2-кратного уровня белой сцены). Конечно, точный захват таких больших яркостей сцены в датчике камеры представляет собой только часть решения, поскольку также по-прежнему требуется искусный приём для того, чтобы выделять фактический 8-битовый код сигнала яркости для определённых аналоговым датчиком (относительно максимальной, при этом записываемой яркости сцены или 1,0) яркостей сцены, при вычислении SDR-изображения для потребления, например, при рендеринге с хорошим качеством изображений на SDR-дисплее с PB на 100 нит. Простое сжатие всех цветов на оси выходного SDR-сигнала яркости представляет собой изящное решение для того, чтобы иметь возможность вписываться в 4-кратный или даже 12-кратный верхний диапазон, поскольку в таком случае более тёмные объекты, которые также должны быть хорошо экспонированы с тем, чтобы быть хорошо видимыми, могут быть слишком тёмными для хорошего качества SDR-изображений. Таким образом, предложена технология, которая сохраняет классическое (Rec. 709) выделение сигналов яркости для более тёмных сигналов яркости вплоть до точки перегиба, и выше этой точки перегиба используется более сжатая, обычно логарифмическая стратегия выделения кодов сигнала яркости, так что гораздо больший верхний диапазон входных яркостей (например, диапазон от 1-кратного уровня белой сцены до 4-кратного уровня белой сцены) может преобразовываться в верхний диапазон кодов сигнала яркости, например, верхние 10%, в зависимости от позиции точки перегиба (или в случае, если требуется сжимать существенное число больших, чем белая сцена, яркостей в SDR-изображении, можно выбирать точку перегиба при 50% диапазона сигнала яркости, т.е. 128 при 8 битах или 512 при 10 битах, но в таком случае внешний вид цвета изображения, хотя и смотрибельный, может начинать существенно ухудшаться). Hattori вводит технологию и практический способ для того, чтобы быстро передавать всю необходимую информацию в декодеры, которым требуется эта информация для того, чтобы применять обратную функцию, чтобы выполнять восстановление HDR-изображения при приёме SDR-изображения, на основании одной или более таких точек перегиба. Механизм с использованием точек перегиба не является хорошим способом для того, чтобы точно управлять внешним видом SDR-изображения. Тем не менее, он представляет собой простой способ изгибать более широкий динамический диапазон (input_d_range) с помощью простой быстрой функции, непрерывно изгибающей более высокие поддиапазоны яркости в меньшие поддиапазоны SDR-сигнала яркости (при условии, что это не будет проблематичным, что не обязательно является истинным, если имеется важный контент изображений, например, в самых ярких областях, таких как, например, облака, которые могут иметь красивые яркие значения серого цвета, которые могут уничтожаться в силу неправильной простой логарифмической части функции перегиба), в частности, когда коэффициент Kx, указывающий значение вплоть до того, во сколько раз выше белой сцены яркости по-прежнему должны быть кодируемыми, не является слишком высоким (т.е. сцены с динамическим диапазоном от среднего до расширенного). Очевидно, что этот документ не изучает простую высокоприменимую приблизительную функцию коррекции, которая является, в частности, применимой, когда корректировщик-человек хочет точно оптимизировать вид изображения (в отличие от Hattori, которая является просто математической спецификацией некоторого достаточно рабочего отображения яркости в сигнал яркости, которое может вслепую использоваться посредством любого автоматического устройства, поскольку его единственная цель заключается в том, чтобы кодировать только изображение внешнего HDR-вида, т.е. восстанавливаемое на приёмной стороне и не обязательно и художественно выглядящее лучше всего SDR-изображение, заявитель захотел спроектировать систему, которая, хотя в некоторых вариантах осуществления также работает (полу)автоматически, должна с использованием идентичных принципов кодирования также обслуживать рынки, которые характеризуются требованиями к художественной точности, такие как точность цветокоррекции человеком-цветокорректировщиком в голливудском фильме). Более конкретно, даже когда также управление подобластью с точными тёмными и яркими цветами изображения HDR-сцены не изучается, очевидно, отсутствует идея среднего параболического сегмента, и при этом Hattori не указывает на возможность проведения исследования по HDR, которое необходимо, чтобы добиться такой реализации.
US 2015/010059 также содержит эту такую же кривую точек перегиба (модель 3: число точек поворота), передаваемую в качестве идеи SEI-изображений, а также содержит идею S-кривой, которая является только другой возможной кривой отображения HDR-SDR, не связанной с идеями настоящей заявки.
Источник Zicong Mai и др.: "Optimizing the Tone Curve for Backward-Compatible High Dynamic range Image and Video Compression", IEEE Transactions on image processing, издание 20, № 6, июнь 2011 г., также представляет собой способ передачи восстанавливаемых HDR-изображений фактически в виде SDR-изображений, но существенно отличающимся способом, а именно посредством вычисления оптимальной относительно изображений формы функции отображения, которая определяется на основании гистограммы яркости входного изображения (чтобы не выделять слишком мало кодов большим областям, что может вводить полосатость, см. фиг. 3).
WO2014/178286 снова также представляет собой кодер на основании точек перегиба (фиг. 3), что обеспечивает включение в SDR-код немного больших, чем белая сцена, яркостей сцены (Nx). Это затем может использоваться для того, чтобы подготавливать посредством рендеринга HDR-изображения (которые добавляют достаточную яркость в самые яркие объекты) на HDR-дисплеях, которые имеют в Nx раз большую пиковую яркость, чем SDR-дисплеи, например, когда N равно 8 или 10 (фиг. 7).
WO 2014/128586 также содержит различные технические идеи, чтобы передавать HDR-изображения HDR-сцены фактически в качестве SDR-изображений, применимых для прямого рендеринга на ранее созданных SDR-дисплеях, уже развернутых в большом количестве в помещениях зрителей. Она изучает то, что иногда конкретная для изображения высоконастраиваемая форма кривой отображения яркости может быть полезной (фиг. 8), но вообще не изучает то, что настоящая приблизительная функция может быть очень полезной функцией в практическом HDR, передаваемой совместно с соответствующей скорректированной SDR-технологией.
Ничто из уровня техники не указывает в направлении разумной простой системы кодирования HDR в соответствии с настоящей заявкой, которая позволяет даже критически настроенным цветокорректировщикам эффективно добиваться SDR-изображения хорошего качества для всех практических целей.
Раскрытие изобретения
Вышеуказанная проблема практически применимой системы кодирования, которая является как достаточно вычислительно простой для выполнения посредством IC на видеоскорости, так и при этом также достаточно гибкой и удобной для корректировщика, чтобы указывать любой подробный внешний вид цвета для отображения на любом намеченном дисплее (по меньшей мере на HDR-дисплее и на другом обычно ранее созданном LDR-дисплее, но кодирования предпочтительно выглядят хорошими в диапазоне дисплеев по меньшей мере между HDR-дисплеем, для которого кодируется внешний HDR-вид, и LDR-дисплеем, для которого совместно кодируется внешний LDR-вид, посредством параметров, указывающих функциональное преобразование цветов для повторной коррекции, начинающееся с HDR-изображения, причём оба изображения обычно задаются в качестве 10-битовых слов, масштабированных до [0,1]), разрешается посредством видеодекодера (250) HDR, содержащего устройство (200) обработки цветов изображений, выполненное с возможностью преобразования входного цвета (Y'UV_LDR) пиксела входного изображения (Im_in), причём это входное изображение имеет первый динамический диапазон (DR_1) яркости, в выходной цвет (R'o, G'o, B'o) компонентов красного, зеленого и синего цвета пиксела выходного изображения (Im_res; REC_HDR), причём это выходное изображение имеет второй динамический диапазон (DR_2) яркости, за счёт чего пиковая яркость первого динамического диапазона по меньшей мере в 2 раза ниже пиковой яркости второго динамического диапазона, или наоборот, содержащий блок (202; 552) приблизительного отображения, выполненный с возможностью применения трёхсегментной кривой повторной коррекции яркости, которая состоит из линейного сегмента для темного поддиапазона (SR_d) диапазона сигналов яркости цветов входных изображений, содержащих самые тёмные значения входного сигнала яркости, который определяется посредством переменной (InvBet) наклона, второго линейного сегмента для самых светлых значений входного сигнала яркости в ярком поддиапазоне (SR_br), который управляется посредством второй переменной (InvAlph) наклона, и параболического сегмента между двумя линейными сегментами.
Сторона создания, например, пользователь, настраивающий параметры, может определять необходимые наклоны в зависимости от свойств HDR-сцены либо её изображения, и во-вторых при необходимости, от свойств кодирования, с помощью которого должно кодироваться изображение. Если обычно выходное изображение кодирования (представляющее собой входное изображение, которое должно принимать приёмные устройства и их внутренние декодеры) представляет собой SDR-кодирование по стандарту Rec. 709 с PB в 100 нит, например, корректировщик (или алгоритм автоматического определения кривой на основании измеренных характеристик изображений), например, может определять форму кривой для PB входного эталонного HDR-изображения (например, PB на 5000 нит в сравнении с PB на 1000 нит). Но он также может определять точную форму на основании контента. Например, если имеется большой объем тёмного контента, к примеру, мотоцикл на фиг. 4, корректировщик может захотеть иметь его с относительно глубокой яркостью в рендеринге HDR-изображений на HDR-дисплее (например, PB в 2000 нит), но в качестве относительно сильно выделяемого яркостью в кодировании LDR-изображений HDR-сцены (который должен выглядеть видимым, если подготовлен посредством рендеринга на обычном SDR-дисплее). Создатель уже также может учитывать обычную конкретику кодирования LDR-изображений, такую как, например, число битов, которые, например, HEVC-кодек использует для кодирования LDR-изображений. Некоторые варианты осуществления декодера могут автономно определять параболическую область между линейными сегментами, например, всегда фиксированные 20% от диапазона входного сигнала яркости или процентную долю в зависимости от наклона двух сегментов (например, больше, если разность в наклоне больше), или даже на основании характеристик текущего снимка изображений, например, того, имеется или нет значительная детальность в среднем диапазоне яркости выше тёмного диапазона, либо того, существуют или нет плавные градиенты, и т.д.
Тем не менее, в других вариантах осуществления, корректировщик или, в общем, создатель может указывать ширину параболической области, например, он может указывать две ширины W1 и W2 (представляющие собой то, из какой точки параболическая часть изменяется на линейную часть) из некоторой заданной точки, которую может устанавливать декодер, например, в которой линейные части, если их продолжать, должны пересекаться. Альтернативно, он может передавать это в качестве одного значения ширины. Единственное необходимое требование заключается в том, что декодер может применять обратную трёхсегментную функцию повторной коррекции яркости для того, чтобы получать из принимаемого LDR-изображения(й) восстановленное изображение внешнего HDR-вида HDR-сцены. В различных вариантах осуществления, можно либо отправлять параметры вогнутой функции с изгибом вверх, как показано на фиг. 2 (т.е. InvBet, InvAlph) или аналогично он может отправлять параметры кривой снижения качества (alph, bet). Одна кривая может быть легко преобразована в другую, например, можно устанавливать LUT равной требуемой точности и затем менять местами оси, так что специалисты в данной области техники должны понимать, что для простоты пояснения речь идет об обоих вариантах в фактических реализациях. В общем, при необходимости может быть предусмотрено два дополнительных параметра, например, смещение Wh_o белого цвета, которое предписывает то, куда в выходном диапазоне кодов LDR-сигнала яркости попадает самый яркий HDR-код (или обычно в других вариантах осуществления он также может задаваться на вертикальной оси из самой большей входной HDR-яркости или сигнала яркости, причём в этом случае HDR-цвета выше этого значения отсекаются в LDR-представлении), что может быть полезным или нежелательным в зависимости от конкретного варианта применения кодирования изображений. Аналогично может быть предусмотрено смещение B_o темного, которое корректировщик может определять на основании других принципов, поскольку цветопередача тёмных цветов на дисплеях отличается от цветопередачи ярких цветов. Таким образом, может быть полезным в общей системе иметь вариант осуществления кодера, который обеспечивает 5 параметров, alph, bet, W (=W1+W2 и заданный предварительно согласованным способом, например, 50% по обе стороны от точки 303 пересечения), B_o и Wh_o.
Для простых вариантов осуществления достаточно трёхсегментной кривой. Усовершенствованные варианты осуществления могут применять дополнительные преобразования цветов. Например, первый блок 224 предварительного преобразования цветов может применять преобразование перед применением трёхсегментной кривой, которая, например, может распределять цвета изображения(й) более равномерно, например, для человека-зрителя. Блок 203 постпреобразования цветов может применять другую функцию преобразования цветов, например, корректировщик может затемнять некоторую конкретную часть диапазона сигнала яркости по сравнению с внешним видом по яркости, обеспечиваемым трёхсегментной кривой. Блок 204 преобразования цветов в области может выполнять дополнительные преобразования цветового пространства, например, вместо получения результата по Y'o в области по методу квадратного корня или по стандарту Rec. 709, аналогично вычисления могут выполняться, например, в перцепционно линеаризованной области и т.д. Конечно, входные и выходные цветовые области обычно могут оказывать влияние на точную форму трёхсегментной кривой и её характерные 2, 3 или 5 параметров, как описано выше. В завершение, после выполнения требуемых преобразований цветов, которые приводят к результату, например, в стандарте Rec. 709, в виде некоторого определения HDR-сигнала яркости, например, с помощью PQ или даже спецификации линейного цветового R'o-, G'o-, B'o-компонента, блок 226 форматирования цветов дополнительно может указывать цвета в конечном цветовом RGB-пространстве, например, Rd, Gd, Bd, подходящем для непосредственного возбуждения соединённого дисплея, который обычно может представлять собой HDR-дисплей, ожидающий своего соединения для передачи изображений (кабельном или беспроводном), в виде некоторого определения HDR-изображения, например, обычно согласно некоторой заранее указываемой оптоэлектронной передаточной функции (OETF), которая может быть стандартной или конкретной для дисплея. Блок (203) применения настраиваемых функций обеспечивает то, что можно проектировать очень конкретную точную функцию на основании потребностей этой текущей HDR-сцены (в частности, того, насколько сложно компоновать между собой все яркости объектов в гораздо меньшем диапазоне LDR-яркости) в месте, в котором это может осуществляться (например, при достаточном количестве времени, вычислительных ресурсах и т.д.), т.е. обычно на стороне создания (причём информация формы этой функции передаётся в устройство на приёмной стороне). В частности, цветокорректировщик-человек может подстраивать нелинейную форму таким образом, чтобы изгибать её во всех надлежащих местах, соответствующих яркостям главных объектов или областей начального изображения. Он может так выделять яркостью, например, небольшую часть до любой яркости в извлечённом изображении согласно своим желаниям. В частности, если большая часть, например, сцены внутри помещения уже имеет корректную яркость, но некоторый небольшой фрагмент неба, видимый через окно, является слишком ярким или тёмным, пользовательская кривая CC может быть спроектирована таким образом, чтобы выполнять преобразование цветов только этих пиксельных цветов. Для некоторых конкретных вариантов осуществления, пользовательская кривая даже может быть спроектирована таким образом, что её градиент не опускается ниже минимального значения ни в одном месте вдоль входного диапазона. Система спроектирована таким образом, что она может подходить для различных видов систем обработки HDR-изображений или видео на будущем рынке (например, для широковещательной передачи, на основе LDR по существующим спутниковым каналам; по сравнению с Интернет-доставкой) и для различных видов контента (очень захватывающих художественных HDR-изображений из Голливуда, по сравнению с производством в полевых условиях, которое, оказывается, имеет динамический диапазон, который, оказывается, оно должно иметь), так что блок обработки пользовательских кривых обеспечивает реализацию безотносительно конкретного характера изменения сигнала яркости (яркости) для всех требуемых частей изображения, и в различных реализациях со столь большими или небольшими усилиями по реализации на стороне создания, с какими он, возможно, реализован.
Следующие неисчерпывающие варианты осуществления имеют конкретную применимость.
Видеодекодер (250) HDR по пункту 1 формулы, в котором устройство (200) обработки цветов изображений выполнено с возможностью применения трёхсегментной кривой к сигналам (Y'_LDR) яркости с узким динамическим диапазоном. Может быть полезным работать в некоторых конкретных областях, например, в области сигнала яркости одной из двух коррекций, например, обычно SDR-сигналов яркости.
Видеодекодер (250) HDR, в котором устройство (200) обработки цветов изображений выполнено с возможностью обеспечения в качестве результата применения трёхсегментной кривой выходного сигнала (Y'o) яркости, который связан с яркостью цвета, представляющей собой результат вывода применения трёхсегментной кривой ко входному цвету посредством степенной функции со степенью 1/N, при этом N предпочтительно равно 2.
Видеодекодер (250) HDR, в котором устройство (200) обработки цветов изображений выполнено с возможностью определения выходного цвета посредством включения умножителя (225), выполненного с возможностью применения умножения с использованием в качестве коэффициента умножения выходного сигнала (Y'o) яркости, к предпочтительно нелинейному представлению (R's, G's, B's) цветов для цвета текущего обрабатываемого пиксела.
Видеодекодер (250) HDR, в котором устройство (200) обработки цветов изображений выполнено с возможностью получения нелинейного представления (R's, G's, B's) цветов, которое технически задано из линейных цветовых R-, G, B-компонентов посредством нелинейной функции, которая является близкой по форме к функции вычисления квадратного корня и которая предпочтительно является степенной функцией со степенью 1/N, где N имеет целочисленное значение.
Видеодекодер (250) HDR, содержащий блок (277) считывания, выполненный с возможностью считывания из принимаемых метаданных первой и второй переменных наклона, и выполненный с возможностью их передачи в блок (202; 552) приблизительного отображения.
Видеодекодер (250) HDR, в котором блок (277) считывания дополнительно выполнен с возможностью считывания ширины параболической области (W_par) между двумя линейными сегментами из принимаемых метаданных, и выполнен с возможностью её передачи в блок (202; 552) приблизительного отображения.
Способ декодирования видео для получения HDR-видео из последовательных изображений в декодере, содержащий применение трёхсегментной кривой повторной коррекции яркости, которая состоит из линейного сегмента для темного поддиапазона (SR_d) диапазона сигналов яркости цветов входных изображений, содержащих самые тёмные значения входного сигнала яркости, который определяется посредством переменной (InvBet) наклона, второго линейного сегмента для самых светлых значений входного сигнала яркости в ярком поддиапазоне (SR_br), который управляется посредством второй переменной (InvAlph) наклона, и параболического сегмента между двумя линейными сегментами, который обеспечивает выходной сигнал (Y'o) яркости, который должен подаваться для умножения на предпочтительно нелинейное представление RGB-цветов (R's, G's'B's) входного цвета, подвергаемого преобразованию цветов.
Видеокодер (501) HDR, содержащий устройство (200) обработки цветов изображений, выполненное с возможностью преобразования входного цвета пиксела входного изображения (Im_in), причём это входное изображение имеет второй динамический диапазон (DR_2) яркости, в выходной цвет (Y'UV) пиксела выходного изображения (IMED), причём это выходное изображение имеет первый динамический диапазон (DR_1) яркости, за счёт чего пиковая яркость первого динамического диапазона по меньшей мере в 2 раза ниже пиковой яркости второго динамического диапазона, или наоборот, содержащий блок (503) приблизительного отображения, выполненный с возможностью применения трёхсегментной кривой повторной коррекции яркости, которая состоит из линейного сегмента для темного поддиапазона (SR_d) диапазона сигналов яркости цветов входных изображений, содержащих самые тёмные значения входного сигнала яркости, который определяется посредством переменной (InvBet) наклона, второго линейного сегмента для самых светлых значений входного сигнала яркости в ярком поддиапазоне (SR_br), который управляется посредством второй переменной (InvAlph) наклона, и параболического сегмента между двумя линейными сегментами.
Видеокодер (501) HDR, в котором устройство (200) обработки цветов изображений выполнено с возможностью применения трёхсегментной кривой к представлению цветов для входного цвета, который находится в нелинейной области, отличающийся тем, что его цветовые компоненты задаются посредством нелинейных функций на основании линейных аддитивных компонентов красного, зеленого и синего цвета.
Видеокодер (501) HDR, в котором устройство (200) обработки цветов изображений выполнено с возможностью применения трёхсегментной кривой к линейному представлению красного, зеленого и синего цвета входного цвета.
Видеокодер (501) HDR, в котором устройство (200) обработки цветов изображений выполнено с возможностью определения выходного цвета в представлении, содержащем нелинейный сигнал (Y'o) яркости, который связан с яркостью выходного цвета посредством нелинейной функции.
Видеокодер (501) HDR, в котором устройство (200) обработки цветов изображений выполнено с возможностью определения выходного цвета в представлении, заданном посредством кодирования видео со стандартным динамическим диапазоном, отличающийся тем, что цветовой компонент выходного сигнала (Y'o) яркости задается посредством оптоэлектрической передаточной функции по стандарту Rec. 709 или по методу квадратного корня.
Способ кодирования HDR-видео, обеспечивающий набор изображений HDR, кодированных в изображениях с узким динамическим диапазоном, содержащий преобразование входного цвета пиксела входного изображения (Im_in), причём это входное изображение имеет второй динамический диапазон (DR_2) яркости, в выходной цвет (Y'UV) пиксела выходного изображения (IMED), причём это выходное изображение имеет первый динамический диапазон (DR_1) яркости, за счёт чего пиковая яркость первого динамического диапазона по меньшей мере в 2 раза ниже пиковой яркости второго динамического диапазона, или наоборот, содержащий применение трёхсегментной кривой повторной коррекции яркости, которая состоит из линейного сегмента для темного поддиапазона (SR_d) диапазона сигналов яркости цветов входных изображений, содержащих самые тёмные значения входного сигнала яркости, который определяется посредством переменной (InvBet) наклона, второго линейного сегмента для самых светлых значений входного сигнала яркости в ярком поддиапазоне (SR_br), который управляется посредством второй переменной (InvAlph) наклона, и параболического сегмента между двумя линейными сегментами.
Машиночитаемое запоминающее устройство, содержащее код, который при выполнении посредством процессора должен применять все этапы по любому из вышеприведённых пунктов относительно способа и сигналов, будь то в запоминающих устройствах или в других технических средствах, содержащих информацию, позволяющую приёмному устройству технически функционировать с возможностью декодирования и восстановления принятых HDR-(как LDR-)изображений, т.е. посредством приёма некоторых данных и метаданных пикселизированных цветовых компонентов, указывающих трёхсегментную кривую, т.е. обычно вышеуказанных по меньшей мере двух или, предпочтительно, 5 параметров (alph, bet, W, Wh_o, B_o).
Краткое описание чертежей
Эти и другие аспекты любого варианта способа и устройства согласно изобретению должны становиться очевидными и поясняются со ссылкой на реализации и варианты осуществления, описанные далее в данном документе, и со ссылкой на прилагаемые чертежи, причём эти чертежи служат просто в качестве неограничивающих конкретных иллюстраций, демонстрирующих более общую концепцию, и на которых штрихи используются для того, чтобы указывать то, что компонент является необязательным, при этом нештриховые компоненты необязательно являются неотъемлемой частью. Штрихи также могут использоваться для указания того, что элементы, которые поясняются как важные, скрыты внутри объекта, либо для нематериальных вещей, таких как, например, выборы объектов/областей, индикаторы относительно уровней значений на диаграммах и т.д.
На чертежах:
Фиг. 1 схематично иллюстрирует возможное устройство обработки цветов, ранее изобретенное и запатентованное заявителем, для выполнения преобразования динамического диапазона, включающего в себя локальную обработку цветов, причём упомянутая обработка цветов обычно должна включать в себя по меньшей мере изменение яркостей объектов во входном изображении, которое поясняет некоторые принципы; тем не менее, предпочтительные варианты осуществления настоящего изобретения должны применяться с необходимыми изменениями нелинейных цветовых RGB-пространств и обычно их соответствующего сигнала Y' яркости; и
Фиг. 2 схематично иллюстрирует пример системы, которая выполнена с возможностью выполнения преобразования динамического диапазона для системы, которая может декодировать параметрическим способом и обеспечивать HDR-изображение из принимаемого LDR-изображения, т.е. за счёт чего хотя также внешний HDR-вид на HDR-сцене принят через метаданные, характеризующие функции преобразования цветов для извлечения изображения внешнего HDR-вида из принимаемого изображения внешнего LDR-вида, только пиксельные цвета LDR-изображения фактически передаются в приёмную сторону и принимаются;
Фиг. 3 показывает функциональную форму на стороне кодирования одного обычного трёхсегментного приблизительного начального отображения сигнала яркости для кодирования LDR из пиксельных цветовых данных HDR-изображений, при этом ввод, например, может находиться в области линейной HDR-яркости, а вывод (вертикальная ось), например, обычно находится в области LDR-сигналов яркости по методу квадратного корня в LDR;
Фиг. 4 проясняет, с помощью нескольких примеров, то, что технические и художественные проблемы обычно возникают для HDR-контента, который должен быть просматриваемым на дисплеях с более узким динамическим диапазоном, даже в случае установленной базы в виде ранее созданных SDR-дисплеев с пиковой яркостью (PB) на 100 нит; и
Фиг. 5 схематично немного подробнее поясняет примерную систему кодирования видео, в которой могут преимущественно использоваться варианты осуществления устройства и способа заявителя.
Осуществление изобретения
Фиг. 1 схематично показывает одно возможное преобразование цветов системы, чтобы кодировать (по меньшей мере) два скорректированных изображения (HDR-, например, с PB на 5000 нит и стандартное SDR-LDR- с PB=100 нит) для рендеринга на дисплеях с существенно отличающимся динамическим диапазоном (PB) и, в частности, блоке ядра преобразования цветов. Специалисты в данной области техники понимают, что эта система может постоянно размещаться как на стороне создания контента, на которой корректировщик-человек должен проводить вычисления, чтобы проверять на калиброванных дисплеях то, какие внешние виды он фактически создаёт, при одновременном указании на свой вкус оптимальных значений параметров функций коррекции в инструментарии функций кодирования, так и на приёмной стороне, на которой устройство может быть включено, например, в устройство приёма видео и обработки цветов, такое как абонентская приставка, BD-проигрыватель или компьютер либо непосредственно дисплей, либо профессиональная система в кинотеатре и т.д.
Поясняется приёмная сторона, на которой уже имеются данные, указывающие две коррекции (HDR и LDR, которые затем дополнительно могут быть оптимизированы посредством дополнительных вычислений для любого MDR-дисплея с промежуточным динамическим диапазоном, например, PB=800 нит).
Таким образом, согласно новым принципам кодирования, приёмное устройство фактически имеет только одно изображение, фактически кодированное (например, классически в 10-битовом HEVC-кодировании, хотя понятно декодируемое в нормализованное [0,1] изображение), Im_in_HDR, например, принимаемое на Blu-Ray-диске или через Интернет-соединение с видеосервером или по HDMI-кабелю из некоторого другого устройства и т.д. Это затем должно вычисляться в LDR-коррекцию, например, поскольку LDR-дисплей соединен, и ему требуется корректно скорректированное LDR-изображение (например, зритель решает прекращать просмотр HDR-дисплея в гостиной, но продолжать просмотр в постели на своем портативном планшете).
Чтобы иметь возможность осуществлять обработку цветов, устройству преобразования цветов также требуются параметры (CF), указывающие функции. Специалисты в данной области техники понимают, что, например, парабола может указываться посредством начальной и конечной точки и линейного начального наклона и искривления и т.д.
Обычно может быть предусмотрено управление насыщенностью как отображения из HDR в LDR, но также и по меньшей мере отображения, которое затрагивает яркости выходных объектов (хотя математически обычно это отображение яркости применяется посредством мультипликативного масштабирования линейных цветовых RGB-компонентов).
Фиг. 2 подробнее показывает то, как предпочтительно можно выполнять эту повторную коррекцию яркости.
Предполагается, что SDR-изображения поступают Y'UV- (или Y'CbCr-) кодированными. Они могут быть матрицированы в масштабированные RGB-компоненты R'sG'sB's пикселов входных изображений. Предполагается, что они находятся, например, в области сигнала яркости по методу квадратного корня (т.е. соответствующие линейные цветовые компоненты должны возникать посредством возведения в квадрат). Соответствующий Y'_LDR-сигнал яркости легко отделяется от Y'UV-представления. То, что эти значения R'sG'sB's фактически представляют собой некоторую масштабированную версию получаемых в конечном счёте цветовых HDR-компонентов (R'o, G'o, B'o), можно видеть на фиг. 4B, на котором показан один цвет LDR- и HDR-коррекций в идентичной нормализованной до сигнала максимальной яркости=1,0 цветовой RGB-палитре (например, первичных цветов по стандарту Rec. 2020 и т.д.). Если мотоцикл должен подготавливаться посредством рендеринга с идентичной абсолютной яркостью (5 нит) на LDR-дисплее при возбуждении с помощью LDR-изображения, которую он должен иметь HDR-дисплее при возбуждении с помощью HDR-изображения, это означает то, что его (относительный, нормализованный до единицы или до 1023 для 10-битовых кодов) LDR-сигнал яркости должен быть более высоким. Иными словами, преобразование цветов между цветовыми компонентами R'o, G'o, B'o и R's, G's, B's или наоборот, также соответствует масштабированию их соответствующих надлежащих яркостей или сигналов Y'_HDR, соответственно, Y'_LDR яркости, и именно оно должно быть реализовано посредством умножителя 225. В некоторых вариантах осуществления, R's, G's, B's могут непосредственно вычисляться из входного Y'UV-представления цветов, хотя в других вариантах осуществления, могут быть предусмотрены дополнительные преобразования цветов для того, чтобы добиваться различных значений R's, G's, B's, которые должны применяться посредством преобразователя 223 цветов (следует отметить, что все штриховые части чертежей являются необязательными, не для более простых вариантов осуществления на рынке, а для некоторых других вариантов осуществления). Он может применять дополнительную подстройку яркости и/или цветности, например, некоторое регулирование внешнего вида и т.д.
Блок (277) считывания затем обеспечивает данные, чтобы позволить блоку 202 приблизительного отображения применять надлежащую функцию, которая использована для того, чтобы совместно кодировать пару изображений внешнего HDR-вида/LDR, т.е. также то, как восстанавливать HDR-изображение из принимаемого LDR-изображения, например, он может передавать параметры или обеспечивать функцию в качестве LUT. Затем корректно масштабированный сигнал Y'o яркости, полученный из применения (по меньшей мере) отображения трёхсегментной кривой, используется в качестве входного множителя, на который следует умножать каждый из трех масштабированных цветовых компонентов, что обеспечивает корректный выходной цвет, который дополнительно может преобразовываться в другое представление цветов посредством блока 226 форматирования цветов.
Хороший вариант осуществления блока (202) приблизительного отображения должен применять функцию, такую как, например, на фиг. 3. Позиция параболического сегмента может определяться посредством кодирования начального и конечного значения сигнала яркости, но парабола также может быть кодирована как его ширина, как показано на фиг. 3. Ввод в этом примере не ограничивает яркость линейного RGB-представления, а именно, u_HDR_in и выходное TU_LDR_out представляют собой то, что при необходимости в конкретной системе использования впоследствии может подстраиваться посредством кривой пользовательской формы блока 203 или в противном случае отправляться в умножитель, чтобы получать корректный HDR-цвет для этого пиксельного обрабатывания.
В этом варианте осуществления, базовая «параболическая» кривая тонального отображения состоит из 3 сегментов:
- тёмный сегмент через (0, 0), который управляется посредством параметрического наклона bet или bg (базовое усиление)
- яркий сегмент через (u_max, TU_max), с наклоном alph или dg
(дифференциальное усиление)
- параболический сегмент, который соединяет их, с шириной xp
(парабола x-ширины)
Без параболы, 2 линейных сегмента соединяются в точке:
um=(TU_max-dg*u_max)/(bg-dg),
TUm=bg*um=TU_max-(u_max-um)*dg.
Непрерывно дифференцируемая кривая составляется посредством добавления параболы, которая центрируется вокруг нее (um, TUm), и она должна начинаться с наклоном=bg и заканчиваться с наклоном=dg. Из математического вычисления затем получается, что остается только 1 (из 3) степень свободы: ширина параболы xp.
В зависимости от ширины, значение y для u=um падает от:
TU=TUm для=0, до:
TU=TUm-delta_TU=TU-up*(bg-dg)/8.
Можно инвертировать это отношение для вычисления up из delta_TU:
up=8*delta_TU/(bg-dg).
Таким образом, обычно можно начинать с=0, затем видеть то, что максимальное расстояние delta_TU находится между изогнутой кривой и опорной кривой отображения яркости (диаграммы рассеяния) и вычислять up из этого.
Таким образом, в этом варианте осуществления, ширина (обычно между 0,0 и 1,0) параболического сегмента представляет собой третий параметр, указывающий эту функциональную форму, которая передается в любое устройство на приёмной стороне, в дополнение к наклону базового усиления (например, с обычными значениями между 0,5 для ярких изображений и 1,0 для тёмных изображений) и наклону диапазона самых светлых входных значений (обычно между 0,0 и 0,25).
На фиг. 4 наблюдается только два примера из множества возможных HDR-сцен, которые HDR-система будущего (например, соединённая с дисплеем с PB на 1000 нит), возможно, должна иметь возможность корректно обрабатывать, т.е. посредством создания надлежащих яркостей для всех объектов/пикселов в изображении, в подготавливаемом посредством рендеринга в конечном счёте изображении на любом соединённом или подлежащем соединению дисплее. Например, ImSCN1 представляет собой солнечное изображение на улице из ковбойского фильма, действие которого разворачивается в Техасе, и ImSCN2 представляет собой ночное изображение. Рендеринг HDR-изображений отличающимся от того, как это было всегда в LDR-эре, которая завершена только недавно (или фактически должна начинаться на рынке ближайшие годы), делает то, что LDR имеет такой ограниченный динамический диапазон (примерно PB=100 нит и уровень чёрного+- 1 нит или даже выше в более ярком окружении просмотра вследствие отражений от экрана), так что могут показываться главным образом только отражающие способности объектов (которые попадают между 90% для хорошего белого цвета и 1% для хорошего чёрного цвета). Таким образом, требуется показывать объекты независимо от их освещения, и одновременно нет возможности точно показывать все очень хорошие, иногда очень контрастные освещения сцены, которые могут возникать. На практике это означает то, что очень яркая солнечная сцена должна подготавливаться посредством рендеринга в качестве идентичных сигналов яркости дисплея (0-100 нит) с тусклой сценой в дождливый день. Кроме того, даже сцены в ночное время не могут подготавливаться посредством рендеринга слишком тёмными, либо зритель не должен иметь возможность хорошо различать самые тёмные части изображения, так что снова эти ночные яркости должны подготавливаться посредством рендеринга в диапазоне между 0 и 100 нит. Таким образом, следует традиционно окрашивать ночные сцены в синий цвет, так что зритель должен понимать, что он не смотрит на дневную сцену. Теперь, конечно, в реальной жизни человеческое зрение также должно адаптироваться к доступному количеству света, но не в очень большой степени (большинство людей в реальной жизни осознают, что темнеет). Таким образом, можно захотеть подготавливать посредством рендеринга изображения со всеми захватывающими локальными световыми эффектами, которые можно художественно проектировать в них по меньшей мере если имеется доступный HDR-дисплей.
Но это не изменяет тот факт, что для некоторых людей по-прежнему требуется понижать качество фантастического нового HDR-фильма до качества этого ограниченного LDR-дисплея (диапазон которого показан, не в точном масштабе, справа на фиг. 4).
Таким образом, слева наблюдается то, какие яркости объектов хочется видеть при эталонной HDR-коррекции с PB на 5000 нит (т.е. оптимизированной для рендеринга на дисплее с PB на 5000 нит). Если требуется передавать не только иллюзию, но и реальные ощущения нахождения ковбоя в ярком залитом солнцем окружении, следует указывать и подготавливать посредством рендеринга яркости около, например, 500 нит. Только из этих примеров уже можно получать ощущение того, что компоновка между собой всех объектов в меньшем диапазоне LDR-яркости в идеале не является вопросом простого сжатия (например, с линейной функцией, отображающей HDR PB в LDR PB и наряду с этим также все более низкие яркости). В отличие от этого, приведены два примера с различным классом характера изменения отображения яркости. Для сцены с дневным светом, если хочется вычислять HDR-изображение из принимаемого LDR-изображения, можно применять фактически функцию растягивания, которая растягивает все яркости таким образом, что, в частности, ковбой, подготавливаемый посредством рендеринга вокруг среднего серого LDR-цвета в 18 нит, преобразуется в 500 нит в HDR (т.е. яркость увеличивается приблизительно в 30 раз). Но это нельзя выполнять для ночной сцены, либо она становится чрезвычайно яркой на HDR-мониторе (фактическое погружение в детали, вследствие некоторой конкретики изображений мозг по-прежнему может предполагать, что он видит ночную сцену, даже когда слишком ярко, но она подготавливается посредством рендеринга далеко не идеально, если реально хочется захватывающего и высококачественного HDR-рендеринга, теперь, когда это стало возможным). Для этого ImSCN2, требуется, чтобы яркости всех тёмных объектов ночью были идентичными на двух дисплеях (и на всех дисплеях с промежуточной PB). В противном случае, он представляет собой свет осветительного столба и может быть луной, которая выделяется до гораздо большей яркости в HDR-изображении. Таким образом, форма функции отображения яркости должна существенно отличаться. Можно предполагать, что если имеются аспекты этих двух архетипичных изображений вместе в одном изображении, например, снятого внутри пещеры и просмотр солнечной обстановки на улице через маленькое отверстие, можно захотеть на деле проектировать сложные кривые отображения яркости, чтобы получать яркости LDR- и HDR-объектов согласно художественному желанию. В LDR-эре, такие ситуации обычно приводили к тому, что все, что за пределами пещеры, просто отсекалось до белого цвета. Альтернативно, поскольку в LDR-эре просто рассматривается то, что камера захватывает, в качестве относительных яркостей, независимо от смысла и того, что это подразумевает для окончательного рендеринга на любом дисплее, некоторые части изображения зачастую становятся слишком тёмными. Например, если Вы идете по коридору и видите, что солнце сияет, эти залитые солнцем пятна выглядят очень яркими. Другие части коридора являются относительно более тёмными, но это не означает то, что пользователь, идущий по нему, видит их немного более тёмными по сравнению с нормальными (фактически, вследствие дополнительного освещения, даже части в тени должны выглядеть в определённой степени более яркими, чем если солнце перемещается за облаками). Но LDR-рендеринг, помещающий эти солнечные цвета около белого цвета, может только подготавливать посредством рендеринга слишком тёмными теневые части коридора, поскольку в противном случае единственной вещью, которую он может выполнять в этом ограниченном диапазоне, представляет собой рендеринг тени с обоснованной яркостью, но в таком случае все на солнце отсекается выше максимального кода сигнала яркости, например, 255, соответственно, подготовленные посредством рендеринга 100 нит.
Таким образом, оптимальный LDR-рендеринг такой сцены является сложным вопросом проектирования, но по меньшей мере теперь с помощью HDR-дисплеев можно подготавливать посредством рендеринга солнечные части реалистично, т.е. выше определённой яркости. Например, если окружение просмотра соответствует примерно 200 нит, можно подготавливать посредством рендеринга затененные части изображения приблизительно в 200 нит. Кроме того, можно подготавливать посредством рендеринга залитые солнцем части (в зависимости от PB дисплея) на уровне, например, 2000 нит. Даже если они не всегда составляют полностью идентичную с реальной жизнью относительную величину выше теневой яркости по меньшей мере они выглядят гораздо более реалистичными, чем коридор, который является слишком тёмным или отсекается.
Но читатель понимает, зачем вся эта сложность, в частности, множество видов изображения, с которыми можно сталкиваться, и огромная разница по меньшей мере между некоторыми HDR-диапазонами более высокого качества (например, PB=10000 нит) и SDR-диапазоном на 100 нит требует системы, которая обеспечивает точную спецификацию различных пиксельных цветов и, в частности, их яркостей. Кроме того, заявитель, в частности, имеет такую философию, что следует позволять создателю контента оказывать влияние на то, как любое другое изображение динамического диапазона должно вычисляться из принимаемого изображения(й) по меньшей мере для тех, кто желает этого, и в какой степени они желают этого, и вплоть до того, что они минимально должны указывать.
Фиг. 5 показывает возможное включение базового устройства (или способа) изменения яркости в некоторую обычную полную систему или цепочку для обмена и потребления HDR-изображения(й). Специалисты в данной области техники должны понимать то, как, например, корректировщик может использовать UI-компоненты, чтобы изменять форму любых функций, например, их отличительных параметров, согласно своим потребностям или желаниям. Хочется подчеркнуть, что хотя пример поясняется для режима ii (в котором LDR-изображение, качество которого понижено относительно эталонного HDR-изображения MAST_HDR, которое создатель контента формирует, например, из своих необработанных захватов, фактически передается, а затем на приёмной стороне, при необходимости, восстанавливается в хорошую аппроксимацию MAST_HDR-изображения), варианты осуществления системы и устройства также могут использоваться при работе в режиме i, в котором фактически передается MAST_HDR-изображение, и устройство применяет снижение качества яркостей в приёмном устройстве в случае, если LDR-изображение необходимо для вывода в SDR-дисплей. Каждое из этих принимаемых LDR- или HDR-изображений также может преобразовываться в изображения с различным динамическим диапазоном, например, с PB на 1499 нит. Кроме того, варианты осуществления устройства также могут быть включены в устройство на стороне создания, например, в кодер, например, чтобы позволять цветокорректировщику проверять то, что происходит на приёмной стороне, и то, как с заданными функциями должно выглядеть LDR-изображение, вычисленное из MAST_HDR, и устройства и способы также могут использоваться в транскодерах в любом промежуточном местоположении, например, в кабине для просмотра дистрибьютора локального контента и т.д.
Видеокодер 501 в этой примерной схеме получает через ввод 509 входное изображение IM_IN, которое для простоты пояснения предполагается в качестве уже художественно созданной эталонной HDR-коррекции, но оно также может представлять собой HDR-изображение из некоторой необработанной трансляции изображений, которая должна подвергаться минимальной обработке цветов с небольшими помехами в реальном времени, может просто крутить ручку несколько раз во время захвата и т.д.
Также может быть предусмотрена обработка цветности, вычисляемая для пиксельных цветов посредством блока обработки цветности, например, изменение насыщенности, которое уменьшает насыщенность таким образом, что в LDR-преобразовании более яркие цвета, например, витража дополнительно могут выделяться яркостью посредством их проталкивания в узкое начало цветовой LDR-палитры около белого цвета, но эти подробности не поясняются. Затем блок 503 отображения яркости должен выполнять различные операции, которые выполняет любой из вариантов осуществления устройства, как показано на фиг. 2, например, униформизацию яркости и затем трёхсегментную кривую и при целесообразности некоторую функцию CC оптимальной формы, определённую для текущего набора изображений и, например, загруженную посредством взаимодействия через пользовательский интерфейс или из метаданных, кодирующих ранее определённую функцию. Некоторые варианты осуществления должны определять форму трёхсегментной кривой посредством инструктирования блока 566 анализа изображений анализировать характеристики изображения, к примеру, то, где находятся большинство пиксельных яркостей, размер и рассеянность подсвеченных участков и т.д. Средство 508 функционального ввода может пониматься посредством блока считывания в качестве, например, обычных инструментальных средств цветокоррекции или соединения с базой данных, сохраняющей по меньшей мере одну функцию или соединение с удаленным человеком-корректировщиком и т.д. Затем это промежуточное изображение IMED, которое теперь в этом примере представляет собой LDR-изображение с пиксельными яркостями, распределенными вдоль LDR-диапазона на 0-100 нит, и их соответствующими сигналами яркости по стандарту Rec. 709 (т.е. представляемыми по Y'o UV), кодируется с помощью обычной ранее разработанной технологии LDR-кодирования, такой как, например, HEVC посредством блока 505 кодирования изображений или видео. Это обусловлено тем, что оно «выглядит» как обычное LDR-изображение по меньшей мере для следующих технологий, таких как конвейер распространения изображений, через который оно должно проходить, несмотря на то, что оно фактически кодирует HDR-изображение HDR-сцены. Это сообщается любому приёмному устройством посредством также передачи функций преобразования цветов (или их обратных функций), используемых для формирования LDR-изображения из эталонного HDR-изображения, что сообщает приёмному устройству не только то, что он фактически принимает HDR-изображение вместо регулярного LDR-изображения, но также и позволяет приёмному устройству восстанавливать хорошую аппроксимацию MAST_HDR-изображения посредством применения этих принимаемых обратных функций к принимаемому LDR-изображению(ям). Таким образом, кодированное изображение или видео LDR_oenc фактически выступает в качестве нормального LDR-видео для остальной части системы, и оно должно перемещаться через некоторое средство 510 связи, которое, например, может представлять собой воздушную широковещательную передачу или Интернет-соединение, или физическое запоминающее устройство, транспортируемое в любое потребительское или профессиональное (например, кинотеатр) местоположение и т.д.
На приёмной стороне, это кодированное выходное изображение (LDR_oenc) становится входным изображением или видео LDR_ienc (возможно, оно по-прежнему подвергнуто дополнительному преобразованию, но для целей пояснения предполагается, что оно представляет собой идентичное изображение(я), циклически обрабатываемое). Вкратце следует отметить, что если используется система HDR-связи в режиме i в LDR_oenc, возможно, используется форма функций, отличная от формы функций в режиме ii, что придает изображению различные яркости объектов и статистику, но при этом, например, с подверганием HEVC-кодированию.
Видеодекодер 550 получает через свой ввод 556 как изображения, так и метаданные MET(F), кодирующие функции, в частности, оптимальную пользовательскую кривую, которая выбрана на стороне создания, например, цветокорректировщиком или некоторым другим пользователем, таким как ассистент режиссера для производства вещания вживую и т.д. Блок (555) декодирования изображений или видео декодирует HEVC-видео, и затем оно подвергается обработке цветов посредством блока 552 преобразования яркости, осуществляющего любые варианты осуществления устройства или способа (т.е. применение надлежащей обратной трехчастной функции для восстановления HDR-изображения по меньшей мере приблизительно). В завершение, корректно скорректированное REC_HDR-изображение(я), например, с PB на 5000 нит может отправляться на дисплей 580, например, дисплей на 5000 нит в идеале (в случае рассогласования PB между HDR-контентом и дисплеем, либо этот видеодекодер, например, встроенный в STB, может уже настраивать отображение изображение посредством надлежащего преобразования цветов в требуемую PB дисплея, например, на 2500 нит, либо дисплей может осуществлять это внутренне в силу наличия собственной версии изученных устройств/способов). Конечно, если для ранее созданного дисплея на 100 нит SDR должен обеспечиваться надлежащим образом скорректированный контент, видеодекодер 550 может выдавать LDR-изображение LDR_rnd в него, которое в этом примере может представлять собой просто принимаемые декодером LDR-изображения без необходимости дополнительного преобразования цветов, но в случае приёма HDR-изображений в LDR HEVC-контейнерах, видеодекодер 550 по-прежнему должен выполнять надлежащее снижение качества согласно любому из вариантов осуществления устройства/способа.
Алгоритмические компоненты, раскрытые в настоящем документе, могут (полностью или частично) быть реализованы на практике в качестве аппаратных средств (например, частей специализированной IC) либо в качестве программного обеспечения, запущенного на специальном процессоре цифровых сигналов или общем процессоре и т.д. Они могут быть полуавтоматическими в том смысле, что по меньшей мере некоторый пользовательский ввод может присутствовать (например, на фабрике или потребительский ввод, или другой человеческий ввод).
Специалисты в данной области техники должны понимать из представления то, какие компоненты могут быть факультативными улучшениями и могут быть реализованы в комбинации с другими компонентами, и то, как (факультативные) этапы способов соответствуют надлежащему средству устройств, и наоборот. Тот факт, что некоторые компоненты раскрыты в изобретении в определённой взаимосвязи (например, на одном чертеже в определённой конфигурации), не означает того, что другие конфигурации являются невозможными в качестве вариантов осуществления при идентичном изобретательском мышлении, которое раскрыто для патентования в данном документе. Кроме того, тот факт, что по прагматичным причинам описан только ограниченный спектр примеров, не означает то, что другие варианты не могут подпадать в пределы объема формулы изобретения. Фактически, компоненты изобретения могут быть осуществлены в различных вариантах вдоль любой цепочки использования, например, все варианты стороны создания, такие как кодер, могут быть аналогичными или соответствовать надлежащим устройствам на стороне потребления разлагаемой системы, например, декодеру, и наоборот. Несколько компонентов вариантов осуществления могут быть кодированы как конкретные сигнальные данные в сигнале для передачи или дальнейшего использования, к примеру, для координации, в любой технологии передачи между кодером и декодером и т.д. Слово «устройство» в этой заявке используется в самом широком смысле, а именно, как группа средств, обеспечивающих реализацию конкретной цели, и в силу этого, например, может представлять собой (небольшую часть) IC или выделенное устройство (к примеру, устройство с дисплеем), или часть сетевой системы и т.д. «Узел» или «система» также предназначены для использования в самом широком смысле, так что они могут содержать, в числе прочего, одно физическое, приобретаемое устройство, часть устройства, совокупность (частей) взаимодействующих устройств и т.д.
Следует понимать, что обозначение компьютерного программного продукта охватывает любую физическую реализацию совокупности команд, позволяющих процессору общего или специального назначения после последовательности этапов загрузки (которая может включать в себя этапы промежуточного преобразования, такие как трансляция на промежуточный язык и конечный процессорный язык), с тем чтобы водить команды в процессор, чтобы выполнять любую из характеристических функций изобретения. В частности, компьютерный программный продукт может быть реализован в качестве данных на носителе, таком как, например, диск или лента, данных, присутствующих в запоминающем устройстве, данных, перемещающихся через сетевое соединение (проводное или беспроводное), либо программного кода на бумаге. Помимо программного кода, характерные данные, требуемые для программы, также могут быть осуществлены как компьютерный программный продукт. Такие данные могут (частично) обеспечиваться любым способом.
Изобретение или любые данные, применимые согласно любой философии настоящих вариантов осуществления, такие как видеоданные, также могут быть осуществлены в качестве сигналов на носителях данных, которые могут представлять собой съемные запоминающие устройства, такие как оптические диски, флэш-память, съемные жесткие диски, портативные устройства, записываемые через беспроводные средства, и т.д.
Некоторые этапы, требуемые для работы любого представленного способа, могут уже присутствовать в функциональности процессора или любых вариантов осуществления устройства изобретения вместо описания в компьютерном программном продукте либо в любом блоке, устройстве или способе, описанном в данном документе (с конкретикой вариантов осуществления изобретения), к примеру, этапы ввода и вывода данных, известные обычно включенные этапы обработки, такие как стандартное возбуждение дисплея и т.д. Также требуется защита для результирующих продуктов и аналогичных результантов, таких как, например, конкретные новые сигналы, предусмотренные на любом этапе способов или в любой подчасти устройств, а также для всех новых применений таких сигналов или любых связанных способов.
Следует отметить, что вышеуказанные варианты осуществления иллюстрируют, а не ограничивают изобретение. Если специалисты в данной области техники могут легко понять соотнесение представленных примеров с другими областями формулы изобретения, для краткости все эти варианты не упоминаются всесторонне. Помимо комбинаций элементов изобретения, комбинированных в формуле изобретения, возможны другие комбинации элементов. Любое сочетание элементов может быть реализована в одном выделенном элементе.
Любое условное обозначение, указанное в скобках в формуле изобретения, не предназначена для ограничения формулы изобретения, также как и конкретный символ на чертежах. Слово «содержащий» не исключает присутствия элементов или аспектов, не перечисленных в формуле изобретения. Упоминание элемента в единственном числе не исключает наличия множества таких элементов.