Предлагаю вашему вниманию альтернативный взгляд на подсчет коэффициентов смешивания цветов Gigascreen. Под катом много букв и мерцающие примеры. На мобильном телефоне примеры могут быть сильно искаженными.

Предыстория

Заняться изучением вопроса меня заставила достаточно досадная случайность. Я изучал цветовые возможности Timex в HiRes режиме и смешал две пары цветов в гигаскрин-режиме любимого редактора ZX Spectrum Screen Editor v0.7 by A. Susekov, дабы по-быстрому получить палитру из четырех цветов и использовать её для рисования в режиме цвет на пиксель в GraphicsGale. Работа готова, времени нет, я сдаю результат и понемногу собираю вариант для реального компьютера. Делю в фотошопе картинку надвое, раскрашиваю в нужные цвета, собираю для пробы гифку с мерцанием в 50 герц и с ужасом обнаруживаю, что в режиме мерцания цвета получаются абсолютно яркие и психоделичные. Намного более психоделичные и вырвиглазные, чем мной задумывалось. Пытаюсь разобраться, как же такое может получиться, и на скорую руку подставляю значения от смешивания двух цветов SRGB, оставшиеся в голове с момента прошлого изучения вопроса гамма-коррекции.
В результате получаю результат, на удивление похожий по яркости на мерцающую версию. Повторно закидываю картинку на компо и пишу плагин просмотра нового формата для ZX-Art. Естественно, новый плагин опирается и переиспользует часть кода от плагина-просмотрщика Gigascreen, задействуя всё те же палитры, что и ранее. На этом шаге я подмечаю, что картинка, смешанная с помощью Gigascreen-палитры Pulsar, наоборот заметно темнее, чем картинка, палитру которой я накидал в фотошопе, исходя из простых правил смешивания цветов. Вот тут-то и появляется у меня любопытная мысль:
А что, если смешать цвета для Gigascreen можно намного проще и надежнее, чем мы делали всё это время?

Кого прежде всего касается эта информация.

1. Разработчиков эмуляторов с поддержкой noflick режима отображения гигаскрина.
2. Разработчиков редакторов картинок в гигаскрин-подобных режимах.
3. Художников, рисующих в гигаскрине.
4. Разработчиков конверторов картинок.

Идея.

Итак, моя мысль заключается в том, что у текущих методов смешивания оттенков Gigascreen на современных LCD мониторах наблюдается разница воспринимаемой яркости между мигающим и смешанным вариантом: при мигании некоторые оттенки воспринимаются ярче, чем в варианте со смешанными цветами. Например, возьмем работу Артёма с прошедшего Мультиматографа.
Слева — вариант мерцания через строчку. Справа — смешанный вариант коэффициентами Pulsar.

Обратите внимание на занавески и барную стойку. На левой картинке они отчетливо светлее, чем на правой, особенно если сравнивать их со стеной на фоне.

Я уверен, что устранить эту разницу для современных LCD мониторах возможно, если соблюдаются несколько условий:
1. Монитор поддерживает SRGB.
2. Монитор и ОС откалиброваны для работы с SRGB
3. Матрица монитора имеет минимум искажений по гамме на протяжении всего градиента.
4. Цвета смешиваются строго согласно правилам гамма-коррекции SRGB.
Это довольно серьезные ограничения, но факт заключается в том, что, строго говоря, имеющиеся принципы смешивания точно так же подвержены негативным эффектам от нарушения этих условий. Грубо говоря, у нас уже сейчас картинка неправильная по всем четырем пунктам. Первые три пункта может устранить сам пользователь, а вот пункт четыре я как раз и рассматриваю в этой статье.

Какие цели не преследуются.

1. У спектрумов не было собственного фирменного дисплея, моделей спектрумов было много, а также существовали клоны. То есть, единого стандарта на изображение не было, поэтому сейчас нет ни малейшей возможности построить каноничную и единоверную версию спектрумовского изображения и рассчитать точные RGB значений цветов. Эта цель и не преследуется.
2. Технической возможности сделать решение, подходящее абсолютно всем дисплеям с их особенностями и кривостями, не существует. Собственно, такой цели и нет. Зато есть возможность опереться на имеющийся современный стандарт и сгенерировать картинку в строгом соответствии с этим стандартом. То, насколько каждое конкретное железо близко к идеальной реализации SRGB пространства — за гранью нашей ответственности. Зато попытаться устранить искажения на собственном участке нам вполне под силам.

Суть метода.

