RawDigger 1.2.16 (release candidate)

Что-то давно мы RawDigger не обновляли. Значит пора, заодно и юбилейный билд:

Update: RD 1.2.16 выпущен, брать на официальном сайте

Изменения:

  • Поддержка камер:
    • Canon EOS M5
    • Google Pixel, Pixel XL
    • Hasselblad X1D, True Zoom
    • Olympus E-M1-mkII
    • Panasonic DMC-FZ2000/2500/FZH1, DMC-LX9/10/15
    • Samsung Galaxy S7, S7 Edge
    • Sony ILCA-99M2 (A99-II), ILCE-6500
  • Exiftool обновлен до  10.36
  • Исправлена проблема показа некоторых старых Canon sRAW

Пробуйте, жалуйтесь. Не пожалуетесь - выпустим эту версию в качестве релиза.

Comments

переписка с Adorama на тему почему TTL у XPLOR600TTL строба не вполне работает с transmitter'ом для Sony (после засылки серии raw снятых на разных диафрагмах)

[quote]

Adorama Brands
Today at 4:39 PM

...I cant view the raw files...

[end quote]

подарите им лицензию что-ли (trial я уже предложил)...

Z / V

Пусть на B&H купят :)

> Пусть на B&H купят

в смысле B&H продает rawdigger ? пойду посмотрю ...

Z / V

и действительно = https://www.bhphotovideo.com/c/search?Ntt=rawdigger&N=0&InitialSearch=ye...

понятно где собака порылась...

Z / V

Так ить больше года уже.

вот что отсутствие rawdigger'а с людьми делает :

"...TTL output was always well lit with detail visible
There were slight variations, with more consistency at higher apertures
Below f/2.5 images were slightly brighter, still within detail acceptability
The biggest variation was between the 2 shots taken at f/3.5 and at f/4 - it was a visible jump in the image and histogram..."

поток прилагательных... плюс по бедности всяли другую камеру (A7+FE28/2), как будто в магазине нет A7R2+FE55/1.8

придется мне им повторить в raw+jpg режиме ( Adorama rep из поддержки FlashPoint их брэнда еще просил снимки содержимого заднего экранчика камеры - похоже для ooc jpg гистограммы )

Z / V

Я, в общем, не знаю что вы от них добиваетесь.

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

> Я, в общем, не знаю что вы от них добиваетесь.

берем M режим на камере (включая fixed ISO = 100 и exposure time = x-sync, 1/250 в данном случае) и ставим на камеру TTL вспышку Sony (все FEC везде по нулям, FEC = flash exposure compensation)... включаем spot metering по куску пенопласта и делаем серию снимков от f/2 до f/11 с шагом 1/3 EV ... берем rawdigger и смотрим кусок который мы spot meter'или на пенопласте... все хорошо для TTL, saturation колеблется в пределах 1/3 EV = жить можно... снимаем TTL вспышку Sony и ставим FlashPoint/Godox TTL transmitter + ТТЛ strobe... повторяем процесс... видим что начиная с f4 и темнее все хорошо и похоже на родную вспышку Sony... a в диапазоне f2 ... f4 TTL с transmitter'ом недонасыщает (причем на f2 на 2+ стопа... ) - причем график линейно растет до f4 и начиная с f4 начинается ожидаемое насыщение... явно же bug ! причем TTL transmitter у Godox должен просто имитировать накамерную вспышку для камеры (снимается в том же режиме - т.е. не wireless, a fill-in - как будто вспышка на камере строит).

Z / V

> все хорошо для TTL, saturation колеблется в пределах 1/3 EV = жить можно.

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

Z / V

Ага, если оно не матчит родную вспышку - понятно к чему претензия.

Но, в принципе, это будет видно (может не так наглядно за счет нелинейности) и по JPEG

> Но, в принципе, это будет видно (может не так наглядно за счет нелинейности) и по JPEG

