Передаточные функции: gamma, PQ и HLG

TL;DR

Передаточная функция – это небольшая математическая формула, которой видеофайл переводит число в яркость на экране и обратно. Старая формула – называется gamma – была дефолтом больше 80 лет и до сих пор управляет каждым SDR (Standard Dynamic Range) телевизором. HDR-видео использует две новые формулы: PQ (Perceptual Quantizer, SMPTE ST 2084), которая задаёт точную яркость от 0 до 10 000 нит и используется Dolby Vision и HDR10, и HLG (Hybrid Log-Gamma), спроектированную BBC и японской NHK так, чтобы один и тот же broadcast-сигнал корректно выглядел и на старых SDR, и на новых HDR-телевизорах. Выбор правильной передаточной функции – самое судьбоносное решение в HDR-доставке: неверный выбор – и ваш HDR-файл выглядит блёкло на SDR-наборе или ваш SDR-fallback выглядит дико перенасыщенным на HDR-наборе.

Зачем это знать

Если ваш продукт хостит видео, которое любой зритель может смотреть на HDR-смартфоне, ноутбуке или ТВ – вы столкнётесь с передаточными функциями в первый же раз, когда контент «странно выглядит на iPhone, но норм на офисном мониторе». В восьми случаях из десяти ответ – в том, что тег передаточной функции отсутствует, неверен или плеер не может его интерпретировать. Эта статья даёт модель, как мгновенно увидеть эту проблему, и названия, которые нужны в разговоре с подрядчиком по кодированию. Математическое образование не требуется – будем строить идею шаг за шагом.

Что делает «передаточная функция» на самом деле

Начнём со слов передаточная функция. Это просто инженерный жаргон для «формулы, переводящей одно число в другое». В видео перевод происходит дважды: когда камера записывает файл и когда экран его показывает.

Вот зачем формула вообще нужна. Свет, который испускает реальная сцена, и яркость, которую производит экран – это непрерывные величины: небо может быть в миллион раз ярче, чем тень рядом. Числа, которые мы сохраняем в цифровом файле, – дискретные: для 8-битного канала они идут от 0 до 255, и всё. Преобразовать миллионнократный диапазон яркости только в 256 чисел требует таблицы пересчёта. Эта таблица и есть передаточная функция.

Если бы использовать простую линейную таблицу – «0 значит света нет, 255 значит максимум света, всё посередине пропорционально», – почти все ваши числа уходили бы на яркие части сцены, и почти ничего не оставалось бы на тёмные, потому что человеческий глаз экспоненциально более чувствителен к изменениям яркости в тёмных зонах, чем в светлых. 1% изменения яркости в тени – это огромно и заметно. 1% изменения яркости в highlights – невидимо. Поэтому, вместо прямой линии, передаточные функции намеренно изогнуты, чтобы тратить большую часть чисел там, где глазу важно – в тенях и средних тонах.

Каждая передаточная функция приходит в двух половинах, зеркально отражающих друг друга:

• OETF (Opto-Electrical Transfer Function): camera-side recipe. Переводит физический свет, попадающий на сенсор, в число, сохраняемое в файле. «O» – «оптика» (свет), «E» – «электрика» (хранимый сигнал).
• EOTF (Electro-Optical Transfer Function): screen-side recipe. Переводит число, прочитанное из файла, обратно в физическую яркость на дисплее. Те же буквы, обратное направление.

Чтобы система работала, OETF камеры и EOTF экрана должны согласиться, какая именно формула была использована. Это согласование – «тег» передаточной функции, который несётся как метаданные внутри видеофайла. Если камера записала одну кривую, а экран применил другую – картинка выходит неправильной: обычно слишком тёмной, слишком яркой, или с раздавленными тенями и пересвеченными highlights. Вернёмся к этому в конце. 1

Нажмите, чтобы увеличить

Gamma – оригинальная формула, до сих пор правящая SDR

Самая старая передаточная функция в видео – gamma, и она – случайность физики, превратившаяся в стандарт.

Электронно-лучевые трубки (CRT) телевизоров с 1939 года имели особенность: электронный луч, которым они рисовали экран, не реагировал линейно на подаваемое напряжение. Подаёшь напряжение 50% от максимума – луч производил свет всего около 22% от максимума, не 50%. Это нелинейное поведение описывалось уравнением яркость = напряжение^γ, где γ (греческая «гамма») было около 2,2 до 2,4. 2