Я прежде всего беру в качестве примера палитру Pulsar и коэффициенты смешивания, используемые в ней, так как эта палитра наиболее популярна и считается наиболее широко применимой на практике. Тем не менее, всё, что я здесь пишу, в той же мере может относиться и к Alone, и к Orthodox палитрам, и к любой другой.

Как сейчас смешиваются цвета

Гигаскрин состоит из двух стандартных ZX картинок. На данный момент мы исходим из того, что, при смешивании цвета, каждый RGB канал смешивается отдельно. Так как сейчас мы исходим из того, что спектрумовские цвета имеют идеально чистые оттенки и не отличаются по яркости отдельных RGB каналов (что, кстати, скорее всего не отражает реальной картины ZX48), то нас интересует шесть общих случаев яркости при смешивании цветов. Нас интересует, какие значения получатся при смешивании:
1. Яркого цвета и яркого цвета. Это обозначается как BB (Bright + Bright)
2. Неяркого цвета и неяркого цвета. NN (Non-Bright + Non-Bright)
3. Черного цвета и черного цвета. ZZ (Zero + Zero)
4. Неяркого и черного цвета. ZN (Zero + Non-Bright)
5. Яркого и неяркого цвета. NB (Non-Bright + Bright)
6. Яркого и черного цвета. ZB (Zero + Bright)

