Прогаем с кенгурой

А как вы храните 100500 девайсов для разработки?

(отжал коробку у ребенка)

Хочу такой знак (с кенгуру, переворачивающим машину) где-то раздобыть.

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

Кстати, самый простой автобаланс белого также строится на базе факта, что 0 на UV плоскости это серый:
1 - предполагаем, что средний цвет картинки должен быть серым
2 - берем среднее значение uv по всей картинке
3 - сдвигаем эту точку в 0 для всех пикселей
4 - ...
5 - PROFIT

Если хочется чего-то поинтереснее, но при этом достаточно легковесного, то я делал такой подход на базе гистограмм, который потом можно показать на кривых.

Вот так этот вариант выглядит

Раз уж мы целиком засунули все в YUV, то можно и сатурейшн там же сделать. Нужно только помнить, что на плоскости UV (0; 0) - это серый. Тогда получаем:

    float4 src = texture0.sample(texture0Smplr, In.v_texcoord);
    float3 yuv = rgb2yuv(src.rgb);
    yuv.yz *= 1 + uniform.amount;
    src.rgb = yuv2rgb(yuv);

И тут тоже сатурейшн будет от серого до в два раза больше (если линейно менять amount в пределах [-1; 1], а то ведь можно сунуть что-то типа exp(10 * amount) или того хуже - но это уже на ваше усмотрение.

Проблема (или наоборот фича) такого подхода в том, что у вас не получится выжечь область изначально с малым сатурейшеном, так как мы по факту просто масштабируем вектор цвета относительно его яркости (серого состояния) максимум на его изначальную величину (то есть в два раза):

res = src - t * (lightness - src)

t = -1: res = src + lightness - src = lightness
t = 0:  res = src
t = 1:  res = src + (src - lightness)

(src - lightness) - это по сути исходный сатурейшн, на который мы и сдвигаем цвет.

И перевод для самых ленивых (не забывайте транспонировать матрицы по необходимости, ибо в метале и гл-е они лежат по столбцам)

static float3 rgb2yuv(float3 rgb) {
    float3x3 kRGBtoYUVMatrix = float3x3(
        0.29900,    0.58700,   0.11400,
       -0.14713,   -0.28886,   0.43600,
        0.61500,   -0.51499,  -0.10001
    );
    return transpose(kRGBtoYUVMatrix) * rgb;
}

static float3 yuv2rgb(float3 yuv) {
    float3x3 kYUVtoRGBMatrix = float3x3(
        1.00000,    0.00000,    1.13983,
        1.00000,   -0.39465,   -0.58060,
        1.00000,    2.03211,    0.00000
    );
    return transpose(kYUVtoRGBMatrix) * yuv;
}

Вот так это выглядит

Так, переходим к практике.

Как сделать супер простой контрол для сатурейшена? Супер просто)))

    float4 src = texture0.sample(texture0Smplr, In.v_texcoord);
    float3 yuv = rgb2yuv(src.rgb);    
    src.rgb = mix(src.rgb, yuv.x, -uniform.amount);

Готово.

Идея такая: сатурейшн это расстояние от серого до нашего цвета. Поэтому берем из yuv яркость (там на самом деле достаточно одной компоненты) и двигаем наш цвет от этой серости. Все

Вот еще момент. Для человеческого зрения в информативном плане важнее яркостная компонента, собственно поэтому цветовую и можно пожать.

Вообще в этом плане yuv замечателен:
- яркостный канал стандартизирован и выверен физически
- срез uv имеет одинаковую яркость для всех цветов
- нативно и по дефолту идет из видео
- позволяет достаточно красиво смешивать цвета
- можно легко сделать простой автобаланс белого (среднее значение uv по всей картинке сдвигаем в 0)
- максимально легкая конверсия в rgb и прочие (перемножение с матрицей)
- можно делать коррекцию яркости, не боясь попердолить цвет

Ну и тд

Единственный минус - он нативно не идет в шейдерах, картинках и дисплеях🤷🏼‍♂️

Кстати на том же проекте я обнаружил, что у матриц для перехода YUV->RGB->YUV (ну или наоборот), которые лежат в стандарте и интрнетах, хромает точность, то есть матрица для прямого перехода - не совсем точно обратная матрица для обратного (и наоборот).

