24-bitowa Colordepth to za mało?

Zauważyłem, że przy bardzo miękkich gradientach 24-bitowa głębia kolorów nie wystarcza, ponieważ widać przejścia koloru. To pojawia się najbardziej w ciemnych scenach lub na nocnym niebie.

Dlaczego nikt nie zmienia głębokości kolorów na dwa bajty na kanał? Wiem, że byłoby to dużo pracy i trzeba by było naprawić wiele sprzętu, ale wydaje mi się to trochę denerwujące. Naprawdę nie sądzę, że technologia sprzętu nie jest wystarczająco dojrzała.

Dlaczego więc nikt tego nie robi?

Oto zdjęcie „The War Z”, gdzie możesz zobaczyć, co mam na myśli:

Mniej więcej sam to powiedziałeś: „Wiem, to byłoby dużo pracy i trzeba by wymienić sprzęt”. Podczas gdy sprzętowo-graficzny koniec rzeczy byłby stosunkowo prosty (jeśli byłby drogi - podwojenie rozmiaru wszystkich tekstur i buforów ramek nie jest trywialne), „ekosystem” dla obrazów o większej głębi kolorów po prostu nie jest odpowiedni dla w pewnym stopniu sprawia, że ​​jest to opłacalny wydatek w czyimkolwiek imieniu, ponieważ żaden producent LCD nie koncentruje się na próbach uzyskania do 16 bitów na piksel (choć przeprowadzono pewne eksperymenty przy 10BPP, które nadal wygodnie dopasowują sygnał RGB do 32- kanał bitowy).

Krótko mówiąc, jest to po prostu zbyt dużo pracy dla tego, co większość ludzi uważa za zbyt mały zysk. Może to być „trochę denerwujące”, ale ten poziom irytacji jest tak niewielki, że priorytetem stały się inne ulepszenia jakości obrazu.

Tak, nie jesteś pierwszą osobą, która to zauważy . :) Przy dzisiejszych wysokich współczynnikach kontrastu 8 bitów na komponent nie wystarcza do uzyskania płynnego gradientu bez widocznych pasm - chyba że zastosowany zostanie dithering.

Używanie więcej niż 8 bitów na kanał na wyświetlaczu nazywa się „ głębokim kolorem ” przez producentów wyświetlaczy. Nie jest bardzo rozpowszechniony z powodu problemu z kurczakiem i jajkiem. Wyświetlacz z głębokimi kolorami jest bezużyteczny bez karty graficznej, która może generować głęboki kolor, oraz silnika gry obsługującego renderowanie do głębokich kolorów. Podobnie nie ma sensu silnik gry lub karta graficzna obsługująca głęboki kolor bez wyświetlacza. Dlatego producenci sprzętu i twórcy gier nie zachęcają do dodawania wsparcia dla tej technologii, ponieważ z obu stron nie ma rynku uzasadniającego koszty rozwoju.

Istnieją również inne sposoby naprawy pasmowania ze względu na ograniczoną 8-bitową precyzję. Jak wspomniałem wcześniej, silniki gier mogą używać ditheringu, aby ukryć pasmowanie.

^{(Zdjęcie kota z 256-kolorową paletą, bez ditheringu i z ditheringiem. Utworzony przez użytkownika Wikipedii Wapcaplet , wykorzystany na licencji CC-By-SA 3.0 .)}

Dodanie lekkiego roztrząsania wynoszącego ± 0,5 / 255 przed zapisaniem wartości piksela w buforze ramki jest niezwykle skuteczne w ukrywaniu pasm na gładkich gradientach i zasadniczo niezauważalne. Jeśli pracujesz w silniku HDR, robisz to na etapie mapowania tonów.

Wreszcie, jak zauważyli inni, kompresja tekstur może być większym źródłem artefaktów pasmowych na obrazie niż 8-bitowa precyzja. To może być to, co dzieje się z niebem na tym zdjęciu, choć trudno to powiedzieć - ma tak dużą kompresję JPEG, że wszelkie artefakty spowodowane kompresją DXT są prawie zatłoczone.

Warto również zauważyć, że wiele paneli LCD nie ma nawet 8 bitów na kanał. Tańsze zwykle używają mniej bitów i używają różnych sztuczek, aby to ukryć. Na przykład mogą szybko przełączać się między dwoma sąsiednimi kolorami, aby reprezentować ten pomiędzy nimi. http://www.anandtech.com/show/1557/3

Istnieje kilka szczegółów na temat tego, jak DXGI obsługuje 10 bitów na kanał i jaśniejsze niż białe kolory na http://msdn.microsoft.com/en-us/library/windows/desktop/jj635732%28v=vs.85%29.aspx

D3D od lat obsługuje także ponad 8 bitów na kanał. Nic nie stoi na przeszkodzie, aby deweloper wykonał dithering z 16 bitów na kanał do 8 bitów, jeśli uważają, że to dobry pomysł.

