Про RPP и LibRaw

lexa - 06/Мар/2017 10:28

На всякий случай вот тут тоже напишу.

Raw Photo Processor переходит на декодирование RAW посредством LibRaw, вот доступны бета-версии.

В результате:

  • Будет поддержано больше камер, базовая поддержка новых будет появляться быстрее.
  • Неизбежны всякие косяки, которые мы постараемся быстро поправить.

Если вы пользуетесь RPP (или бросили пользоваться т.к. не поддержана новая камера) - тестируйте, жалуйтесь, нет жалоб - нет исправлений.

Comments

Andrmar (not verified) - 06/Мар/2017 13:43

Есть несколько вопросов. Раз RPP теперь декодирует с LibRaw, а FRV так же построено на LibRaw, то:
С какими настройками надо запустить RPP, чтобы получить вид как в предпросмотре FRV?
С коэффициентами ББ в FRV не всё ясно. Т.е. когда есть когда запись .rpps включена ББ выглядит потом в RPP вполне адекватно, а можно значения, которые "уйдут" в RPP увидеть в FRV?

lexa - 06/Мар/2017 22:25

декодирование - одинаковое, а дальнейшая обработка - разная.

lexa - 06/Мар/2017 22:26

Значения ББ: Preferences - White Balance - WB display mode, поставить в WB Coefficients

Andrmar (not verified) - 07/Мар/2017 09:11

Это да. Только на лицевой стороне они одни, для того чтобы увидеть надо ткнуть в панель коэффициентов. И там до второго знака. Поэтому не был уверен, что это правильные.

lexa - 07/Мар/2017 10:24

До второго знака - это примерно единичка в Tint и несколько градусов в CCT (если в районе 4500-8500к).

Больше точности не надо (а место в нижней панели - дефицит, не у всех мониторы 4k)

mikeuz - 07/Мар/2017 22:23

При чём здесь 4к?
Если даже RPP переходит на LibRAW - это о чём-то говорит!

lexa - 07/Мар/2017 22:30

4k при том, что места в нижней строчке у FRV не хватает на все хотелки.

Andrmar (not verified) - 08/Мар/2017 13:44

Ооо. Если RPP переходит на LibRAW это здорово. Поскольку FRV и RawDigger мультисистемные, а любимый workflow до этого был только для Маков.
Еще бы пару профилей пленочных все же допилили, которые в статье "Кнопка Шыдевыр" описывались еще 2010-м.
Kodachrome 25, Ektachrome 100VS , но по сравнению с RPP под вендами это конечно ещё лет 7 может ждать.

lexa - 08/Мар/2017 14:26

"Системность" RPP от перехода на LibRaw - не изменится. LibRaw - это только декодер raw-данных, ничего более.

Профили - не ко мне.

crypt (not verified) - 10/Мар/2017 22:38

Смотрю, здесь в блоге какая-то активность и кто-то что-то знает о raw'ах? Вопросы все хочу кому-нибудь задать. Я вот совершенно не понимаю, на основании чего и каким образом выставляются множетели для WB. Откуда возникает (вычитывается, как расчитываются множетели) as shot и почему он отличается от всех остальных конверторов с такими же настройками as shot. У dcraw свои множители. Есть какая-то формула, чтобы я мог связать все эти множетели, настройки камеры (ставлю фиксированный WB в кельвинах) и температуру цвета в конверторах без множителя. Т.е. хотелось бы по возможности какого-то консистентного и предсказуемого результата. Документацию тоже не нахожу.

lexa - 11/Мар/2017 10:59

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

Я не знаю где найти написанную человеческим языком документацию, а алгоритм такого пересчета (CCT-множители и обратно) есть в исходных текстах Adobe DNG SDK (и есть в RawTherapee, причем не факт что два алгоритма совпадают). Соответственно, не на человеческом языке, а на C++.

lexa - 11/Мар/2017 11:05

Да, а множители As Shot, по счастью, не надо считать. Их пишет камера в метаданные RAW-файла. В виде множителей, не в виде температуры.

crypt (not verified) - 11/Мар/2017 16:04

По первому ответу: я код читаю с трудом, буду думать, спасибо.

> а множители As Shot, по счастью, не надо считать.

