RawDigger 1.2.3

Ссылки:

Изменения

Косметические:

  • Поддержка Sony RX1R-II (по сути, только цветовой профиль, все остальное и так работало)
  • Обновлен exiftool
  • Увеличена скорость работы при изменении параметров Selection Grid. Проблема проявлялась только на OS X 10.11, на остальных системах разница будет заметна только на очень больших сетках с тысячами ячеек.

Comments

вот спрошу для начала здесь... допустим я хочу сообразить matrix + trc профиль в icc/icm контейнере используя rawdigger и argyll (с makeinputicc gui), но хочу странного - т.е. не гамму(ы) в trc, а свою кривую в trc... правильно ли будет после экспорта данных снятых по сетке из мишени (применяем WB, но не применяем gamma и scaling) добавить в cgats с raw rgb и в файл описания мишени много много искусственных патчей дополняющих патч по которому был сделан WB но имитирующих greyscale шкалу например с в 256-4096 элементами, затем выполнить ручками (excel, matlab, etc) правку raw rgb для учета желаемой (вместо гаммы) кривой и scaling и затем все это скормить argyll... наличи серой шкалы в 256...4096 элементов будет таким образом argyll стимулировать к генерации правильныx shaper в TRC тэги icc/icm ?

или бред ?

N/A

Проще подменить TRC в профиле.

> Проще подменить TRC в профиле.

подмена да, простая - import в TRC например в утилите ICC Profile Inspector открыв имеющийся профиль и save as потом... но как быть с матрицей, не лучше ли argyll рассчитает матрицу если таки так модифицировать cgats с данными по снимнку и описание мишени ?

N/A

Матрица к TRC никакого отношения ж не имеет. Если имеет - плохо, неверно. Проверьте экспериментально? Например, если Argyll попросить создать профиль с гаммой и профиль с ЕКС - матрица одинакова ли?

> Матрица к TRC никакого отношения ж не имеет.

нуууу... на первый неопытный взгляд мы же модифицируем raw rgb в CGATS по-разному для разных trc перед argyll'ом, казалось бы что отличия должны быть в итоге для нелинейных кривых-то ... конечно надо попробовать, но нехотелось бы попасть на сломанные часы показывают правильное время два раза в сутки

N/A

У Вас матрица - RGB -> XYZ, XYZ линейно (gamma = 1).

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

N/A

Selection/Sample stats: discard abnormal pixel values if this setting is on (checkbox set) statistics for Selection and Sample discards 10% of highest and 10% of lowermost pixel values to filter off dust, scratches, small specular reflections, and other target/sensor defects.

---

откуда было взято именно 10% - интересно.

N/A

От фонаря, естественно.

а есть ли "use case" где этa oпция реально нужна помимо работы с мишенями (где конечно всякие волоса и прочие следу жирных пальцев сплошь и рядом) ?

N/A

Сделано именно для мишеней. Потому и только в Profile edition.

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

> Сделано именно для мишеней. Потому и только в Profile edition.

можно ли выдвинуть рацпредложение тогда... добавить в диалог создания сетки чекбокс который включает фильтр (по умолчанию например он при показе диалог отмечен - но на всякий случай пользователь может его отменить) + поле задания % (ну мало ли)... или просто одно поле задания % фильтрации где по умолчания в этом диалоге будет стоять 10% и пользователь может если надо ввести что он хочет - например 0% итд.... ну и в общих опциях оставить настройку то же... я бы предпочел в общих опциях ее никогда не менять оставив выключенной, а включать именно при работе с сеткой над мишенями (и соотв. опция с параметрами по умолчанию показывается в диалоге задания сетки)...

PS: и еще вопрос - при работе с сеткой как происходит фильтрация ? 10% по сенселям каждого прямоугольника внутри ячейки сетки для каждого такого участка индивидуально, так ?

N/A

Да, 10 процентов в каждом sample

вот спрошу для начала здесь...

а в LUT профиле (icc/icm) с PCS = cieXYZ надо в собственно 3Dlut от писать точки 0 до 32767, но не до 65535, так ?

N/A

а зачем в CSV пишутся координаты сэмплов (Left, Top, Width, Height) в виде чисел в кавычках (в то время как поканальные данные например без кавычек) ? мелкое меудобство

N/A

"Исторически"

У меня excel жрет их как числа, но вообще записал.

А в матлабе лишняя строка на это !

h_DS = datastore('tps.csv');
h_DS.ReadSize = 'file';
h_DS.TextscanFormats(5:8) = {'"%f"'}; % вот эта !!!
t_Data=read(h_DS);

N/A

Усвоил.

В следующем апдейте починим, когда он будет - не знаю (новых камер нет, затихло все).

Исправлено в версии 1.2.4

спасибо

N/A

ошибка

допустим померяли мы мишеньку, и допустим для какого-нибудь rgb пр-ва с g1 имеем:

R11 G11 B11 * M1(3x3) = X1 Y1 Z1
R12 G12 B12 * M1(3x3) = X2 Y2 Z2

cieXYZ из промерянного спектра, RGB подсчитано соотв. из cieXYZ/D50

теперь сняли в неровном освещении мишень, выбрали какой нибудь N1 из пред. текста и подобрали некую матрицу М2 чтобы

R21 G21 B21 * M2(3х3) = X1 Y1 Z1

так как освещение неровное то для другого патча

R22 G22 B22 * M2(3x3) * K = X2 Y2 Z2

где К отвечает за то что освещение другое

так как мы знаем