конечно, но я с горяча снял серии в raw и там еще UniWB для встроенного thumbnail... короче пересниму я им в raw+jpg с фиксированным "человеческим" ББ вместо UniWB и приложу снимки lcd экранчика вдобавок...

Z / V

> Но сама по себе идея работать с JPEG - она здравая т.к. что там камера думает про raw и насколько его поднимает (и в каких режимах) - не дело ж вспышки.

дело TTL вспышки (вернее firmware в том что стоит на камере в башмаке) обеспечивать более менее ровную экспозицию при изменении параметрa типа диафрагмы на объективе если снимаемя сцена, замер и все остальное одинаковое (меняем только диафрагму) и мы не выходим ни за макс. мощность вспышки ни за мин мощность вспышки, причем с хорошим запасом по обоим концам... в чем и суть претензии

Z / V

в процессе продожающихся препирательств с Adorama заодно выяснил для себя что spot-metering (у Sony A7R2) если используется TTL flash (родной, не родной - без разницы) вовсе не работает /т.е. измерение явно не по spot/ в отличие от ситуации с ambient light ... интересно а как с этим у dSLR от Canon & Nikon (про никон вопрос IB - наверняка же исследовал когда-то)

Z / V

зачем у меня не сохраняются (file -> screenshot) скриншоты в .jpg ? в .png сохраняются ... куда бежать смотреть ? т.е. никаких ошибок после нажатия в окне диалога кнопки save нет /видимых глазу на экране/... а файла в обозначеном месте - нет !

Z / V

Windows или мак?

Win8,1 - "у меня все работает", хочу больше подробностей.

Ага, а на 10-ке хрен. Ну ладно, jpeg.dll все едино с собой таскаем, сделаю им.

> Ага, а на 10-ке хрен.

именно W10x64

Z / V

Обновил версию тут: http://www.rawdigger.ru/download
Тестируйте, жалуйтесь.

пора отвлечься от суеты с UI в FRV... вопрос - зачем "страдать" экспонируя мишень (для профилирования) "по максимуму" , если S/N усреднении допустим 2 сенселей (мы же не мишени для разрешения снимаeм, деталей не хранить) = (S1 + S2) / sqrt (N1^2 + N2^) ... если у нас на на патч будет например 100х100 сенселей в ячейке сетки это ж компенсирует любую недодержку в итоге (RD все равно все сведет к одной цифре на сенсель (каждого "цвета") - т.е. это как биннинг огромного числа сенселй в 1... что компенсирует много стопов очень)...

Z / V

Казалось бы, надо взять линейку и померяться? Ну вот из принципа недодержать мишень стопов на пять и прямо в экселе посмотреть, соблюдаются ли соотношения для недодержаной мишени и для нормально экспонированной

может если соотношения нет то у вас там бага в коде :-) !

PS: хватает ли кстати в RD знаков после точки/запятой для точности в тенях ?

PS2: ну вот два raw : ~0.62s vs ~1/40s = 2225.02 vs 87.159 (G avg) -> log2 (25.52828738) = 4.67402485... a это и есть 4 & 2/3 стопа - так же ? ну в красном канале (патч был синий, и красный канал там в 1.5 стопа слабее) = 4.692482365 vs 4.67402485

Z / V

Возьмите dcraw, даже если там баг - сами поправите.

а насчет точности в знаках после запятой в UI (да и при эскпорте) ?

Z / V

Что-то не так c точностью?

> Что-то не так c точностью?

Мало знаков на экране !

Z / V

А можно пример? Скриншот - годится!

ну вот например =

a CSV =
"Filename","Frame","Id","Sample_Name","Ravg","Gavg","Bavg"
"DSC06334.ARW",1,1,"3076:2156-84x92",26.872,87.135,115.81

цифр ес-но на самом деле таки больше и раз rawdigger позиционируется для исследований всяких то наверно надо изображать их больше все же ? особенно если DN будут типа в районе единиц

Z / V

На глаз, вижу полтора лишних знака на экране: показывается с точностью 0.1, а сигма - 3. Точнее - незачем.

