RGB değerleri 255'e mi, 256'ya mı göre normalleştirilmeli?

8 bitlik renk değerlerini kayan noktalı sayıya çevirip geri döndürmek, her görüntü işleme programının ilk kararlarından biri ve bu konuda iki yaklaşım var. Grafik programcısı Pekka Väänänen, 30fps.net blogunda soruyu analiz eden bir yazı yayımladı; yazıda standart 255'e bölme ile 0,5 kaydırma ekleyip 256'ya bölen alternatif karşılaştırılıyor.

İki formül

Standart yaklaşım pikselleri img / 255.0 ile dönüştürüp trunc(result * 255 + 0.5) ile geri yazıyor: 0 tamsayısı 0.0'a, 255 ise 1.0'a karşılık geliyor — GPU'ların işaretsiz normalleştirilmiş biçimlerde kullandığı kuralın aynısı. Alternatif ise dönüştürme için (img + 0.5) / 256.0, yazma için trunc(result * 256) kullanıyor; böylece her kayan noktalı değer iki tamsayının tam ortasına düşüyor.

Alternatifin pratik bedeli siyahın artık 0.0 olmaması: 0 tamsayısı 0.001953125 olarak çözülüyor, dolayısıyla siyah pikseli algılamak isteyen kodun bu sabiti bilmesi ve 8 bitlik aralığa bağlanması gerekiyor. Yazar, standart formülde görüntünün kayıpsız geri döndüğünü ve 128/255'in yaklaşık 0.501961 olmasından kaynaklanan hatanın en anlamsız bitte kaldığını, göreli hatanın yüzde 0.00001 civarında olduğunu belirtiyor.

Uçlarda yarı genişlikte kutular

Standart formülün zayıflığı kenarlarda ortaya çıkıyor. Kayan noktalı aralığı [0, 1]'den biraz geniş olduğu için 0'a ve 255'e yuvarlanan kutular diğerlerinin yarısı genişliğinde; bu yüzden düzgün dağılımlı gürültü uç değerleri yarı sıklıkta üretiyor. Yazı bunu bir milyon rastgele değerle oluşturulan histogramla gösteriyor ve ardından bunun nadiren önemli olduğunu savunuyor: aralığın hemen dışındaki değerler yine doğru tamsayıya yuvarlanıyor ve siyahtan 0.005 çıkarmak iki şemada da 0 ile sonuçlanıyor.

Nicemleme kuramının diliyle bunlar 255 düzeyli mid-riser ve 256 düzeyli mid-tread nicemleyiciler. Geri oluşturma hatası 256'ya bölmede biraz daha düşük — ortalama mutlak hata 1/1024'e karşı 1/1020 — ama yalnızca aynı kodun hem kodlamayı hem çözmeyi denetlediği durumda. Başkalarının görüntülerini alternatif ölçekle yüklemek teoride yanlış çözmedir ve iki nicemleyiciyi karıştırır.

Ne yapmalı

Sonuç bilinçli olarak pratik: kendi üretmediğiniz görüntüleri işliyorsanız 255'e göre normalleştirin. 256'ya bölme, hem kaydetmeyi hem yüklemeyi siz denetliyorsanız, sıfırın sıfıra eşlenmesine ihtiyaç duymuyorsanız ve işleme kodunu 8 bitlik aralığa bağlamayı kabul ediyorsanız savunulabilir. Yazıda ayrıca Chris Lomont'un sonraki 'en iyi yöntemi' ele alınıyor: k/255.0 ile çözüp clamp(floor(x * 256), 0, 255) ile kodlayan bu yöntem tam aralığı ve eşit kutuları koruyor, karşılığında nicemleme hatası uçlarda zirve yaparak yaklaşık iki katına çıkıyor.