Ранние broadcast-инженеры должны были выбрать: либо встроить дорогие корректирующие схемы в каждый ТВ, чтобы исправить кривую, либо принять кривую и предкорректировать сигнал на стороне вещания. Выбрали более дешёвый вариант – применить обратную кривую на камере, чтобы к моменту, когда естественная кривая CRT «декорректировала» сигнал, картинка выходила правильной. Камеры делали напряжение = свет^(1/2,2), ТВ делали свет = напряжение^2,2, и две операции отменяли друг друга.

Когда пришли цифровое видео и плоскопанельные дисплеи, инженеры могли бы перейти на линейную систему. Но к тому моменту мир владел миллиардами часов гамма-кодированного контента, и современные LCD- и OLED-экраны просто эмулируют старую CRT-кривую. Сегодняшний стандарт BT.1886 формализует gamma 2,4 как EOTF для HDTV. Стандарт sRGB для компьютерной графики использует чуть другую гамму со средним 2,2. 3

Случайность оказалась полезной. Гамма-кривая случайно оказалась хорошим совпадением с чувствительностью человеческого глаза – она выделяет больше из 256 чисел (для 8-битного видео) тёмным тонам, где глаз наиболее чувствителен, и меньше – ярким, где глаз не заметит. Поэтому SDR-видео в 8 бит выглядит приемлемо. Если бы гамма была прямой линией, 8-битное видео показывало бы ужасный banding в тенях.

Где gamma до сих пор используется в 2026: каждый SDR-видеостр, который вы смотрите – Netflix SDR, YouTube SDR, эфирное ТВ, Zoom-звонки, веб-камера ноутбука, любое приложение в соцсетях. Примерно 95% всего видео в коммерческом использовании сегодня – gamma-кодированное.

Где gamma фейлит: везде, где ярче примерно 100 нит. SDR проектировался под пиковый белый экрана в 100 нит – примерно как лист бумаги под офисным освещением. Современные HDR-экраны идут до 1000, 4000, даже 10 000 нит, и gamma просто не имеет определённого поведения выше 100. Поэтому HDR потребовал новой формулы.

PQ – точная формула для премиум HDR

Первая формула, спроектированная специально для HDR, – PQ, сокращение от Perceptual Quantizer. Её создала Dolby в 2014 году и стандартизировала SMPTE в том же году как SMPTE ST 2084. 4

Что делает PQ отличной от gamma – её отправная точка. Gamma была случайностью CRT-физики. PQ намеренно проектировалась вокруг человеческой системы зрения – конкретно, вокруг того, сколько различимых уровней яркости глаз действительно может отличить на каждой яркости. Команда Dolby измерила это для сотен зрителей и построила кривую – Barten ramp, описывающую «just noticeable difference» (JND) глаза на каждой яркости от очень тёмной до очень яркой. PQ выделяет свои 1024 уровня (в 10-bit) так, чтобы каждый шаг по кривой был ровно на один JND – то есть глаз действительно не видит ступеньки, как бы ярко или тёмно ни было.

Результат – формула, производящая визуально-идеальные градиенты до 10 000 нит, в 100× ярче 100-нитового потолка gamma. В 12-bit PQ не даёт видимого banding нигде в полном диапазоне. 4

Но у PQ есть жёсткое мнение, встроенное в дизайн: она задаёт абсолютную яркость, не относительную. Когда PQ-кодированный файл говорит «уровень 50%», он значит «ровно 92 нит на экране, независимо от того, какой у вас экран». Если ваш экран физически не достаёт 10 000 нит (а почти никакой потребительский не достаёт), плеер обязан применить «tone-mapping» – сжать очень яркие части картинки в тот диапазон, который дисплей действительно может показать. Tone-mapping – это отдельная сложная задача, и разные реализации плееров делают её по-разному. Один и тот же PQ-файл может выглядеть тонко по-разному на LG OLED, Samsung QLED и Sony ТВ, при том что файл идентичен.

Где PQ используется в 2026: каждый Dolby Vision и HDR10 стрим. Netflix HDR, Disney+ HDR, Apple TV+ HDR, все премиум 4K Blu-ray, все Dolby Vision кино-мастера. PQ стала универсальной формулой для on-demand премиум HDR. 4