Если вы делаете это преобразование один раз, то ок и никто не заметит (разве что чел который отличит 0xA34B8F от 0xA34С8F). Но если вы будете это гонять туда-сюда каждую итерацию, то ошибка накопится очень быстро (даже если сидеть во флотах все время) и цвета распердолит во все стороны. Так что будьте осторожны.

Примерно в то же время (в 2019) я пилил прократам модель для симуляции акварели. Вот чтоб было как на бумаге. К сожалению, модель вышла хоть и качественной, но довольно тяжелой и на больших картинках работала медленно. Плюс требовала кучу памяти на несколько флотовых 4 канальных слоев для разных параметров. Плюс там очень много нюансов с undo/redo. Кароч осталось оно на репе про RnD и в прод не пошло.

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

Чтобы решить эту проблему, я делал так (третья картинка):
1 - переводил RGB->YUV,
2 - там переводил UV в полярную систему координат
3 - ремапил углы так, чтобы между красным, желтым и синим был угол 120º
4 - переводил обратно в декартову систему координат
5 - смешивал цвета в этой модели
6 - для отображения делал обратное преобразование

Еще одна оооочень интересная группа моделей - с приставкой Ok за авторством Бьерна Оттоссона. Несколько (5) лет назад в твиттерах были горячие дискуссии на тему градиентов, смешений цветов и прочего. Среди этого прочего Бьерн предложил несколько моделей с «естественным» смешением цветов и правильной ориентацией яркости.

После (не)продолжительного обсуждения и тэганья всех, кого это должно было бы заинтересовать, его модели включили в стандарт и добавили поддержку как минимум в продуктах Adobe (причем очень быстро, несмотря на казалось бы громоздкость корпорации). Я пытался пропихнуть это и в Procreate, но меня послали.

Вообще рекомендую к прочтению все четыре его статьи с сайта:
- про проблемы смешения цвтов в существующих моделях
- про Oklab
- как наболтать насыщенность и не выжечь глаза
- про Okhsv и Okhsl

Ого) аж 6 человек отписалось после начала серии постов про цветовые модели - эта тема такая страшная, такая скучная или и так всем очевидная?

Так вроде это базовая база и всем полезна будет. Хм. Не ясно

На тему видео вы, возможно, видели что-то типа 4:2:2 или 4:2:0. Это цветовая субдискретизация и показывает сколько сэмплов (пикселей простым языком) цветоразностных каналов на яркостный.

Первая 4 - частота яркостного канала,
Вторая 2 - сколько на эти 4 будет цветоразностных
Третья 2 - сколько цветоразностных во второй строке (если ноль, то вторая строка будет идентична первой

Почему это важно: если вы работаете с сырыми буферами yuv (YCbCr и пр), то часто каналы там лежат в планарном (planar) виде, то есть лежит либо буфер yyy… uuu… vvv…, либо yyy… uvuvuv… (полупланарный/semiplanar). Да, привычный yuv yuv yuv… называется уплотненный/черезпиксельный или interleaved по русски.

Так вот, когда у вас планарно лежат каналы, важно помнить, что размеры их могут не совпадать, если все числа в 4:4:4 не равны. Так, на пример, при 4:2:2 цветоразностные будет иметь в два раза меньшую ширину, а при 4:2:0 - и высоту тоже.

Картинку спер из вики

Я кратенько расскажу про интересные модели, а потом - про их практическое применение вне исходного предназначения - матрицы и переводы и так спокойно гуглятся (знать только, что гуглить).

Начну с цветоразностных, потому что они интересны исторически. Расскажу в общих чертах, потому что там разница в осях, а не в принципе.

Пришли они к нам из телевидения (+ активно используются в видео). Там изначально изображение было ЧБ (яркостная компнонента), к которому добавляется либо поднесущая, либо отдельный частотный канал (в зависимости от стандарта). Это позволяет чб телекам принимать и правильно показывать тот же канал, что и для цветных телеков. Но можно их и отдельно передавать (как на фотке моего древнего телека).