RGB и железо: поток сознания

[Proxy]

Под впечатлением от этой темы хотелось описать своё видение цветовой модели RGB. Но не хочется массивным оффтопом портить ту ветку, поэтому опубликую здесь (и при этом кое-что из того поста перетяну сюда).
Итак по поводу цветовых моделей.
Тезис 1: как работает RGB? Если представить себе устройство вывода, представляющее из себя 3 лампы (с идеальными спектральными характеристиками), свет от которых проходит через светофильтры (один на каждую лампу), проходит через отверстия в экранах (1 экран с отверстием для каждой лампы) и попадает на общий экран. Цвет 0xFFFF00 означает, что на контактах ламп номер 1 и 2 будет некоторая условно-максимальная величина напряжения, а 3 лампа будет выключена. Если на равное расстояние поднести фоторезистор (опять же с идеальными спектральными характеристиками) к 1 и 2 лампе до светофильтра, то его сопротивление будет одинаково. В тоже время если поднести его на одинаковое расстояние к каждому светофильтру с противоположной стороны от ламп, то его сопротивление будет различно, т.к. свет разных диапазонов спектра несёт разное количество энергии. Т.е. данное устройство не может никак создать на экране пятно красного цвета такое же яркое, как самое яркое зелёное пятно, создаваемое этим же устройством. Вроде бы выглядит как техническое ограничение, т.к. если подать на лампу напряжение выше условно-максимального, то лампа просто выйдет из строя. Пока вроде бы всё гладко с RGB (на сколько технически способны работать монитор и принтер, на столько и работают).
Тезис 2: заглянул в настройки своего монитора и обнаружил, что яркость и контрастность установлены в значения 80% от максимального (иначе глазам не комфортно становится). Стало быть у этого конкретного монитора есть ещё как минимум 20% диапазон (80-100) компенсации яркости субпикселей (чтобы устройство могло отобразить чуть более яркий синий, более близкий по яркости к яркому зелёному).
Но тут мешает цветовая модель RGB, в которой (при глубине 24 бита) 0xFFFF00 и 0xFF00FF по яркости должны отличаться, а большие значения компонент не уместить в 24 бита. И если бы даже устройство автоматически умножало эти величины для сглаживания разницы в яркости, то это привело бы аду из настроек, цветовых схем, индивидуальных для каждого устройства, к искажению изображений, которые ориентированы на обычное использование модели RGB, да и к тому же этот запас в 20% может сильно зависеть от устройства, его конфигурации и размещения. Есть почти у каждого устройства возможности регулировки цвета, управления гаммой и т.д. Это всё почти никак не согласовано с источником изображения, т.е. сделав снимок на фотоаппарат вы можете быть абсолютно уверены, что на двух мониторах или фотопринтерах, которые состоят из идентичной компонентной базы, изображение будет радикальным образом различаться.
Снимок содержит всего-навсего битмап (который преобразован каким-либо образом, сжат и т.д. и т.п, но это всё не важно, он тем не менее представляет собой обычное растровое изображение). Т.е. яркий синий цвет даже если способна различить матрица фотоаппарата, то передать и вывести изображение не исказив никак невозможно (яркий синий будет ярким, но уже не таким синим, т.к. R и G придётся завысить). И не важно какая глубина использована, это будет касаться и 24 бит и 48 бит, технически предел ограничен RGB, в которой принято, что цвета 0xFFFF00 и 0xFF00FF имеют не одинаковую яркость (и так и должно быть, при этом подходе иначе возникнут лишние проблемы с технической стороной).
Имхо неплохая идея была бы помимо одного битмапа в файл-контейнер помещать так же сведения о настройках устройства (как в некоторых аудиоконтейнерах размещаются настройки эквалайзера, кое-что и так в JPEG помещается, но это лишь капля в море; а в частности необходимо туда помещать сведения о принятой для использования данным устройством концепции сопоставления частот и кодов RGB, соотношения кодов с кодами, получаемыми некой эталонной матрицей) и дополнительный битмап, который однозначно устанавливал бы способ трактовки предельных значений цветовых компонент в каждой точке, в которой таковые имеются (вызван ли засвет ограничениями матрицы фотоаппарата или просто пришлось его допустить для сопоставления пределов цветов с RGB). Тогда устройства могли бы просто игнорировать второй битмап, если они работают в предельном для себя режиме цветопередачи или просто не располагают алгоритмом его обработки.
Или можно просто перейти на HSV, хотя тут тоже без использования отдельных цветовых схем не обойдётся, т.к. опять же нет строгого стандарта на сопоставления частотных составляющих спектра и конкретного кода HSV. Ещё можно продвигать совместимость с Lab. HSV и так много где возможно использовать, но он тем не менее для вывода он будет с потерями преобразован (то же плавание яркости в кругах из той темы, которое навязывает специфичную концепцию ограниченных сопоставлений кодов и частот, навязывающих умещение HSV в менее объёмную RGB, от чего не получится уйти из-за того, что она устоялась и использована в уже имеющихся материалах) ещё до передачи устройству вывода (и технические возможности последнего опять же становятся малозначительными, а именно технические диапазоны яркостей каждого субпиксела или точки; кое-что регулируется применением цветовых схем и конфигурационных фич устройства, но потери тем не менее неизбежны, а стало быть искажения, вызванные применением RGB).
Ещё RGB не нравится статичностью глубины каждой компоненты. Глубина 24 бита означает, что канал G имеет глубину ровно 8 бит (а можно ведь и иначе распределить пространство 24 бит). Технически некоторые матрицы способны более точно распознавать (или отображать, если это устройство вывода) зелёную составляющую (в частности кое-где это обусловлено дублированием зелёного для использования избыточного пространства при построении субпикселов квадратами, т.к. 3 фотодиода не могут без избыточности заполнить квадрат), чем все остальные цвета. И если 256 значений окажется мало, то придётся так же увеличивать и остальные компоненты (даже если возникнут неиспользуемые биты).

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