колірний конвеєр darktable
Більшість програм обробки зображень походять з 1990-х років та/або успадковують робочий процес 1990-х. Ці програми обробляли зображення, закодовані 8-бітовими беззнаковими цілими числами, оскільки це було більш ефективно в обсязі пам’яті та обчислень. Однак через використання цілочисельного формату (що означає появу помилок округлення) їм довелося застосувати “гамму” (по суті, передавальну функцію із застосуванням степеню 1/2.2 або 1/2.4 для кодування значень RGB) та збільшувати бітову глибину в затемнених ділянках, щоб зменшити там помилки округлення (люди дуже чутливі до деталей в затемнених ділянках). 8-бітові цілочисельні формати також технічно обмежені діапазоном 0-255. Все, що виходить за межі цього діапазону, переповнюється і відсікається до найближчої межі.
Ці робочі процеси, що використовують обмежені простори RGB і, можливо, нелінійні перетворення для кодування RGB-сигналів, називаються “на основі відображення”. Вони покладаються на припущення, що зображення було підготовлено для показу на ранній стадії в конвеєрі обробки, і вкладають жорстко закодовані припущення про значення RGB чорного, середньо-сірого та білого кольорів. Більшість алгоритмів обробки зображень, що використовуються в цих робочих процесах, були налаштовані навколо цих припущень. Наприклад, режим змішування “перекриття” очікує кодування середньо-сірого на 50% (або значення 128 у цілочисельному кодуванні).
На жаль, нелінійне масштабування, яке є обов’язковим для роботи цілочисельного кодування, порушує природні взаємозв’язки між значеннями пікселів. Відтінок і насиченість змінюються непередбачувано, а співвідношення значень між сусідніми пікселями розширюються або стискаються таким чином, що градієнти також змінюються непередбачувано.
Тому конвеєри на основі відображення порушують оптичні фільтри (розмиття або відновлення різкості оптики), альфа-композитинг (який покладається на оптичні та геометричні визначення оклюзії), кольори та градієнти (локальні залежності між кольоровістю та яскравістю пікселів). Вони також погано масштабуються до HDR-зображень, що призвело до розробки багатьох сумнівних методів локального та глобального тонального відображення та сумнозвісного “вигляду HDR” 2010-х років.
Сучасні комп’ютери не прив’язані до тих самих обчислювальних обмежень, що й комп’ютери 1990-х років, і можуть працювати з пікселями, значення яких абсолютно необмежені (від 0 до +нескінченності) і кодуються як дійсні числа (із використанням форматів з рухомою комою). Ці можливості забезпечують те, що ми називаємо робочим процесом “на основі сцен”, в якому пікселі можуть зберігати свої початкові радіометричні зв’язки майже по всьому конвеєру обробки. У робочому процесі на основі сцен пікселі готуються до відображення лише на останньому етапі конвеєра. Це означає, що значення RGB пікселів зберігаються пропорційними інтенсивності випромінювання світла, зафіксованого камерою на сцені, забезпечуючи точний альфа-композитинг та емуляції оптичних фільтрів, одночасно масштабуючи до будь-якого динамічного діапазону за тим самим алгоритмом (як SDR, так і HDR).
Однак конвеєри на основі сцен втрачають зручні фіксовані значення білого, середньо-сірого та чорного, що характеризують конвеєри на основі відображення, і встановлення цих значень відповідно до сцени та умов зйомки стає відповідальністю користувача. Для цього потрібен більш складний інтерфейс користувача.
Крім того, оскільки значення “на основі сцен” мають бути фізично значущими, пікселі не можуть мати нульову інтенсивність. Це означало б, що у них взагалі немає світла, а існування нульового світла порушує багато фізично точних алгоритмів. Насправді білий та чорний нічого не означають щодо оригінальної сцени, яка є лише сукупністю яскравостей з різною інтенсивністю. Робочий процес на основі сцен просто спрямований на перепризначення деяких довільних яскравостей сцени до того, що буде виглядати білим або чорним на вихідному носії.
Версії darktable до 2.6 мали нелінійний конвеєр на основі відображення припускаючи, що нелінійне перетворення відбулося на початку конвеєра, а середньо-сірий колір був кодований як 50%. Однак не всі модулі та фільтри відсікали значення пікселів вище 100%, залишаючи відкритою можливість відновлення цих значень пізніше в конвеєрі.
Перетворення до відображення в модулі filmic, представлене в darktable 2.6, було першим кроком до конвеєра на основі сцен, і відклало обов’язкову нелінійну підготовку до відображення до кінця конвеєра, а також додало можливість встановити власні значення чорного, сірого і білого. Потім модуль колірний баланс представив спосіб мати справу зі змінним визначенням середньо-сірого.
Починаючи з darktable 3.2, користувачі могли вибирати між двома робочими процесами, які визначали узгоджені налаштування за замовчуванням, модулі та порядок конвеєра і для обробки на основі відображення і для на основі сцен.
У darktable 3.4 була введена опція маскування та змішування повністю “на основі сцен”, що дозволяє визначати маски для значень пікселів понад 100% та використовувати лише необмежені оператори змішування.
Перехід на обробку на основі сцен є когнітивним стрибком для найбільш досвідчених користувачів, які звикли мислити в термінах відображення. У робочому процесі на основі відображення прийнято закріплювати значення білого і дозволяти регулюванню тону обертатися навколо цієї точки, намагаючись максимізувати яскравість, але уникаючи відсікання. У робочому процесі на основі сцен значення білого та чорного кольорів є змінюваними та адаптованими до вихідного середовища. Користувачам рекомендується закріпити середньо-сірий (який буде збережений як є для будь-якого вихідного середовища) і дозволити перетворенню до відображення (filmic) розширити або скоротити динамічний діапазон навколо цієї точки. Оскільки білий 10-бітного HDR у 4 рази яскравіший, ніж білий 8-бітного SDR, будь-яке жорстке визначення “білого” стає неактуальним. Але закріплювати середньо-сірий насправді зручніше, оскільки це зберігає середню яскравість зображення незмінною в процесі перетворення до відображення.
Деякі модулі (рівні, рівні rgb, тонова крива, крива rgb) за своєю суттю несумісні з робочим процесом на основі сцен, оскільки їх графічний інтерфейс неявно пропонує значення RGB, які обмежені в діапазоні 0-100%. Незважаючи на те, що піксельні операції, які вони виконують, можуть бути використані як у робочих процесах на основі сцен, так і на основі відображення, оскільки вони необмежені всередині, але їх інтерфейс управління не дозволяє вибирати пікселі за межами діапазону 0-100%.
Подібним чином, режими змішування, такі як перекриття, лінійне світло, розсіяне світло, направлене світло, затемнення, заміна світлим тощо, мають жорстко закодовані пороги, які внутрішньо очікують нелінійного кодування на основі відображення.
У darktable 3.4 і вище, наведення курсора на заголовок модуля показує підказку, що деталізує колірні простори, діапазони та кодування, які модуль очікує, використовує та виробляє. Ось визначення використаних термінів:
- лінійний
- Значення пікселів пропорційні радіометричному випромінюванню сцени, що забезпечує точну емуляцію фізичних фільтрів.
- нелінійний
- Значення пікселів перемасштабуються таким чином, що для темних ділянок надається більший діапазон кодування, як правило, перепризначенням середньо-сірого 18.45% до значення між 46 і 50%.
- на основі відображення
- Очікується, що значення пікселів становитимуть від 0 до 100% від діапазону дисплея (або іншого носія зображення), де під 100% розуміється яскравість рефлективної на 20% білої поверхні (білий зразок калібраційної мішені), а 0% – максимальна щільність вихідного середовища (насичена чорна фарба або мінімальне підсвічування світлодіодної панелі).
- на основі сцен
- Очікується, що значення пікселів будуть більше нуля і до +нескінченності. Сенс конкретних значень пікселів має визначатися користувачем під час виконання. Значення пікселів “на основі сцен” не означають автоматично лінійне, радіометрично масштабоване кодування.