R12 G12 B12 * M1(3x3) = X2 Y2 Z2
R22 G22 B22 * M2(3x3) * K = X2 Y2 Z2

R11 G11 B11 * M1(3x3) = X1 Y1 Z1
R21 G21 B21 * M2(3х3) = X1 Y1 Z1

то

R12 G12 B12 * M1(3x3) = R22 G22 B22 * M2(3x3) * K
R11 G11 B11 * M1(3x3) = R21 G21 B21 * M2(3х3)

и можно посчитать K из 2 наборов промерянных RGB (при неровном освещении) и 2 наборов рассчитанных RGB , матрицы убираются делением

так ли это

и если так - не проще ли flat field делать таким образом ? т.е. это наверняка не так - но где ошибка ?!

N/A

Ну смотрите, у нас есть две группы нелинейных эффектов:
- "оптические": виньетирование, кривой свет, которые влияют на сигнал, попадающий на матрицу
- "электрические": шумы, нелинейность в тенях (в частности за счет шума)

Как вы предлагаете их разделить одним снимком?

> - "оптические": виньетирование

мишень занимает ну допустим 1/10 кадра по горизонтали, в центре.... никакого виньетирования не должно быть

> кривой свет, которые влияют на сигнал, попадающий на матрицу

ну вот мы его и выравниваем

> "электрические": шумы, нелинейность в тенях (в частности за счет шума)

давайте пока рассмотрим два хорошо проэкспонированных кадра мишени... которые далеко от теней... и потом рассчитывае К (см выше), я ж могу каждый темный патч экспонировать отдельно, а потом raw RGB для него просто делить обратно, т.е. перекспозиция относительно базового патча уберется, а вот неровность света останется...

вопрос же - в чем неправильна математика ?

N/A

> вопрос же - в чем неправильна математика ?

и конечно же если матрицы М2 (см выше) просто не существует теоретически (или у наилучшей матрицы погрешность будет больше чем выравнивание реальным flat field) для пары патчей, то понятно почему это не будет работать на практике.

N/A

Встав до 7 утра - я сегодня не в состоянии разобраться в математике. Не раньше завтра.

Поэтому я с позиций здравого смысла (он при вставании в 7 утра еще есть) рассуждаю.

Вот у нас есть две группы нелинейных искажений
- те, которые мы хотим компенсировать в профиле (нелинейность сенсора-ацп в тенях; на самом деле "общую нелинейность оптики" /светорассеяние/ - сюда же придется).
- те, которые мы не хотим компенсировать: кривой свет и (отрицаемое вами) виньетирование.

Я не вижу способа их разделить в одном кадре (второй, который "замер" т.е. идеальная модель мишени - в любом случае есть).

Ну вот у вас в темно-синем патче получилось больше зеленого, чем должно быть при расчете "по матрице".
За счет чего его больше: за счет кривого света (который не должен попасть в профиль) или за счет каких-то свойств камеры (кроссовер синий-зеленый, просто нелинейность в тени), которые мы собственно и хотим описать профилем?

> Встав до 7 утра

так это не вопрос жизни и смерти - можно подождать

> Ну вот у вас в темно-синем патче получилось больше зеленого, чем должно быть при расчете "по матрице".
За счет чего его больше: за счет кривого света (который не должен попасть в профиль) или за счет каких-то свойств камеры (кроссовер синий-зеленый, просто нелинейность в тени), которые мы собственно и хотим описать профилем?

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

виньетированние на ~1% площади сенсора (1/10 * 1/10) в центре кадра при зажатой диафрагме и достаточно длинном обьективе если даже и есть то его можно смело отнести к неровности освещения источником света и все.

кроссовер - ну он линеен относительно экспозиции же

N/A

Ну вот еще раз (я не понимаю как это еще подробнее сказать)

У вас есть две группы искажений. Одна - должна войти в профиль (потому что их мы и компенсируем), другая - нет.

Как разделить?

Нет, конечно можно считать, что вторая, та которая не должна войти в профиль, имеет какой-то характер. Ну там свет косой, но его косость описывается чем-то (уравнением 1-го порядка, к примеру). Тогда можно что-то сделать.
Без таких предположений - нельзя ничего.

В описанную выше математику я не вчитывался и не собираюсь. Считаете что она правильная - ну пользуйтесь.

> Как вы предлагаете их разделить одним снимком?

у меня не один снимок - у меня их два... один raw и один замер мишени (это как бы тоже снимок, в "идеальном" освещении который хочется использовать для рассчета отклонений в освещении мишени в raw -> вот я и хочу использовать замер мишени, для выравнивания raw RGB используя вышеприведенные формулы...

N/A

Замер мишени (реальный ли, идеальный ли) всегда есть, потому что иначе по одному кадру неизвестно чего (мишени с неизвестными цветами) мы и профиль можем построить только неизвестно какой.

собрался с духом и сменил таки boot в bios на ssd с W10

в rawdigger (1.2.3) стоит в настройках "save windows positions on exit", тем не менее при повторном запуске rawdigger не помнит что он был перед выходом максимизирован на весь экран... т.е. если он не максимизирован то он свое положение запоминает на экране, а вот максимизацию - нет... что я не так делаю ?

N/A

А максимизация и не запоминается.

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

И максимизация запоминается в 1.2.4 (но реально только на винде)

спасибо!

N/A

PS: а почему изнутри самой программы проверка наличия новой версии в RD (через пункт меню) не сработала ?

N/A

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

N/A

Потому что в апдейты добавляем не сразу.

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

Данный апдейт - он явно широкой аудитории не касается.

Add new comment