@demofox heh, even if you're *extremely careful* about colorspaces and doing HDR "right" like we have, banding can creep in from everywhere.
We had an engineer spend a month and a half fighting banding on every rendering pass on the last Dragon Age. You need to dither on eeeevery colorspace conversion đ”
@pq @demofox the most obvious one is applying any kind of gamma-like curve on 8bit data. Your values get stretched on one part of the curve, and you get very visible banding.
But the moment of despair comes when you realize that a simple horizontal gradient from 0 to 127 over a 4K screen will necessarily have bands that are 3840/128=30 pixels wide, and those are quite visible by a human eye. So any 8bit target will display banding on slow gradients. It's unavoidable, unless you dither/noise :)
@pq @demofox
Recommendation: check out the "Bible of banding" that is the presentation on the rendering tech of Inside :)
https://blog.playdead.com/articles/inside_presentations/inside_publications.html
@jon_valdes Oh, don't worry. I always wonder if there is some insight I haven't realized yet.
I have indeed been doubting if 10 bpc is even enough for electrical BT.2100/PQ, and I've been *hoping* that 16-bit floating-point would be enough for optical display-referred data.
Very long and slow gradients is a good point to make. Without dithering we would need the stimulus change from one code value to the next to be imperceptible when laid out as two flat fields side-by-side.
demofox
Jon Valdés
Pekka Paalanen