Недостатньо 24-бітового кольору?

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

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

То чому ж ніхто цього не робить?

Ось картинка "Війна Z", де ви можете бачити, що я маю на увазі:

Ви більш-менш сказали це самі: "Я знаю, що це буде багато роботи, і багато обладнання потрібно буде замінити". Хоча графічно-апаратний кінець речей насправді буде досить простим (якщо дорого - подвоєння розміру всіх текстур та буферів кадрів далеко не банальне), "екосистема" для зображень із більшою глибиною кольорів просто не на місці такий ступінь, який робить це вагомим витратом від кого-небудь, оскільки жоден виробник LCD не зосереджується на спробі отримати до 16 біт на піксель (хоча були експерименти на 10BPP, які зручно все-таки вписувати сигнал RGB в 32- бітовий канал).

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

Так, ти не перший, хто помітив це . :) При сьогоднішніх високих коефіцієнтах контрастності 8 біт на компонент недостатньо для отримання плавного градієнта без видимого смуги - якщо тільки не використовується забарвлення.

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

Також існують інші способи виправити смуги через обмежену 8-бітову точність. Як я вже згадував раніше, ігрові двигуни можуть використовувати тремтіння, щоб приховати смуги.

^{(Зображення кішки з 256-кольоровою палітрою, без і з відтінком. Створено користувачем Wikipedia Wapcaplet , використовуваним за ліцензією CC-By-SA 3.0 .)}

Додавання легкої темряви ± 0,5 / 255 перед виписанням значення пікселя до фреймбуфера є надзвичайно ефективним при приховуванні смуг на плавних градієнтах і по суті непомітно. Якщо ви працюєте в двигуні HDR, ви робите це під час етапу тонального відображення.

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

Також варто зазначити, що багато РК-панелей не мають навіть 8 біт на канал. Дешевші, як правило, використовують менше бітів і використовують різні хитрощі, щоб спробувати приховати це. Наприклад, вони можуть швидко перемикатися між двома сусідніми кольорами, щоб представити той, що знаходиться між ними. http://www.anandtech.com/show/1557/3

На сайті http://msdn.microsoft.com/en-us/library/windows/desktop/jj635732%28v=vs.85%29.aspx є деякі подробиці про те, як DXGI підтримує 10 біт на канал і яскравіші за білі кольори.

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

Звичайно, це не допоможе настільки, якщо вихідні дані (текстура тощо) будуть лише 8-бітовими (або, швидше за все, DXT1, що ефективно 5-6-5 біт на канал). Я вважаю, що в цьому скріншоті все є з небом (розмиття в гауссі з 8 біт на секунду робить для мене набагато плавнішим), але важко бути певним.

Відповідь Стівена Стадницького правильна - ігри рідко використовують більш високу точність текстур, оскільки для цього потрібна занадто велика пам'ять текстури, а отже, і занадто велика пропускна здатність пам'яті при відборі текстури в піксельному шейдері. Однак є рішення, які не потребують великих текстур. (Я б опублікував це як коментар, але це занадто довго.)

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

Ще одне можливе рішення - застосувати нормалізацію гістограми до зображення неба. Якщо дані текстури лежать у вузькому діапазоні значень, як темне нічне небо, більшість бітів у кожному кольоровому каналі не несуть корисних даних. Натомість зробіть це:

• Автор оригінальної текстури у 16-бітному форматі, як 16-бітний TIFF.
• Готуючи текстури для ігрового двигуна, знайдіть найтемніший піксель на зображенні та відслідковуйте це як зміщення. Скажімо, це значення пікселя 0,1 в можливому діапазоні 0-1.
• Далі знайдіть найяскравіший піксель і відніміть найтемніший піксель, щоб отримати діапазон значень на зображенні. Отже, якщо найяскравіший піксель ще досить темний - скажімо, 0,35 - діапазон становить лише 0,35 - 0,1 = 0,25. В зображенні присутній лише 25% діапазону значень.
• Створіть стиснуту DXT / BC текстуру в грі. Віднімайте найтемніше значення від кожного пікселя і множте, щоб використовувати всю кольорову гаму. У прикладі розрахунку ми віднімаємо темне значення 0,1 і, оскільки лише 25% наявного діапазону значень, ми множимо кожне значення пікселів на 4 рази, щоб створити текстуру в грі. Не забудьте зробити все це, перш ніж кількісно оцінити 16-бітове вихідне зображення до входу 8bpp в компресор DXT. Тепер вихідне зображення використовуватиме весь діапазон значень, підтримуваний ігровим форматом. Ми виділяємо всі наші біти для відображення значень, фактично присутніх на зображенні.
• Зберігати темне зміщення значення (0,1) та діапазон (0,25) у метаданих десь. Передайте їх у вигляді входів у ваш піксельний шейдер.
• У піксельному коді шейдера виберіть зсувну, розширену текстуру, перетворіть її у плаваюче значення, а потім зробіть множення / додавання для відновлення вихідного значення кольору. Іншими словами, помножте на 0,25 і додайте 0,1, щоб відновити значення, збережене у вихідному зображенні.

Переконайтесь, що шейдерний код гамма правильний . Якщо ви займаєтеся математикою (освітлення та післяобробка) на зразках текстур, які не перетворюються з кольорового простору sRGB в лінійний простір, ви побачите артефакти обшивки, як описаний вами. Корекція гамми була створена, щоб допомогти полегшити подібну проблему, виділивши більше бітів темним значенням, де ваші очі більш чутливі до змін значення. Але ви можете легко порушити речі, якщо не врахувати корекцію гамми, коли обчислюєте, наприклад, освітлення, експозицію або післяобробку FX. Gamma FAQ корисно.

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