В файле, соответственно, 3.5 лишних знака.

> а сигма

слона-то !

PS: а если raw - синтетический и весь из себя идеальный, вы на ходу ж не определяете точность показа

Z / V

Весь из себя идеальный - это какой, все значения на плашке одинаковые? Тогда среднее будет таким же, одинаковым. И целым.

уел... надо значит придумать тест чтобы сигма была спец. маленькая !

Z / V

Можно, конечно, влезть на шкаф (но снимать значения с синтетики - зная из чего она синтезирована - глупое занятие).

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

К тому, что Алексей уже написал: если мишень идеальная, равномерно окрашенная, без пыли и царапин, одно дело. Если реальная - то надежнее экспонировать по максимуму, чтоб и темным патчам досталось экспозиции, фильтрации и усреднения. Вот, скажем, CC24 - почти 6 ступеней ДД. Так ли хочется идти сильно ниже, особенно учитывая паразитные засветки, которые начинают заметно проявляться уже с 7 ступени?

специально ниже идти не хочется, но и напрягаться тоже не надо - т.е. можно таки не писать о том что imaging-resource недосветил например ... то что осветил криво и неизвестно чем остается...

Z / V

Смотрите, какая штука. Даже при экспозиции "вправо" на CC SG самые темные плашки при такой схеме освещения как на IR теряют линейность, причем уже по экспонометру это видно. Мы ж матрицу строим в первую голову, остальное - LUT - коррекции, после матрицы работают. Соответственно, если мы хотим хорошую основу - матрицу - нам чего надо? - линейности.

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

Z / V

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

> Вот, скажем, CC24 - почти 6 ступеней ДД.

это если нам именно для профилирования с CC24 нужен самый темный патч из greyscale набора... а нужен ли он на самом деле - и что он там улучшает (не в смысле проверки потери контраста) ? матрицу же он не улучшит в любом случае.

Z / V

Какие плашки выкидывать профайлер чужой будет - того мы в RawDigger'е знать не могем.

продолжаем давить прЫщи ... вот допустим у нас есть мишенька, а в ней 3 патча - синий, серый ("светлее" синего, "темнее" желтого) и желтый... достанем бытовую лампочку накаливания у которой все со спектром хорошо, кроме того что он в районе "синего" невелик... что опять же совсем не смертельно если синий патч снимать под этой лампочкой отдельно, долго и упорно и вывести синий канал туда где неслучайные шумы и прочие неслучайные факторы нарушающие линейность малы vs фотонный шум... понятно что желтый патч в итоге будет clipped... вопрос - зачем люди страдают пытаясь найти источник освещения более ровный в плане графика его спектра (ну или городят фильтры на свет и/или объектив), вместо того чтобы просто снять мишеНь два раза подряд - один раз максимизируя экспозицию желтого патча, второй раз максимизируя экспозицию серой плашки (желтая понятно будет clipped в 1 или 2 каналах или вот даже в 3) - и использовать таким образом серый патч чтобы поделить цифры для синей плашки из raw с хорошо экспонированным синим патчем используя соотношение цифр в каналах для серого патча из обоих снимков и подсунуть эти цифры к данным из raw где желтый патч не clipped ?

Z / V

ошибка выше у меня конечно элементарная... в синей плашке (если брать синию и желтую плашки похожие на то что есть в мишени типа CC24) будет слабый конечно же "красный" канал при более-менее обычных CFA ... разброс между максимальным насыщением "зеленого" канала в желтой плашке и "красного" канала в синей плашке в данном будет порядка ~ 4 & 1/3 стопа (причем даже самый плохой это на самом деле "синий" канал в красной плашке из CC24) ... стоит ли городить огород из двух снимков и арифметики если допустим у Sony A7R2 это будут DN = ~15000 (почти клиппинг) в "зеленом" канале желтой плашки vs DN = ~750 в самом слабом канале самой проблемной для галогена плашки ?

Z / V