24-Bit Colordepth yeterli değil mi?

Çok yumuşak gradyanlarda, 24 Bit renk derinlik renginin geçişlerini görebileceğiniz kadar yeterli olmadığını fark ettim. Bu, en karanlık sahnelerde veya gece gökyüzünde ortaya çıkar.

Neden kimse renk tonunu kanal başına iki bayta değiştirmiyor? Bunun bir sürü iş olacağını ve bir çok donanımın düzeltilmesi gerektiğini biliyorum, ama onu biraz sinir bozucu buluyorum. Donanım teknolojisinin yeterince olgun olmadığını düşünüyorum.

Peki neden kimse bunu yapmıyor?

İşte ne demek istediğimi görebileceğiniz "Savaş Z" nin bir resmi:

Siz az ya da çok kendiniz söylediniz: 'Biliyorum, bu çok fazla iş olacak ve bir çok donanımın değiştirilmesi gerekecekti.' Grafik donanımın sonu, aslında göreceli olarak kolay olsa da (eğer pahalıysa - tüm dokuların ve çerçeve tamponlarının boyutlarını iki katına çıkarmak iki kat daha uzak), daha yüksek renk derinlikli görüntüler için 'ekosistem' sadece yerinde değil Hiçbir LCD üreticisi, piksel başına 16 bite kadar ulaşmaya odaklanmadığından (bu durum, 10BPP'de hala bir RGB sinyalinin içine uygun bir şekilde uygun bir RGB sinyalini sığdırmak için bazı deneyler olmasına rağmen) bunu kimsenin lehine yapabileceği kadar harcama yapmaz. bit kanalı).

Kısacası, çoğu insanın henüz çok az kazanç sağlayamayacağı kadarıyla çok fazla iş var. 'Biraz sinir bozucu' olabilir, ancak bu sıkıntı düzeyi o kadar incedir ki görüntü kalitesindeki diğer iyileştirmeler önceliklidir.

Evet, bunu ilk fark eden sen değilsin . :) Günümüzün yüksek kontrast oranları ile, bileşen başına 8 bit, görünür bantlama olmadan yumuşak bir gradyan yapmak için yeterli değildir - dithering kullanılmadığı sürece.

Bir ekranda kanal başına 8 bitten fazla kullanılması , ekran üreticileri tarafından " derin renk " olarak adlandırılır . Tavuk ve yumurta problemi nedeniyle pek yaygın değildir. Derin renkli ekran ve derin renge dönüştürmeyi destekleyen bir oyun motoru olmadan derin renkli ekran kullanışsız. Aynı şekilde, oyun motorunda veya ekran olmadan derin rengi destekleyen ekran kartında da bir nokta yoktur. Bu nedenle donanım üreticileri ve oyun geliştiricileri için bu teknolojiye destek sağlama konusunda pek bir teşvik yok, her iki taraftan da, geliştirme maliyetini haklı çıkaracak bir pazar yok.

Ayrıca, sınırlı 8 bitlik hassasiyet nedeniyle bantı sabitlemenin başka yolları da vardır. Daha önce de belirttiğim gibi, oyun motorları bantlamayı gizlemek için renk taklidi yapabilir .

^{( Taklitsiz ve renk takmayan 256 renk paleti olan bir kedinin resmi. Vikipedi kullanıcısı Wapcaplet , CC-By-SA 3.0 lisansı altında kullanılır .)}

Çerçeve değerine piksel değerini yazmadan önce ± 0,5 / 255 değerinde hafif bir renk taklidi eklemek, düz degradeler üzerindeki bantların gizlenmesinde son derece etkilidir ve temelde farkedilemez. Bir HDR motorundaysanız, bu tonlama sırasında bunu yaparsınız.

Son olarak, başkalarının da belirttiği gibi, doku sıkıştırma, görüntüde 8 bitlik hassasiyetten daha büyük bir bant benzeri yapı kaynağı olabilir. Bu resimdeki gökyüzünde olan şey bu olabilir, anlatması zor olsa da - DXT sıkıştırması nedeniyle ortaya çıkan herhangi bir eseri bataklıkla kaplayacak kadar çok JPEG sıkıştırması var.

Ayrıca birçok LCD panelin kanal başına 8 bit olmadığını da belirtmek gerekir. Daha ucuz olanları daha az bit kullanma ve onu gizlemeye çalışmak için çeşitli hileler kullanma eğilimindedir. Örneğin, aralarındaki birini temsil etmek için iki bitişik renk arasında hızla geçiş yapabilirler. http://www.anandtech.com/show/1557/3

DXGI’nın kanal başına 10 biti nasıl desteklediği ve beyaz renklerden daha parlak olduğunu http://msdn.microsoft.com/en-us/library/windows/desktop/jj635732%28v=vs.85%29.aspx adresinde bulabilirsiniz.

