Об относительной яркости, или насколько живучим бывает легаси

Я начал было писать ответ про гамму, но он получился такой большой, что я его тоже вынес в апдейт.

Совет: я бы модифицировал Ваш пример следующим образом (но мне лень)…

У Вас (псевдокод):
var ethalonY := 0.5, count := 100;
for (var n := 0; n!=count; ++n) {
var r := random(), b := random();
var g1 := getGreenFromRedBlueY(r, b, ethalonY, [0.299, 0.587, 0.114]);
var g2 := getGreenFromRedBlueY(r, b, ethalonY, [0.2126, 0.7152, 0.0722]);
putLeft(r, g1, b); putRight(r, g2, b);
}

Надо:
var ethalonY := 0.5, count := 100;
for (var n := 0; n!=count; ++n) {
var h := n / count * 360°;
var (r, g, b) := hslToRgb(h, 100%, 50%);
var (r1, g1, b1) := normalizeToY(r, g, b, ethalonY, [0.299, 0.587, 0.114]);
var (r2, g2, b2) := normalizeToY(r, g, b, ethalonY, [0.2126, 0.7152, 0.0722]);
putLeft(r1, g1, b1); putRight(r2, g2, b2);
}

Т.е.:
1. Не подбирать зелёный по красному и синему, а подбирать все 3 канала по hue.
2. Меньше рандома, просто перебрать все значения hue подряд с каким-то шагом.

Как уже неоднократно писали, учет гаммы так же важен, как и цифры интенсивности. Так что «рядовой программист», в итоге, все равно сделает неправильно, без учета нелинейности цветового пространства, независимо от того, какие магические числа он нагуглит. Не позорьтесь, исправьте в апдейте

function stringify (r, g, b) {
	return 'rgb(' + Math.round(255 * Math.pow(r, 0.45)) + ',' +
                        Math.round(255 * Math.pow(g, 0.45)) + ',' +
                        Math.round(255 * Math.pow(b, 0.45)) + ')';
}

Это более — менее очевидно. Вопрос скорее — как правильно?

Прямой англоязычный аналог мне неизвестен, к сожалению.
Навскидку в голову приходит известный Color FAQ Чарльза Пойнтона, а конкретнее пункт 9:
http://www.poynton.com/notes/colour_and_gamma/ColorFAQ.html#RTFToC9

Эмм, нет. При (стандартном) переводе из RGB в HSL/HSV как раз эти коэфициенты и не учитываются. Т.е. RGB=[0,0,255] даёт L=50% и RGB=[0,255,0] тоже даёт L=50% (несмотря на то, что [0,0,255] — это синий, а [0,255,0] — это салатовый).

Да и вообще, зачем мне HSL/HSV, если у меня поворот ровно на 120° и 240° — достаточно поменять местами каналы (ну, с поправками, учитывая, что разные каналы имеют разную «мощность»).

Вот для этих поправок и нужны коэфициенты. Прикол в том, что более древние (и по логике неправильные) SDTV-коэфициенты на моём мониторе давали более правильный результат, чем более новые, рекомендуемые в т.ч. автором этой статьи.

На самом деле плохо, что при работе с изображениями не заморачиваются с гаммой. И я имею в виду не только преобразование в YUV, но и использование алгоритмов обработки изображений в целом. Для многих задач игнор гаммы в угоду производительности не играет роли, но при работе с реальными изображениями, когда важна точность, гамму стоит учитывать.

Например, при гамме 2.2 смешение пикселей с интенсивностями 0 и 255 будет равно 186, а не 127.

Это библиотека github.com/chartjs/color, форк github.com/harthur/color, ноги которой растут из библиотеки github.com/brehaut/color-js (в которой, кстати, всё с этим хорошо: github.com/brehaut/color-js/blob/master/color.js#L271).

Не согласен.
Я рассуждаю не как программист, а как ретушер-цветокорретор. Картинка должна быть не просто «правильная» с точки зрения математики, она должна быть яркой и контрастной, с минимальными потерями в деталях – то есть она должна быть красивой. А это не алгоритмизируется так просто

Вот примеры той же радуги:
L-канал из режима Lab: rainbow-Lab.jpg
Командой Grayscale: rainbow-gray.jpg

Если сравнить все варианты – то самый детализированный, то есть тот, у которого цвета максимально разделены друг от друга – десатурнутый с режимом наложения колор. У изображения есть не только детализация по пикселям, но и цветовая, я сейчас о ней и говорю. Пока обсуждаются абстрактные цветные квадратики, все это не наглядно, но когда приходится работать с реальной фотографией, то разница становится заметна и понятна

На самом деле все еще сложнее, грамотно перевести картинку в чб можно только с помощью команды Calculation, пробуя накладывать разные каналы друг на друга, в разных режимах и пропорциях, это сложная задача и после нее все равно придется доводить картинку корректирующими кривыми, но двухкликовый способ лучше всего тот, который я описал, Я плохо представляю, как его запрограммировать, хотя предполагаю, что это возможно, потому что наблюдал подобные задачи и их решения программными методами как на сервере, так и в браузере. Я не вспомню навскидку, но мне кажется, что в CSS есть возможность сделать подобную обработку не простым обесцвечиванием, а с наложением в разных режимах.

Я всего лишь добавил в чисто математический разговор, рассуждения о цвете профессионала-полиграфиста, который почти 20 лет занимается цветокоррекцией. Может это кому то окажется полезным, потому что, как показывает практика, мало кто представляет себе реальный процесс обработки изображений для глянцевых журналов, в инете этому уделяется куда меньше внимания, хотя бы потому, что разброс экранов по качеству и искажениям несравнимо больше, чем в полиграфии и многое прощается