В любом случае R:G:B будут соотноситься как A*(x:y:z). Т.о., все равно проверка относительной интенсивности уровней цветности в каждом пикселе позволит выявить: монохромное (в т.ч. черно-белое) ли изображение.
Там просто будут ошибки округления. Так что достаточно учитывать эти ошибки - например, построить гистограммы пропорций R:B и G:B с не очень большим разрешением. Если на гистограммах будет только по одному пику - изображение монохромное.
Не проще: во-первых, есть ошибки округления, во-вторых, R\approx G\approx B только в черно-белом, а у нас рассматривался случай монохромного изображения. Т.е. имеем: R=Ar, G=Ag, B=Ab; где rgb - общий цветовой тон изображения (double), A - яркость.
какое округление в byte?
Случайные пиксели не того цвета - там их число/все пиксели. Меньше 1% - значит ошибки, игнорить их. Но это для ч/б, о чем и говорил ТС.
Для монохрома да, так не пойдет.
Берем базой цвет #FFD66D (r=255, g=214, b=109) - для точки с яркостью 255. Точка с яркостью 0 будет иметь R=0, G=0, B=0 - это понятно.
А вот, скажем, точка с яркостью 100: R=100.00, G=83.92, B=42.75. Округлить результат можно как по правилам округления, так и простым floor или ceil. А при вычислении соотношения цветов получим ошибку.
Ясно, мы говорим про разные вещи. Я имею ввиду случай, когда функция должна вернуть true, если фотка ч/б. Пропорции нужны для случая, если функция выозвращает true, если фотка монохромна.
Если в изображении есть три (и больше) канала, о чём говорит конкретный формат файла изображения, то наиболее правильно его считать цветным/многоканальным. Если есть палитра + квантованные данные, тоже цветное, и лишь одноканальные серые изображения являются Ъ-серыми. Монохромные битмапы - отдельный случай серого ;).
Весь этот бред сокращённо: лишь данные о процессе получения изображения правильно опишут ваше изображение. Логично процесс получения изображения описывать подходящим форматом хранения.