Это точная информация? Сами видели? Для каких производителей это правда? Эти множители у меня как раз разные в dcraw и rpp.:(

lexa - 11/Мар/2017 18:52

Я не могу отвечать за RPP, спросите у автора. Но вообще, AsShot больше неоткуда читать, кроме как из камеры (нет ли путаницы с Daylight?)

lexa - 11/Мар/2017 18:54

Ну и да, если говорить о свежих бетах RPP, которые на LibRaw, я не просто "сам видел", но к этой самой LibRaw приложил некоторое количество усилий, 1166 коммитов по подсчетам гитхаба: https://github.com/LibRaw/LibRaw/graphs/contributors

ib - 11/Мар/2017 18:57

В RPP индицируется log2 от коэффициентов баланса.

lexa - 11/Мар/2017 19:08

Я, вот одно место еще не откомментировал, а оно явно нуждается
>> ставлю фиксированный WB в кельвинах

Вы его поставили. Камера - по встроенному в нее цветовому профилю - пересчитала в коэффициенты. Потом конвертор - по своему профилю - в ЦТ.
Результат чудовищен, ставим на камере 6500, в конверторах разных видим 5000-8000 (цифры от фонаря, но на 1000к разные конверторы запросто расходятся даже в области daylight, не говоря о вечерней съемке с высокими ЦТ).

crypt - 13/Мар/2017 13:23

Да, понимаю, полностью логично. Расходятся даже значения в камере и в официальной програмулине. А имеет ли смысл посредством x-rite color passport составлять профиль для камеры? Я как-то сделал DCP профиль (adobe tools) при искусственном освещении так с ним все лица стали походить на морковки! Является ли профиль по 24 патчам достаточно качественным, чтобы накладывать его на то, что получается внутри камеры или он слишком прост в сравнении с внутренним и только исказит цвета? Беглый поиск на тему вшитого профиля не дал мне ясного представления. Вроде как там 3 primary colors в виде матриц и, возможно, еще какая-то таблица (типа HSV) для корректировки остальных цветов, но так это или нет, я не знаю. Кроме того не знаю, калибруют каждый отдельный сенсор при выпуске или там идет усредненный профиль.

lexa - 13/Мар/2017 13:36

Профиль для расчета цветовой температуры и профиль используемый для показа - это могут быть и разные профили, зависит от конкретной программы.

Что касается ColorChecker 24, то по нему получаются вполне качественные профили. Но совершенно несложно получить и некачественный: неравномерное освещение и/или неверный референс-файл способны все испортить.

crypt - 13/Мар/2017 14:58

Заодно вопрос насчет FastRawViewer. У меня не получается использовать, потому что я хочу отправлять фото в фотошоп (т.е. иметь превью ACR like), а с gamma 2.2 превью получается слишком неконтрастным, а с variable contrast наоборот выходит слишком контрастно по сравнению с адобовскими программами. можно как-то сделать картинку похожей? Есть какой-то набор настроек "сделать как в Adobe" или такого не предусмотрено? какой при этом профиль камеры используется?

lexa - 13/Мар/2017 15:21

А какая камера?

В принципе, variable contrast (с движком контраста в 0) довольно близко к Adobe по контрасту (ну с той поправкой, что у нас немножко разные тоновые кривые, но именно что "близко").
Ну вот первый попавшийся кадр, ACR (все по нулям) и FRV: https://www.dropbox.com/s/rbkiuoxw1llmsv3/Screenshot%202017-03-13%2015.1...
(красный у нас с Adobe разный потому что их увод в морковный мы осуждаем, но контраст то - ну близкий)

Вот наводящий вопрос: если у вас Windows, то вы Color Management в FRV конечно же включили?

UPD: профиль для показа свой, расчет CCT - адобовский.

lexa - 13/Мар/2017 15:33

С вертушкой был - на весь диапазон яркостей.
А вот неконтрастный кадр: https://www.dropbox.com/s/bhm6bt064kpspkg/Screenshot%202017-03-13%2015.3...

Ну зеленый несколько отличается, цветовые профили разные. Но контраст - ну совсем близко, как по мне, для целей отбора более чем достаточно

crypt - 13/Мар/2017 18:23

nikon d750. про красный понятно. пардон, не вижу никакого движка, который можно двигать в ноль. ни в настройках, ни в интерфейсе. где крутить волшебный движок?

вот, как выглядит сейчас

https двоеточие, два слеша xvi.crypts.me:5083/2017-03-13.png

картинка с профилем. включен adobe hidden exposure correct, set hidden expo correct to 0.75 EV. в FRV на мой взгляд явно более насыщены ораньжевые и зеленые квадраты, больше контраст в переходах светлый-темный на одежде.

> Вот наводящий вопрос:

тут все ок. конкретно сейчас загружен мак (потому что заодно тестирую RPP), CM включен. кстати, если для thumbnails ставлю тоже обрабатывать в ProPhoto, они краснеют. становится не похоже на большую картинку. не знаю почему.

lexa - 13/Мар/2017 18:37

Главное: контраст это контраст (ну вот можно серую шкалу снять и сравнить), а насыщенность - это насыщенность.
Полного соответствия по цветам с кем-либо мы не обещали (особенно с Adobe). Контраст же - вот с какой-то разумной точностью держим.

>> set hidden expo correct to 0.75 EV.
А зачем? Там стандартная величина должна быть правильной и соответствующей Адобу. То что вы поставили -в FRV стало примерно на 2/3 стопа светлее (чем в Adobe, коррекция экспозиции по нулям)

>> пардон, не вижу никакого движка, который можно двигать в ноль
Menu - Adjust - Increase/Decrease contrast (ну и индикатор контраста со стрелками вверх-вниз правее индикатора цветовой температуры)

>> если для thumbnails ставлю тоже обрабатывать в ProPhoto
Это не "обрабатывать", это 'Assign profile' по сути. Камеры умеют превьюшки писать в sRGB (обычно), Adobe (если включить), профото (некоторые кодаки, если не путаю). Вот в соответствии с настройкой камеры - это и ставится.

crypt - 13/Мар/2017 19:15

> А зачем? Там стандартная величина должна быть правильной и соответствующей Адобу.

если отключить компенсацию совсем - очень темно. оставить по дефолту - добавляет 2.65 EV и ес-но очень светло. не знаю почему.

> Главное: контраст это контраст

в цветах же у меня контраст всеравно присутствует.

> со стрелками вверх-вниз

а! стрелки! если поставить -1 становится более похоже и в цветах тоже. не знаю, может, закрепить это где-то по умолчанию.

а если поставить gamma 2.2 - это будет просто компенсирующая гамма и я буду видеть примерно то же, что было при съемке? или кривые какие-то еще добавляются?

lexa - 13/Мар/2017 19:26

>> если отключить компенсацию совсем - очень темно. оставить по дефолту - добавляет 2.65 EV
"по дефолту" - это если Shift-A нажать? Это "сдвиг гистограммы к правому краю". В принципе полезная вещь, но надо понимать зачем.

У D750 стандартная компенсация для ISO от 100 и выше - 0.1EV. И судя по тому что рендеринг в скриншоте вашем - систематически светлее в FRV (потыкал пипеткой, но в EV пересчитывать не стал) дело то в этом.

То есть стандартные настройки (defaults) - для работающих с Adobe должны быть OK, менять их имеет смысл только для камер, которых мы вдруг не знаем, а Адоб - знает (но таких очень мало).

>> если поставить gamma 2.2 - это будет просто компенсирующая гамма
Я не вполне понял вопрос, но наверное да. В смысле - там из линейной (RAW) в экранное - вот эта вот гамма (+профиль экранный если есть)

crypt - 13/Мар/2017 19:56

> "по дефолту"

Я имел ввиду, что галочка Apply Adobe hidden expo... стоит, а Set hidden value не стоит. Ладно, я возьму таймаут на подумать.

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

lexa - 13/Мар/2017 20:00

Если Apply hidden стоит, а set hidden - нет, то применяется некое внутреннее умолчание, которое соответствует адобовской поправке (если мы вдруг провираемся - хотелось бы примеров).

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

crypt - 13/Мар/2017 22:21

Я думаю, уж на никоне много народу эти функции использовало, если бы с вашей стороны были ошибки, давно бы зарапортовали... у меня в AB еще lens corrections включены, они осветляют. Я вот еще что не пойму. Если у FRV есть все эти ручки для приведения изображений к какому-то виду, то почему нет возможности тут же экспортировать в tif? Если я из него пытаюсь отправить файл в фотошоп, то всеравно попадаю в ACR и файл приходится настраивать снова.

lexa - 13/Мар/2017 22:33

К экспорту нужно еще кадрирование и поворот на произвольный угол.

Будет. со временем.

crypt - 14/Мар/2017 11:43

ох, ребят... я занимаюсь софтом, не связанным с обработкой изображений и мне вас (всех, кто делает граф. программы) никогда не понять! кадрирование везде можно сделать, а цвета уникальны для каждого проявщика и, если их невозможно передавать из программы в программу, то и pipeline прерывается. уж вам поди ничего не стоит сформировать tif и сбросить в файл.

p.s.

это ни коей мере не упрек. выражаю только свое непонимание.

lexa - 14/Мар/2017 12:00

Ну вот поверьте на слово: у нас есть совершенно нетехнические (записать 8-битный TIFF из экранного буфера в файл действительно подъемная задача) соображения делать именно так - отложить на следующий крупный апдейт, даже не на 1.4.

И технические соображения тоже есть, сделанная сейчас эта фишка будет "на выброс", в версии "после 1.4" ее придется полностью выкинуть и сделать заново.

crypt - 14/Мар/2017 12:10

конечно, верю. не вопрос. спасибо помогли мне немного разобраться в теме.

hardy - 13/Окт/2017 22:21

... хоть как-то сохранить то, что делалось в FRV. TIFF решил бы эту проблему.

Возможно, что darktable сможет читать XMP после FRV, но пока это не подтверждено. LR/PS у меня нет.
Ждем версии "после 1.4".

lexa - 14/Мар/2017 12:17

Ага, вот еще не отвечено:
>> если поставить -1 становится более похоже и в цветах тоже. не знаю, может, закрепить это где-то по умолчанию.

Preferences - Image Display - Contrast setting on next file: Keep from prev. file
Не оно?
Ну то есть расчет на то, что снимают обычно сериями т.е. для следующего кадра настройки от предыдущего - подходят (как правило).

Аналогичные настройки есть для Exposure Correction и для White balance.

(и есть еще Force XMP files creation, если ее включить, то если вы открыли файл с унаследованными от предыдущего параметрами - эти параметры будут записаны в XMP даже если вы ничего руками не меняли. Дальше их всосет Адоб)