Делить RGB на 255 или на 256? Математическая война, о которой вы не знали

Что произошло

Статья на 30fps.net разбирает неожиданно глубокий вопрос: когда вы конвертируете 8-битное значение цвета (0-255) в float (0.0-1.0), делить нужно на 255 или на 256?

Казалось бы — на 255, чтобы 255 стало 1.0. Но при обратной конвертации через truncation 256 бинов превращаются в 255: только точное 1.0 попадает в бин 255, что создаёт неравномерное распределение. Деление на 256 решает эту проблему, но создаёт другую: 255/256 не равно 1.0, и чистый белый становится недостижим.

Статья вводит два типа квантизаторов — mid-tread (стандартный, /255) и mid-riser (альтернативный, /256) — и показывает, что оба несовершенны.

Что говорит тред

herf, создатель f.lux и эксперт по цвету, выступил за решение с +0.5: «Полуразмерные интервалы на краях — это неприемлемо. RGB-значения представляют яркости относительно адаптированного состояния, и "ноль" в дневной сцене — это не настоящий ноль.»

jessetemp указал на методологическую ошибку: автор путает bins с bin edges. В первом графике стандартный подход выглядит странно, потому что 0-7 должны быть краями бинов, а не центральными точками.

moefh успокоил: при 8 битах на компонент разница между /255 и /256 настолько мала, что нужно отличное цветовосприятие и вплотную подойти к экрану, чтобы её заметить. Но при 16 битах и HDR проблема становится реальной.

virtualritz дал практический совет: «255.0. Всё остальное опасно при работе с цветом. А при переходе обратно в 8 бит — дизеринг, чтобы избежать бандинга.»

Что это значит

Вопрос, который выглядит как придирка, оказывается фундаментальным при работе с HDR, научной визуализацией и точным цветом. Статья — отличный пример того, как «очевидный» ответ в программировании часто неправилен.