Первые три случая очень просты, там цифровое значение яркости канала остаётся прежним. То есть, смешивая ярко красный и ярко красный цвета, мы получим всё тот же ярко красный.
Зато, смешивая ярко-красный (RGB #FF0000) и ярко-синий (RGB #0000FF), мы получим такой вариант:
1. R #FF + R #00
2. G #00 + G #00
3. B #00 + B #FF
То есть, если в случае зеленого канала мы имеем нуль, то в красном и синем канале нам необходимо определиться с каким-то средним значением между #FF и #00.
Pulsar палитра выглядит вот так:
pulsar=00,76,CD,E9,FF,9F:100,00,00;00,100,00;00,00,100

Это — формат записи из Unreal, он же в ini-файле расшифровывается так:

; palette format:
; name=ZZ,ZN,NN,NB,BB,ZB:R11,R12,R13;R21;R22;R23;R31;R32;R33
; where ZZ,NN,BB - bright levels for black,normal,and bright colors
; ZN,NB,ZB - bright levels for zero+normal, normal+bright, zero+bright
;            for GIGASCREEN and FLASH-COLORS

Я не буду вдаваться в подробности коррекции оттенков через R11-R33 коэффициенты, нам сейчас важно то, что Pulsar задаёт для наших случаев 4-6 такие значения яркости:
ZN = #76
NB = #E9
ZB = #9F

То есть, в верхнем примере с сине-красным получится:
1. R #FF + R #00 = ZB = #9F
2. G #00 + G #00 = ZZ = #00
3. B #00 + B #FF = ZB = #9F
Итого результирующий цвет будет #9F009F. Откуда взялись именно такие уровни яркости каналов? Об этом можно подробно прочитать в оригинальном обсуждении на zx-pk.ru
Вкратце, если мне не изменяет память, такие уровни яркости были долго и скрупулезно эмпирически подобраны при сравнении с реальным железом. Поправьте меня, если я плохо помню.

Предлагаемая альтернатива

Палитра Pulsar достаточно хорошо решает свои задачи и, наверное, очень неплохо передаёт картинку каких-то конкретно наборов железа авторов этой палитры. Я предлагаю сконцентрироваться на том, чтобы максимально нивелировать разницу между мерцающим вариантом и смешанным, причем я предлагаю опираться не на чей-то опыт или набор железа, а на четкий, распространенный стандарт SRGB. Таким образом, имеющаяся разница будет обусловлена не чьими-то точными, но субъективными наблюдениями, а конкретными отклонениями конкретного железа от очень конкретного аппаратного стандарта.
То есть, я предлагаю эти самые коэффициенты 4-6 взять, и просто математически рассчитать согласно цветовому пространству SRGB.

Расчеты.

Для сложения двух цветов в старом добром линейном RGB мы привыкли к самой простой процедуре: (A + B) / 2.
То есть, если мы хотим сложить черный и белый цвета, то так и просится (0 + #FF) / 2 = #80, или 128. Звучит достаточно логично, но именно здесь и заключается главный подвох, по причине которого обломалась не одна попытка решить вопрос смешивания гигаскрин цветов в лоб. Дело в том, что SRGB пространство, который показывают наши мониторы, под который заточены видеокарты, софт, драйвера — это нелинейное цветовое пространство. Или, правильнее сказать, пространство с хитрой коррекцией гаммы. Наглядная разница на картинке:



По этой причине в SRGB #80 (128) не является срединным серым по шкале абсолютной яркости, как это было бы в старом RGB, а срединная яркость приходится аж на #BC (188).
Пруф: en.wikipedia.org/wiki/Middle_gray
Наглядный пример, как это работает на вашем мониторе прямо здесь и сейчас. Можно эту картинку пощупать color picker-ом и убедиться, что работа с цветами давно не такая простая, как могло бы быть:



Как же смешивать цвета в SRGB? Самый простой вариант — перевести оба цвета в линейный RGB, применив обратную коррекцию гаммы, взять среднеарифметической значение и снова применить коррекцию гаммы, переведя в SRGB. Именно эту процедуру я и предлагаю сделать для наших ZN, NN, ZB значений.

Формулу перевода из линейной шкалы в SRGB возьмем из википедии:

a = 0.055, C_linear — линейная яркость.

Формула коррекции гаммы делится на два участка, нас интересует нижний (где C > 0.0031308), так как верхний применим для яркости <(1/255). Следует также учесть то, что яркость в формуле используется в диапазоне от 0 до 1. Возьмем для примера средний серый 128 и переведем в SRGB. C_linear = 128/255 = 0.5019, подставляем в формулу:
(1+0.055)* 0.5019^(1/2.4) — 0.055 = 0.7366
Теперь 0.7366 обратно домножим на 255, округлим и получим 188 (#BC). То есть, все достаточно просто. Получить формулу обратного перевода несложно, просто надо применить обратные операции. Для экономии времени советую сделать таблицу с Excel-формулами для перевода.
Попробуем теперь вычислить ZN, NB, ZB. Сэкономлю немного времени и сразу напишу полученные значения, за уровень Non-Bright взято то же значение, что и в Pulsar.
ZN = #96
NB = #E8
ZB = #BC

Как видим, значения сильно отличаются кроме Non Bright + Bright, оставшегося практически идентичным. Давайте посмотрим, что получилось на практике. Для каждого оттенка в гифке есть три участка: мигающий двумя цветами, сетка тех же двух цветов и оттенок, полученный при смешивании.





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

Практика.

Теперь применим эти оттенки на практике к той же картинке. Слева я поставил палитру Pulsar, в центре мигающий вариант, справа SRGB смешивание.



Как видите, SRGB картинка более светлая, что визуально здорово соотносится с мерцающим вариантом.

Еще пара примеров.



Обратите внимание на лоб.



Практически все тени стали ближе по оттенку к мерцающему варианту.

Заключение.

Я не берусь судить однозначно, так как требуется более широкое тестирование, чем проведенное мной, но на момент написания этой статьи мне кажется, что смешивание цвета с учетом гаммы даёт более точный результат и обещает дать еще более точный результат в дальнейшем, по мере совершенствования дисплеев. Повторюсь, что никакое самое правильное смешивание цвета не даст того самого оттенка с реального оригинального спектрума, так как единой оригинальной палитры не существовало принципиально. То, к чему стоит стремиться сейчас — это максимальное нивелирование разницы между мигающим и смешанным вариантом, и, на мой взгляд, такой нехитрый и прямолинейный подход отлично себя оправдывает. Давайте также не забывать, что современные реалы постепенно мигрируют на современные дисплеи, и задача правильного отображения цвета внезапно становится снова актуальной и для показа на реальных машинах.
Таким образом, Pulsar палитра в SRGB смешивании будет выглядеть так:
srgb=00,96,CD,E8,FF,BC:100,00,00;00,100,00;00,00,100

Проверяйте мои расчеты, пишите свои впечатления.

Что проверить, если у меня всё не так

1. Статью совершенно нет смысла смотреть при наличии масштабирования. Сюда попадают: планшеты, телефоны, увеличение на уровне браузера (выключается через CTRL+0), увеличение масштаба интерфейса в ОС, Retina-технологии (под них надо, видать, отдельные примеры как-то сделать). Проблема всего вышеперечисленного в том, что картинки показываются с искажениями цвета из-за быстрого алгоритма ресэмплинга (опять же, привет, гамма-коррекция!)
   
2. zxart.ee/userfiles/images/srgb/srgb.gif — по этой картинке можно в целом оценить готовность системы к SRGB. Если между левыми-правыми половинами огромная разница, то нужна проверять профили, калибровать дисплеи, и в худшем случае идти в магазин за новым.