Где PQ испытывает трудности: в live-broadcast (где невозможно всегда пред-грейдить контент под абсолютную яркость на неизвестных дисплеях) и в смешанных SDR/HDR-средах (где один фид может быть виден одновременно на старых и новых ТВ). Эту дыру и заполнила HLG.

HLG – формула, спроектированная для live broadcast

HLG, сокращение от Hybrid Log-Gamma, была совместно разработана BBC и японской NHK в 2015 году и стандартизирована как ARIB STD-B67. Её название описывает её структуру: нижняя половина кривой – это традиционная gamma-кривая (совместимая с существующими SDR-телевизорами), а верхняя половина – логарифмическая (расширяющаяся в HDR-яркости). 5

HLG спроектирована решить специфическую проблему broadcast-индустрии. Представьте, BBC транслирует футбольный матч. У части зрителей – новые HDR-ТВ, у части – старые SDR-ТВ 2014 года. Нельзя транслировать два отдельных фида – пропускная способность и бюджет не позволят. Нужен один сигнал, который автоматически правильно выглядит на обоих типах экранов.

Трюк в том, что SDR-ТВ, не знающий, что такое HLG, видит только нижнюю половину HLG-кривой – а эта нижняя половина – обычная gamma-кривая, поэтому SDR-ТВ показывает её корректно. HDR-ТВ, знающий, что такое HLG, декодирует полную кривую включая log-расширенную верхнюю – и получает правильную HDR-картинку. Один файл, два зрителя, оба счастливы, без специальной обработки. 5

HLG также обрабатывает проблему абсолютной vs относительной яркости иначе, чем PQ. HLG – относительная: уровень сигнала 50% не означает фиксированную яркость, он означает «50% от пика вашего экрана, каким бы он ни был». 500-нитовый дисплей покажет это как 250 нит. 1000-нитовый – как 500 нит. Tone-mapping не нужен, потому что яркость автоматически масштабируется с дисплеем. Это делает HLG проще для отгрузки live-контента, но значит, что артистический замысел («этот highlight должен быть ровно такой яркости») менее точен, чем позволяет PQ.

Где HLG используется в 2026: live broadcast HDR. BBC, NHK Японии, большинство европейских общественных broadcaster'ов и растущее число спортивных продакшенов используют HLG. YouTube также принимает HLG для HDR-загрузок. 6

Где HLG испытывает трудности: в тщательно грейдингованном кинематографическом контенте. Кинематографисты хотят абсолютный контроль яркости – когда сцена должна быть тусклой, она должна быть тусклой везде, не растягиваться, чтобы заполнить любой экран. PQ даёт этот контроль; HLG жертвует им ради удобства.

Нажмите, чтобы увеличить

Side-by-side: gamma vs PQ vs HLG

Вся история, сжатая в одну таблицу.

Почему это важно в вашем пайплайне – проблема теггинга

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

Три режима провала, которые вы увидите в продакшене:

Провал 1: HDR-файл помечен как SDR. Кто-то экспортировал PQ-кодированный HDR-мастер, не сохранив метаданные передаточной функции. Файл доходит до плеера, который, не найдя тега, предполагает gamma. Плеер прогоняет PQ-числа через gamma-кривую и выдаёт картинку, которая слишком яркая, с неоновыми зелёными и горящими красными. Это то, что люди имеют в виду, когда говорят «HDR-файл выглядит перенасыщенным на моём SDR-телефоне».

Провал 2: SDR-файл помечен как HDR. Реже, но хуже. Энкодер записал неверный тег, HDR-aware плеер применяет PQ EOTF к gamma-кодированным числам, картинка выходит серой, тусклой и безжизненной. Всё выглядит как туманный день. Это то, что люди имеют в виду, когда «HDR-функция на этом ТВ делает всё выцветшим».

Провал 3: Тег сорван в середине пайплайна. Изначальное кодирование корректно, но шаг транскодинга (часто облачная функция или сервис пакетирования) срывает цветовые метаданные. Следующая стадия в пайплайне не может знать, какую кривую использовать, и дефолтит на gamma. Качество молча деградирует.

Исправление во всех трёх случаях одинаково: проверить файл ffprobe, найти, какой тег передаточной функции установлен (или отсутствует), и перетеггировать на upstream-стадии. Значения тега, которые искать: color_transfer=bt709 (gamma для SDR), color_transfer=smpte2084 (PQ) или color_transfer=arib-std-b67 (HLG). Если видите unknown – проблема теггинга выше по течению.

