Если вдруг у вас были проблемы с детектором анизотропной фильтрации текстур у нового FastRawViewer, то скачайте и попробуйте еще раз по ссылкам ниже.
Если проблем не было, то не качайте и не пробуйте, других изменений, кроме детектора, нет.
Из смешного. Выяснил что у NVidia GT610, если вы включили насильную анизотропку в драйвере, драйвер может посмотреть на программу, подумать и выключить обратно. Эффект устойчивый.
Вот у нас сенсор (+АЦП). Сигнал от него, как я понимаю, линейный с высокой точностью. Даже если точность не очень высокая, то откалибровать отклик конкретной модели сенсора не должно составлять труда. Перед сенсором светофильтры. Они тоже линейно сворачивают спектр в скаляры. RGB-пространство тоже линейно, ну гамма там по яркости. Получается, что задача преобразования сигнала от сенсора в RGB линейная с точностью до одной единственной заданной гаммы. Значит, чтобы заставить монитор светиться так же как светился объект перед камерой, достаточно линейно преобразовать сигнал от сенсора. С точки зрения цвета это означает ткнуть пипеткой в нейтральный объект и таким образом найти взаимные коэффициенты для трёх каналов. Ну и гамму потом наложить. Всё, этого должно быть достаточно.
Что я упускаю? Потому что если я ничего не упускаю, то совершенно непонятно, почему разные конвертеры по-разному разрешают и передают цвета с разных камер а они таки их передают по-разному.
Отвечаем (чуть подробнее, чем в том комментарии в ЖЖ):
А ты, Вовочка, молчи, а то мы всю физику к ..уям сведем... анекдот
О консенсусе
Несмотря на мой скепсис в отношении цветовой науки и любви потоптаться по святому,
прикладную задачу копирования изображений я считал решенной (как минимум, в простых случаях).
Ну вот есть файл (RGB), к нему прилагается профиль (ICC), следует ожидать что на одном и том же устройстве (LCD мониторе, чтобы быть конкретным) он
при включенном Color Engine отобразится более-менее разумно и одинаково.
Естественно, предполагается что все необходимые условия соблюдены: монитор отпрофилирован, показываемые цветовые данные привязаны к цвету (снабжены профилем), условия наблюдения постоянные, программа показа розумиет ICC, наливай да пей бери и выводи.
Конечно, жизнь несколько богаче и 2.5 года назад я уже исследовал проблему точности CMM (Color Management Module) и написал про это серию статей.
Но я наблюдал в эксперименте разумные ошибки - 5-6, а для хороших CMM и 8 бит данных сохранялись, отклонения от смены CMM в худшем случае были
заметны глазом, но не были фатальными.
Да, на картинке слева вы видите кусочек из этого файла, показанный на одном и том же мониторе, с одним и тем же профилем монитора, одним
и тем же профилем при цветовых данных файла, одной и той же программой (Adobe Photoshop) с одними и теми же настройками за исключением одной....
Мониторы с большим цветовым охватом (вроде того, за которым я сейчас пишу этот текст создают понятную проблему:
Если расширенный охват используется (у монитора не включили насильно режим sRGB или что-то такое), а программа показа картинок цветовых преобразований делать не умеет, то вы увидите на экране фигню.
Ну совсем грубо, RGB (255,0,0) - это на двух мониторах ("обычном" и "расширенном") будет красный цвет, соответствующий красному углу охвата. Только красный этот будет сильно разным, см. например картинки с охватом
На скриншоте ниже четыре (на самом деле 2) варианта показа на мониторе одной и той же картинки: