FastRawViewer 0.9.4 (PreBeta4): Color Management

lexa - 06/Окт/2014 13:24

Просили Color Management в FastRawViewer? Раз просили - теперь тестируйте! Ссылки для скачивания - в конце поста.

Чтобы включить Color Management, нужно

  • Скачать тестовую версию.
  • Запустить
  • Пойти в настройки (Ctrl-P), там в Color Management и включить галку "Enable Color management"
  • При необходимости, поправить и другие настройки CM
По умолчанию, поддержка Color Management выключена, мы считаем это правильным потому что:
  1. Большинство современных мониторов - sRGB (или близко к нему) и использование sRGB как рабочего пространства при показе RAW дает вполне приемлемые результаты.
  2. Во многих случаях, пользовательские мониторные профили - плохие, их использование ухудшает результат.
  3. Заметное количество пользователей модифицировали настройки своего видеоадаптера "для старых игр", включив насильную анизотропную фильтрацию текстур. Этот режим несовместим с Color Management у FRV (потому что ColorManagement сделан средствами видеокарты, это не потребляет ресурсы CPU и вообще работает очень быстро, но вот такой вот сайд-эффект).
В процессе разработки-отладки я, со своим wide-gamut монитором вообще вот понял, что вьюеру Color Management не очень нужен: цвета в любом случае не финальные, в подавляющем большинстве случаев я буду поднимать насыщенность при редактировании и то, что мне ее поднимает монитор - очень даже хорошо.

Теперь, собственно, просьба к тестировщикам:

  • FRV при включении Color Management, или при старте с включенным CM, у себя внутри рендерит картинку (не показывая юзеру) и сравнивает с эталоном. Если тест не прошел - ругается и просит выключить анизотропную фильтрацию и анти-алиасинг (ежели они включены в настройках драйвера для всех программ).
  • Для сравнительно новых видеокарт и только для OpenGL-версии, анизотропную фильтрацию можно обойти средствами OpenGL. В этом случае FRV не будет ругаться даже если анизотропка насильно включена.
  • Меня интересуют случаи, когда
    • Детектор проврался. У вас ничего такого не включено, а оно ругается.
    • Детектор проврался. Ничего не сдетектировал, а картинка при включенном CM выглядит "в крапинку"
В обоих упомянутых случаях - пишите жалобы, лучше с подробным описанием проблемы (версия операционки, видеокарта, версия драйверов, версия FRV /сколько бит, OpenGL или DX9/).

Остальной Changelog не привожу, он здоровый и сильно технологический, из видимых пользователям изменений - только новые камеры (10 штук) и исправление не слишком существенных ошибок. В процессе установки вы можете попросить инсталлятор вам его показать.

Ссылки для скачивания

Comments

Serge_e - 06/Окт/2014 18:19

Я правильно понимаю, что в многомониторной (2 шт) системе, если надо чтобы СМ работал правильно на другом мониторе (захотел зачем-то перетащить туда окно FRV), надо перетащить, закрыть, открыть. Тогда будет корректно.

lexa - 06/Окт/2014 18:27

Проще снять галку 'use system' и выбрать нужный профиль руками.

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

Mike (not verified) - 06/Окт/2014 21:22

Первая ссылка в статье битая, нет такого сайта - http://www.fastrawviwer.ru/

lexa - 06/Окт/2014 21:58

Спасибо, поправил.

netopyrr - 06/Окт/2014 22:07

мне вот совершенно непонятно, зачем такой вьювер в отрыве от конвертера. продайтесь какому-нибудь adobe уже наконец

lexa - 06/Окт/2014 22:19

Мне казалось, что вьюер RAW нужен тому кто снимает в RAW. Включая и авторов вьюера.

kiavan92 - 07/Окт/2014 00:36

То вам RawDigger нужно скрестить с FRV, то уже конвертер...
Завтра вы захотите инструменты для ретуши, послезавтра — склейку в HDR или панораму. Потом у вас на карте памяти полетит ФС и вы попросите инструмент для восстановления файлов. Там и до отдельной ОС дойдёт.
AcdSee, в таком случае, чем вас не устраивает?

netopyrr - 08/Окт/2014 01:32

AcdSee не понимает фуджирав =)

kiavan92 - 08/Окт/2014 01:43

RPP понимает. А ещё даст вам и детализацию, и цвета.

netopyrr - 08/Окт/2014 01:54

разве что под виртуальной машиной, так как не все в этом мире маководы

kiavan92 - 08/Окт/2014 02:00

Я, вот, не маковод, однако OS X у меня имеется в двух экземплярах: полноценная на ноуте и виртуальная на десктопе. Тут всё от желания зависит.
Если вас интересует результат вывода из RPP, дабы понять, нужно оно вам или нет — залейте свою равку какую-нибудь.

netopyrr - 08/Окт/2014 02:04

а вы специалист по демозаике xtrans? =)

kiavan92 - 08/Окт/2014 02:07

По-моему, я вам просто предложил попробовать RPP в качестве альтернативы другому софту. Понравится — хорошо, не понравится — ну, будете дальше искать.
Я не говорил, что я специалист по Фуджи, и, тем более, я не разработчик RPP.

n/a (not verified) - 07/Окт/2014 00:28

> потому что ColorManagement сделан средствами видеокарты, это не потребляет ресурсы CPU и вообще работает очень быстро, но вот такой вот сайд-эффект

вопрос в сторону - подумывая об обновлении notebook (PC) и выбирая из вариантов с 880M (8Gb), 870M (6Gb), 870M (3Gb), 860M (4Gb), 850M (2Gb) - бюджет на это _НЕ_ неограничен (ну то есть надо будет выбирать между более хорошей карточкой и другими вещами) - что есть cost effective (например для использования FRV) в расчете на возможный размер raw до 50mp с частной точки зрения блоговладельца (и не стоит ли смотреть на AMD вместо NVidia) ? сейчас достаточно древняя 525M (1Gb) и 16mp - 24mp raw...

lexa - 07/Окт/2014 08:50

Для текущей FRV особо продвинутая видеокарта не нужна. Я между Intel Iris Pro 5000 и NVidia 750M не вижу большой разницы на макбуке (она есть, но на глаз не видна, только в тестах с детайльным таймингом).

В настоящее время максимум который может потребоваться FRV (даже не текущей, а чуть следующей версии) от видеопамяти, это 2 JPEG полного разрешения (по 200Mb для 50Mpix) и три битмепа полновинного (50Mb для 50Mpix), всего - примерно полгига для 50Mpix (реально там драйвер будет свапить текстуры которые не поместились поэтому хватит и 256M, но будет медленно).

Представим себе FRV, который делает демозаику высокого качества на видеокарте же. Это из 100M байера в 800M плавучки, плюс помянутые выше 2 JPEG по 200 - 2 гигабайт хватит с запасом на 50Mpix. И даже на 80Mpix хватит, если без JPEG-ов (а 2 JPEG полного размера обычно не бывает).

То есть касаемо FRV - я бы ограничился самой дохлой картой из перечисленных и не парился бы.

Если теоретически рассуждать о raw-конверторе на видеокарте, то там ситуация несколько хуже. Нужно будет держать минимум три битмепа полного размера в видеопамяти. 50Mpix в плавучке - 800M, значит вот 2.5Gb нужно.
Но это теоретическое рассуждение, может быть на практике получится работать с перекрывающимися тайлам (собственно, отчего бы не получится то...), работы больше, требования к железу - меньше.

n/a (not verified) - 10/Окт/2014 20:38

> 2 гигабайт хватит с запасом на 50Mpix.

а есть ли ПО которое может использовать лишнюю GDDR для каких нибудь полезных вещей (ну например виртуальный RAM диск) ? если вдруг пробегало мимо глаз в интернетах...

lexa - 11/Окт/2014 00:04

Сомнения меня берут.
А потом пришло другое приложение и тоже попросило видеопамяти. Куда драйвер денет ваш диск?

n/a (not verified) - 12/Окт/2014 23:21

похоже пред. постинг не дошел

> Куда драйвер денет ваш диск?

не отдаст !!! живет же FRV вместе и исполняется одновременно с другими программами которые используют GPU memory ? типа Capture One ... или я не прав ?

PS: а есть ли засада если плюнуть и соорудить external GPU ? если все равно с raw работаешь дома где большой монитор (и еще один ящик не сильно помешает), а на работе без разницы.

lexa - 13/Окт/2014 07:52

Ну в том то и фишка, что то как оно устроено в OpenGL/DX9 - это не захват ресурсов GPU. Ресурсы "загруженные в видеокарту" могут быть по факту скопированы в RAM, а в видеокарту ехать по потребности. Как вы понимаете, для рамдиска такой вариант не подходит.

Про External GPU не понял. По какому интерфейсу с ним общаться?

n/a (not verified) - 19/Окт/2014 02:37

а вот вопрос возник - может ли программа одновременно использовать и встроенный gpu типа iris'a того же и дискретный типа nvidia какой-нибудь ? или все устроено так что или-или.

lexa - 19/Окт/2014 09:04

Из общих соображений, для вычислений (OpenCL) - скорее да (я не пробовал!), для графики - скорее нет. Для графики ж вообще не приходится контекст создавать на указанном устройстве, оно как-то само.
Но и для вычислений - скорее всего не без приколов. В винде, скажем, карточка должна быть активной (инициализированой драйвером), а для этого к ней надо подключить монитор. Как это устроено в системах с динамическим переключением GPU (ну вот в ноутбуках, Iris/Nvidia) - пока не могу сказать. OpenGL работает прозрачно, операционка как-то разумно переключает.

n/a (not verified) - 07/Окт/2014 08:56

это по памяти видеокарты, а по скорости обработки на ней когда все уже там ? или все это фигня по сравнению с чтением с SSD/HDD/NAS в RAM потом в карту ?

lexa - 07/Окт/2014 10:28

По скорости обработки: на софтверном эмуляторе OpenGL оно тормозит, это да, особенно если на одном ядре CPU. И то, сильно тормозит только focus peaking, остальным даже можно пользоваться.

На аппаратном OpenGL/DX9, ну давайте прикинем. 200 операций на экранный пиксель (от фонаря, не 20 и не 2000). 850M - это 640 ядер грубо на гигагерце, 600гигафлопс. То есть ~3гигапикселя в секунду или 50мегапикселей за время смены кадров (60fps) может отрисовать.

Но это экранные пиксели, не RAW. На мониторе у нас от 2Mpix (HD) до 8Mpix (4k). То есть у 850M будет запас раз в 6 на 4K и в 25 раз на HD.
Причем, на самом то деле экран перерисовывается не 60 раз в секунду, а только если что-то поменялось (кнопку нажали, окно поресайзили). То есть если пропустит фрейм-другой - никто не заметит. Если ничего не меняется - то перерисовки нет.

Там тормозит другое. При переключении RAW/JPEG - картинка всякий раз загружается в карту заново, хотя этого можно и не делать бы. Поэтому по кнопке J оно подтормаживает и видна разница между старой PCIe2 картой (~3Gb/sec аплоада) и новыми PCIe3 (~12Gb/sec). Но это мы порешаем со временем. И, смешно, но процессорные видюхи в этом месте у отдельных выигрывают потому память-память быстрее, чем память-PCIe.