# Проверить тег передаточной функции и прочую цветовую метадату
ffprobe -v error -select_streams v:0 \
  -show_entries stream=color_transfer,color_primaries,color_space,color_range \
  -of default=noprint_wrappers=1 input.mp4

Корректно теггированный HDR-файл должен возвращать что-то вроде:

color_primaries=bt2020
color_transfer=smpte2084
color_space=bt2020nc
color_range=tv

Корректно теггированный SDR-файл должен возвращать:

color_primaries=bt709
color_transfer=bt709
color_space=bt709
color_range=tv

Если поле color_transfer показывает unknown или отсутствует – upstream-кодирование потеряло метадату, и чинить надо именно там. Мы покрывали ту же проблему теггинга в «Цветовых пространствах: RGB, YCbCr, BT.709, BT.2020, DCI-P3»; тег передаточной функции – один из трёх цветовых тегов, который должен течь end-to-end. 3

Какая передаточная функция для какого продукта?

Практические рекомендации:

Если не уверены, какая нужна – почти всегда ответ gamma. Поднимаетесь к PQ или HLG только при намеренной HDR-стратегии, целевой аудитории с HDR-устройствами и контент-библиотекой, выигрывающей от расширенной яркости. Глубже про HDR-картину.

Нажмите, чтобы увеличить

Частая ошибка: считать, что «10-bit = HDR»

Ловушка, в которую попадают продакт-команды: путать битовую глубину с HDR. Это не одно и то же.

Битовая глубина – это сколько различимых уровней яркости может принимать каждый пиксель (покрыто здесь). Передаточная функция – это формула, которая отображает эти уровни на реальный свет. Можно иметь 10-bit SDR-контент (многие продукты так и делают – это просто даёт более плавные градиенты в SDR). Можно иметь 10-bit HDR-контент (Netflix HDR именно такой). Две концепции независимы.

На практике они склонны идти вместе, потому что PQ и HLG обе работают лучше всего минимум в 10-bit, и редко нужен 10-bit для SDR (gamma в 8-bit нормальна для большинства зрителей). Но связь – корреляция, не причинность. Когда вы отгружаете HDR-продукт, нужны оба – 10-bit хранение и PQ или HLG передаточная функция – и оба должны быть правильно теггированы. Подробнее про bit depth.

Чем мы занимаемся в Фора Софт

Мы видим баги передаточных функций в клиентских пайплайнах почти каждую неделю. Telemedicine-платформа внезапно видит, что оттенки кожи стали оранжевыми на iPhone, но не на Android – оказывается, тег colour-transfer сорвался во время ingest-шага. OTT-сервис выкатывает HDR и получает жалобы, что картинка выглядит «мутной» на более дешёвых ТВ – tone-mapping на плеере ведёт себя странно. Surveillance-система тянет фиды с камер, которые пишут HLG по умолчанию, и воспроизведение записей выглядит выцветшим – viewer-софт применил неправильный EOTF. Исправление всегда выше по течению, в потоке тегов. Фреймворк из этой статьи – то, что мы применяем.

Ключевые выводы

• Передаточная функция – это формула, переводящая сохранённое число в реальную яркость экрана. OETF – camera-side; EOTF – screen-side.
• Gamma (BT.1886, sRGB) – SDR-формула и универсальный дефолт. Останавливается на 100 нит.
• PQ (SMPTE ST 2084) – absolute-brightness HDR-формула, используемая Dolby Vision и HDR10. Спроектирована вокруг человеческой системы зрения, масштабируется до 10 000 нит.
• HLG (ARIB STD-B67) – broadcast-дружелюбная HDR-формула, используемая BBC, NHK и live HDR. Обратно совместима с SDR-ТВ; относительная яркость.
• Теггируйте каждый файл end-to-end с правильным значением color_transfer. Отсутствующие или неверные теги – причина #1 баг-репортов «странно выглядящий HDR».
• 10-bit ≠ HDR. Можно иметь 10-bit SDR (gamma в 10-bit), и для отгрузки HDR нужны и 10-bit хранение, И PQ/HLG.

Что читать дальше

• Цветовые пространства: RGB, YCbCr, BT.709, BT.2020, DCI-P3
• Битовая глубина: 8, 10, 12 бит и проблема banding
• Полный гид по HDR: HDR10, HDR10+, Dolby Vision, HLG