Ответ: Разрядность мониторов и регулировка цветовой температуры.
Не по теме:
Топик порядочно запутался с этими двумя новыми вопросами, поднятыми probep. Так прямо сразу и не поймёшь, в каком постинге о чём речь: где о программировании LUT видеокарты посредством 16-битных значений, а где — о 10-битном интерфейсе между видеокартой и монитором.
Вчера таки проверил, как же на самом деле 16-битные значения, подаваемые на вход функции SetDeviceGammaRamp, преобразуются в 8-битные для загрузки в LUT видеокарты, — делятся ли они на 256 путём отбрасывания младших битов, или всё же на 257, по-универсальному. Эксперимент с многими градациями в разных сочетаниях показал, что действительно, увы, [HIGHLIGHT]имеет место тупой сдвиг вправо на 8 бит[/HIGHLIGHT], как и утверждал
probep.
Я поначалу хотел перепроверить на видеокарте другого типа, — а вдруг у ATi и nVidia драйверы ведут себя по-разному, — но наткнулся на топик по OpenICC, где небезызвестный Graeme Gill излагает свои наблюдения о
LUT-технологиях в разных системах, а ему по поводу неработы SetDeviceGammaRamp под Windows NT 4.0 указывают на
наличие ещё одной функции: она классифицируется скорее как средство доступа к драйверу, нежели как высокоуровневый сервис для клиентских приложений, и называется
DrvIcmSetDeviceGammaRamp.
Сама по себе функция ничем вроде не примечательна, и весьма напоминает обычную SetDeviceGammaRamp, только лишённую простого указания на номер целевого экрана. Однако в её описании есть интересные слова.
Each value is described using 16-bit precision. If the hardware has fewer bits of precision, it [HIGHLIGHT]should downshift and use the most significant bits, without rounding[/HIGHLIGHT].
В комментариях к обычным
SetDeviceGammaRamp и
GetDeviceGammaRamp присутствует только расплывчатая формулировка про «most significant bits», что и порождает путаницу.
Ну что ж, браво, Microsoft! Как всегда, отчебучили. Видимо, у них там проектированием системы занимались люди с таким же «ассемблерным» сознанием. Предусмотрели 16-битовые значения, но забыли подумать головой о том, как же в реальности их можно будет использовать. Или, может, они рассчитывали, что загрузчик LUT (который они по неведомой причине всё равно не собирались писать самостоятельно) будет каким-то чудом оперативно определять, какой разрядности сейчас связь между видеокартой и монитором (она не обязана совпадать с глубиной цвета рабочего стола), и динамически масштабировать значения из профиля под текущий режим.
Это из той же оперы, что и общая глубина цвета. Я уже говорил, что даже в Windows XP (а может, ещё и в 2000) вполне возможно создавать растры с глубиной цвета до 10 бит на канал, а монохромные — до 32 бит. Однако всё те же функции Get/SetDeviceGammaRamp готовы работать только с массивами из 256 значений на канал, даже в 5/6-битном режиме; не удивлюсь, если где-нибудь существует инструкция, что выборка 32-х элементов из такого массива должна вестись с шагом 8 ступеней, а не 255/31.
Какие отсюда следуют выводы?
- Калибровщики типа Spyder, случайно или осознанно, действуют как положено.
- Другие программы, в том числе Gretag/X-Rite, работают «неправильно» — не так, как задумали «ассемблерщики» из Microsoft.
Понятное дело, что Microsoft ничего исправлять не будет; во всяком случае, не в «классических» интерфейсах — может, разве только в новой WCS, да и то не раньше, чем многобитные продукты станут привычной вещью. Значит, остаётся только подавать петицию в X-Rite, чтобы подстроились под глубинный замысел редмондовских чудиков. Думаю, они должны среагировать на то, что их по сути правильные действия в реальности приводят к худшему результату.