D3D ayrıca yıllarca kanal başına 8 bitten daha fazla desteklemiştir. Bir geliştiricinin kanal başına 16-bit'ten 8-bit'e kadar biraz titreme yapmasını durduracak hiçbir şey yoktur, eğer iyi bir fikir olduğunu düşünüyorlarsa.

Tabii kaynak verileri (doku vb.) Yalnızca 8 bit ise (ya da kanal başına etkili bir şekilde 5-6-5 bit olan daha büyük olasılıkla DXT1), bu pek yardımcı olmaz. Ekran görüntüsünde gökyüzünün ne olduğuna inanıyorum (8-bpp gauss bulanıklığı benim için daha pürüzsüz kılıyor) ama kesin olması zor.

Steven Stadnicki'nin cevabı doğrudur - oyunlar nadiren daha yüksek hassasiyetli dokular kullanır, çünkü çok fazla doku hafızası gerektirir ve sonuç olarak dokuyu bir piksel gölgelendiricisinde örneklerken çok fazla hafıza bant genişliği gerektirir. Ancak, büyük dokular gerektirmeyen çözümler var. (Bunu bir yorum olarak gönderirdim, ama çok uzun.)

Homeworld bu problemi gökyüzü görüntüsünü verteks gradyanları olarak kodlayarak çözer. . Bu teknik, dokunun çok sayıda oyun pikselini kapladığı büyük, düşük frekanslı görüntüler (yani düz degradeler) - benzeri gökyüzü için harika çalışır.

Başka bir olası çözüm histogram normalleşmesini gökyüzü görüntünüze uygulamaktır. Doku verileri karanlık bir gece gökyüzü gibi dar bir değer aralığındaysa, her renk kanalındaki bitlerin çoğu yararlı veri taşımamaktadır. Bunun yerine, şunu yapın:

• Orijinal dokuyu, 16 bit TIFF gibi, 16 bit biçiminde yazar.
• Dokularınızı oyun motoru için hazırlarken, görüntüdeki en koyu pikseli bulun ve bunu ofset olarak takip edin. Diyelim ki bu piksel değeri 0-1 olası aralığında 0,1'dir.
• Sonra, en parlak pikseli bulun ve görüntüdeki değer aralığını elde etmek için en koyu pikseli çıkarın. Öyleyse, eğer en parlak piksel hala oldukça karanlıksa - 0.35 deyin - aralık yalnızca 0.35 - 0.1 = 0.25. Görüntüde değer aralığının yalnızca% 25'i mevcut.
• Senin üret DXT / BC-sıkıştırılmış oyun içi dokusu. Her pikselden en karanlık değeri çıkarın ve tüm renk aralığını kullanmak için çarpın. Örnek hesaplamada, koyu değerimiz olan 0,1'i çıkardık ve mevcut değer aralığının sadece% 25'i bulunduğundan, oyun içi doku oluşturmak için her piksel değerini 4'le çarpıyoruz. Tüm bunları 16 bit kaynak görüntünüzü DXT kompresöre giden 8bpp girişine indirmeden önce yaptığınızdan emin olun. Çıktı görüntüsü şimdi oyun içi format tarafından desteklenen tüm değer aralığını kullanacaktır. Tüm bitlerimizi görüntüde gerçekten mevcut olan değerleri temsil etmek için tahsis ediyoruz.
• Karanlık değer ofsetini (0.1) ve aralığını (0.25) meta verisinde bir yere koyun. Bunları piksel gölgelendiricinize giriş olarak iletin.
• Piksel gölgelendirici kodunda, kaydırılmış, genişletilmiş dokunuzu örnekleyin, yüzdürme değerine dönüştürün ve ardından orijinal renk değerini geri yüklemek için bir çarpma / ekleme yapın. Başka bir deyişle, kaynak görüntüde depolanan değeri geri yüklemek için 0,25 ile çarpın ve 0,1 ekleyin.

Gölgelendirici kodunun gama doğru olduğundan emin olun . SRGB renk uzayından doğrusal uzaya dönüştürülmemiş doku örneklerinde matematik (aydınlatma ve işlem sonrası) yaparsanız, tanımladığınız gibi bant yapılarını göreceksiniz. Gama düzeltmesi, gözlerinizin değer değişikliklerine daha duyarlı olduğu karanlık değerlere daha fazla bit tahsis ederek bu tür bir sorunu hafifletmek için oluşturulmuştur. Ancak, örneğin aydınlatma, pozlama veya işlem sonrası FX hesaplarken gama düzeltmesini hesaba katmazsanız işleri kolayca kesebilirsiniz. Gama SSS yararlıdır.

24 bit yeterli değildir, ancak bunun gibi görüntü sıkıştırma algoritmaları, takma ad veya diğer dijital yapay nesnelerden kaynaklanan problemler çok daha yaygındır. Ayrıca, ekran teknolojisinin rolünü göz ardı etmeyin - dijital girişler ne olursa olsun, ekran gerçek parlaklıkta uygun adımları üretmeyebilir.