Oczywiście nie pomoże to tak bardzo, jeśli dane źródłowe (tekstura, itp.) Są tylko 8-bitowe (lub bardziej prawdopodobne DXT1, czyli efektywnie 5-6-5 bitów na kanał). Wydaje mi się, że to właśnie dzieje się z niebem na tym zrzucie ekranu (gaussowskie rozmycie 8-bpp sprawia, że ​​jest dla mnie znacznie gładsze), ale trudno jest być pewnym.

Odpowiedź Stevena Stadnickiego jest poprawna - gry rzadko używają tekstur o wyższej precyzji, ponieważ wymagają zbyt dużej ilości pamięci tekstur, aw konsekwencji zbyt dużej przepustowości pamięci podczas próbkowania tekstury w module cieniującym piksele. Istnieją jednak rozwiązania, które nie wymagają dużych tekstur. (Zamieszczę to jako komentarz, ale jest za długi).

Homeworld rozwiązuje ten problem, kodując obraz nieba jako gradienty wierzchołków . Ta technika świetnie sprawdza się w przypadku dużych obrazów o niskiej częstotliwości (tj. Gładkich gradientów) - jak niebo - gdzie tekstura pokrywa ogromną liczbę pikseli w grze.

Innym możliwym rozwiązaniem jest zastosowanie normalizacji histogramu do obrazu nieba. Jeśli dane tekstury mieszczą się w wąskim przedziale wartości, takim jak ciemne nocne niebo, większość bitów w każdym kanale kolorów nie zawiera żadnych użytecznych danych. Zamiast tego wykonaj następujące czynności:

• Twórz oryginalną teksturę w formacie 16-bitowym, takim jak 16-bitowy TIFF.
• Przygotowując tekstury do silnika gry, znajdź najciemniejszy piksel na obrazie i śledź to jako przesunięcie. Powiedzmy, że ta wartość piksela wynosi 0,1 w możliwym zakresie 0-1.
• Następnie znajdź najjaśniejszy piksel i odejmij najciemniejszy piksel, aby uzyskać zakres wartości na obrazie. Tak więc, jeśli najjaśniejszy piksel jest nadal dość ciemny - powiedzmy 0,35 - zakres wynosi tylko 0,35 - 0,1 = 0,25. Na obrazie znajduje się tylko 25% zakresu wartości.
• Wygeneruj teksturę skompresowaną w DXT / BC . Odejmij najciemniejszą wartość z każdego piksela i pomnóż, aby użyć całego zakresu kolorów. W przykładowym obliczeniu odejmujemy naszą ciemną wartość 0,1, a ponieważ istnieje tylko 25% dostępnego zakresu wartości, mnożymy każdą wartość piksela przez 4x, aby utworzyć teksturę w grze. Zrób to wszystko, zanim skwantyzujesz 16-bitowy obraz źródłowy aż do wejścia 8bpp do kompresora DXT. Obraz wyjściowy będzie teraz wykorzystywał cały zakres wartości obsługiwanych przez format w grze. Przydzielamy wszystkie nasze bity do reprezentowania wartości faktycznie obecnych na obrazie.
• Przechowuj gdzieś metadane przesunięcia wartości ciemnej (0,1) i zakresu (0,25). Przekaż je jako dane wejściowe do modułu cieniującego piksele.
• W kodzie cieniowania pikseli próbkuj przesuniętą, rozszerzoną teksturę, przekonwertuj ją na wartość zmiennoprzecinkową, a następnie wykonaj pomnożenie / dodanie, aby przywrócić pierwotną wartość koloru. Innymi słowy, należy pomnożyć przez 0,25 i dodać 0,1, aby przywrócić wartość zapisaną w obrazie źródłowym.

Upewnij się, że kod modułu cieniującego jest poprawny gamma . Jeśli wykonasz matematykę (oświetlenie i przetwarzanie końcowe) na próbkach tekstur, które nie są konwertowane z przestrzeni kolorów sRGB na przestrzeń liniową, zobaczysz artefakty pasmowania, takie jak te, które opisujesz. Korekcja gamma została stworzona, aby pomóc w rozwiązaniu tego rodzaju problemu poprzez przydzielenie większej liczby bitów ciemnym wartościom, w których twoje oczy są bardziej wrażliwe na zmiany wartości. Ale możesz łatwo zepsuć rzeczy, jeśli nie uwzględnisz korekcji gamma podczas obliczania, na przykład oświetlenia, ekspozycji lub efektów końcowych. Gamma FAQ jest bardzo pomocna.

24 bity to za mało, ale znacznie częściej zdarza się, że takie problemy są spowodowane algorytmami kompresji obrazu, aliasingiem lub innymi cyfrowymi artefaktami. Nie zapominaj też o roli technologii wyświetlania - bez względu na wejścia cyfrowe wyświetlacz może nie generować odpowiednich kroków w rzeczywistej jasności.