як працює HDR?

Я намагаюся зрозуміти, що таке HDR і як він працює.

Я розумію основні поняття і маю невелике уявлення про те, як це реалізується за допомогою D3D / hlsl.

Однак це все ще досить туманно.

Скажімо, я візуалізую сферу з текстурою землі та невеликим точковим списком вершин, щоб вони виступали зірками, як би я вивів це в HDR?

Ось кілька речей, які мене плутають:

• Я здогадуюсь, я не можу використовувати будь-який базовий формат зображення для текстури, оскільки значення будуть обмежені [0, 255] та затиснуті до [0, 1] у шейдері. Те саме стосується заднього буфера, я вважаю, що формат повинен бути форматом з плаваючою точкою?

• Які інші кроки пов'язані? Зрозуміло, що для відображення цілі візуалізації має бути більше, ніж просто використовувати формати з плаваючою точкою, а потім застосувати деякий розквіт як пост-процес? (враховуючи, що вихід буде 8bpp у будь-якому випадку)

В основному, які кроки для HDR? Як це працює ? Я не можу знайти жодних хороших статей / статей, які описують процес, окрім цього , але, здається, трохи перебираємо основи, тому це заплутано.

Технології HDR дозволяють імітувати більшу кількість деталей, ніж ви можете переглядати на екрані, ніж при традиційному освітленні / фактурах. Ви можете порівняти це з тим, як поводиться око під дією різної кількості світла - коли занадто багато світла, очей пропускає менше світла, щоб все ще було у вашому видимому діапазоні. Коли недостатньо світла, райдужна оболонка відкривається більше, тому можна побачити більше деталей.

Права частина цього зображення використовує HDR. Він більше використовує діапазон кольорів, темніші темніші, а світлі області яскравіші. Для порівняння ліва частина зображення виглядає трохи плоскою.

Основні етапи:

1. Надайте вашій сцені текстуру з плаваючою комою (у такому форматі, як A16B16G16R16F), використовуючи інші текстури з плаваючою точкою на ваших моделях та / або світильники, що мають яскравість більше 1,0f.

2. Щоб відобразити цю текстуру, діапазон видимих ​​кольорів потрібно перетворити на щось, що відображається на вашому екрані - цей процес називається тоновим відображенням , і для отримання різних ефектів можна використовувати різноманітні рівняння відображення тонів. Це обов'язково, оскільки монітори не можуть відображати всю гаму кольорів або люмінесценції, яку ми можемо зберігати у текстурах з плаваючою комою (було б здорово, якби це було можливо, але це також було б засліплюючою небезпекою ...).

3. Блум та інші наслідки додаються для подальшого перебільшення різниці в світінні речей. Розквіт обчислюється з буфера з плаваючою комою та поєднується з відображеним на тоні зображенням.

Сподіваюся, що це допомагає

Технічно HDR означає лише використання більшого спектру можливих значень для вашої графіки. Зазвичай у вас обмежено 256 дискретних значень для червоного, зеленого та синього каналів, це означає, що якщо у вас є 2 елементи, один вдвічі яскравіший за другий, а третій, який у 10000 разів яскравіший за перший, немає таким чином ви можете правильно зобразити всі 3 в одній сцені - ви або зробите яскравий об’єкт лише на 256x яскравішим, ніж перший, або робите обидва тупих об'єкта повністю чорними (втрачаючи контраст між ними), і тоді яскравий об’єкт нескінченно яскравіший ніж вони обидва.

Це легко виправити за допомогою значень з плаваючою комою для значень червоного / зеленого / синього - але тепер у вас є проблема, як відобразити це на графічному пристрої, який обробляє лише фіксовану кількість дискретних значень на канал (наприклад, 256) . Отже, друга частина проблеми полягає в тому, як відобразити значення плаваючої точки назад до обмеженого діапазону. Тривіальним рішенням є масштабування всіх значень пропорційно в дискретному діапазоні, але це означатиме, що 1 дуже яскравий піксель може зробити решту екрана чорними і т. Д. Іноді це те, що ви хочете, іноді це не так - див. Тональне відображення CiscoIPPhone посилання на приклади того, як можна підійти до цього.

Як правило, це не ваші текстури, які потрібно зберігати в новому форматі - саме тоді, коли освітлення застосовується до них, вам потрібно вміти приймати більші значення. Очевидно, але якщо у вас є джерела світла, запечені до текстури - наприклад. зоряне тло - вам може знадобитися формат більшої роздільної здатності там. Або просто підняти шейдерну шкалу значень таких матеріалів, коли настане час їх виведення.

Комп'ютери традиційно представляли кожен піксель на екрані лише 24 бітами пам'яті: 8 для червоного, 8 для зеленого та 8 для синього. Це майже достатньо бітів, які людина не помітить, якщо ви додали більше, а 8-бітний байт дуже зручний для мікропроцесорів, тому ось що застрягло.

Незважаючи на те, що 8 біт є майже достатньою точністю для відображення зображення, це однозначно недостатньо точності для обчислення зображення. У різних точках під час обчислення зображення потрібно не менше 32 біт точності.

Ось чому піксельні шейдери обчислюють кольори з 32-бітовою точністю, навіть коли ви перетворюєте на 8-бітове зображення точності. В іншому випадку ви не можете, наприклад, поділити значення на 1000, а потім помножити його на 1000, оскільки ділення будь - якого 8-бітного значення на 1000 призводить до нуля.

У 3D-графіці в реальному часі спостерігається тенденція до збереження всієї графіки> 8-бітовою точністю до останнього можливого моменту, в цей час> 8 біт червоного зменшуються на 8 біт і так далі для зеленого та синього.

HDR позначає акт візуалізації зображень, які мають більш високу, ніж 8-бітову точність. У сучасних телевізійних відеоіграх 16-бітова точність є нормою, і це може бути "достатньо" у відеоіграх на довгі роки.

Один з аспектів, на який я думаю, що є ключовим для HDR, - це правильне застосування моніторної гами.

Монітор, на який ви дивитесь, виробляє світло як функцію вхідних пікселів. Ви можете очікувати, що піксель зі значенням 255 видасть (приблизно) в 255 разів більше світла, ніж піксель зі значенням 1. Це не так. При стандартній гаммі монітора в 2,3 вона яскравіше в 255 ^ 2,3 рази, або приблизно на 340000!

Усі, хто виробляє контент (виробники камер), це знають, або (якщо ви дизайнер) ви неявно це компенсуєте.

Це все добре, якщо ви просто відображаєте растрові картинки (ну, більшу частину часу), але якщо ви використовуєте їх як текстури в 3D-сцені, це вже інша історія. Якщо ви хочете правильно моделювати взаємодію зі світлом, вам слід використовувати лінійні обчислення світла по всьому трубопроводу візуалізації. Це означає

• виправлення текстур для гамми

• візуалізуйте все за допомогою лінійного світла (де вам потрібно багато точності завдяки високому динамічному діапазону світла),

• застосуйте зворотне перетворення гамми монітора як останнє, перш ніж поставити зображення на екран.

Коли ви вносите цю зміну в існуючу сцену, з наявними творами мистецтва, освітленням тощо, вам, мабуть, доведеться виправити багато вашої інтенсивності світла та текстур, оскільки вони були вибрані таким чином, щоб вони виглядали приємно під час візуалізації з нелінійним світлом. Тож це не особливість, яку можна просто "включити" і очікувати, що все буде виглядати краще просто так.