Физику не обманешь (или еще раз про 3 млн. ISO)

Теоретическую часть про 3 миллиона ISO мы уже тут обсуждали. Дошло время до практики.

Достал по случаю серию кадров, снятую на Nikon D5 c ISO от 100 до 3 миллионов. Публиковать сами файлы не могу, а вот вырезку в масштабе 100% мне разрешили.

Вырезка эта хороша тем, что "читаемость букв" - хороший признак, позволяющий легко увидеть падение MTF. Вот вырезка с буквами:

(click to zoom to 100%)

Условия съемки таковы: на ISO 100 было 1/2s f/5.6, дальше с увеличением ISO - укорачивали выдержку, а когда перестало хватать - начали прикрывать диафрагму.  Обычно такие тесты дают лучшие результаты, чем "реальная жизнь", потому что на 1/8000 вклад теплового шума будет мал.

Область на снимке - это примерно на стоп ниже "среднего тона по экспонометру", если я правильно представляю, куда настроен экспонометр у D5.

Обработка - Adobe Camera Raw, "все движки по нулям".

Итак, что мы видим:

  • До ISO6400 (включительно) - шумы растут, но буквы еще читаются.
  • На 12800  мелкую восьмерку уже можно спутать с 3 или 6 (нет, если мы знаем что там восьмерка - нельзя; поэтому по хорошему такие тесты надо делать на случайной последовательности цифр, вроде  середины числа пи, а потом один тестировщик списывает их со снимка, а второй - считает ошибки).
  • На 25600-51200 ухудшение читаемости продолжается и 8:30 я уже довольно уверенно вижу как 3:30.
  • Ну а дальше все комментариев и вовсе не требует.

У меня, понятно, нет парных кадров, но "по памяти", ISO 400k выглядят примерно так же, как на A7S-II, что само по себе - неплохой результат. Но чудес (еще три стопа относительно A7S) - нет, ибо неоткуда им взяться.

RawDigger показывает в гистограмме странную гребенку на всех ISO (чего на Никонах отродясь не было), а начиная с ISO409600 (включительно) и далее - все очень похоже на цифровое усиление (т.е. "последняя честная чувствительность" - 204800), но подробнее я к этому вернусь, когда будут публично доступные RAW.

Comments

От 3200 и выше уже всё линейно растёт, как мне кажется.

Падает же ж.

А мы продаем или покупаем?

Я имел в виду возрастание ISO на стоп и увеличение отклонения в два раза. А так, да, падает.
Но, несмотря на экспоненциальность, первый ряд чувствительностей выглядит по приросту шума как-то более щадящим.
В общем, чего гадать, пока нет самплов.

Ну так из общих соображений, оно "линейно растет" от ISO100.
Плюс-минус read noise, который померять пока не на чем особо померять (что там на рамке у никона - хрен пойми, не хочу разбираться.)

Первая колонка - установка ISO
Вторая колонка - баланс белого, коэффициенты RBGG
50 1.921875 1.965332031 1 1
100 1.926269531 1.964355469 1 1
200 1.926269531 1.967773438 1 1
400 1.92578125 1.96875 1 1
800 1.9296875 1.959472656 1 1
1600 1.944824219 1.928222656 1 1
3200 1.943847656 1.928222656 1 1
6400 1.947753906 1.917480469 1 1
12800 1.941894531 1.932128906 1 1
25600 1.943359375 1.928710938 1 1
51200 1.936035156 1.940429688 1 1
102400 1.928222656 1.942382812 1 1
204800 1.755859375 1.951660156 1 1
409600 1.741210938 1.964355469 1 1
819200 1.579589844 1.728027344 1 1
1638400 1.364257812 1.494628906 1 1
3276800 1.131347656 1.1640625 1 1

S/N падает - баланс стремится к UniWB. Это нормально.

Так происходит, если замер баланса перенесли на основной сенсор.

Почитал тут https://photographylife.com/where-are-my-mid-tones-baseline-exposure-com... — а там бОльшая часть картинок что-то не грузится.

У меня - грузится, даже после сброса кэша.

Хм. Ну, спишем на кривого провайдера не работе.

Вообще, интересно, конечно, посмотреть на картинки после таких манипуляций (благо у меняDNG родной, Baseline Exposure легко посмотреть).

Вообще, как я понимаю, моё BLE в -0.5118103027, согласуется с постоянным ощущением, что недосвечивает камера (ну, я уже жаловался, да).

> благо у меняDNG родной, Baseline Exposure легко посмотреть

это всегда легко смотреть - надо просто сконвертировать не DNG в DNG используя тек. Adobe DNG Converter (или ACR или LR) и Adobe все пропишет там внутри...

Z / V

У Adobe в этом месте бывают ошибки.

т.е. в сконвертированном DNG пропишут одно значение, а в самом коде (ACR/LR) с DNG сделают другое во время конверсии... а пример ?

Z / V

> а в самом коде (ACR/LR) с DNG

следует читать с не DNG (т.е. исходным для конверсии) raw

Z / V

Не. Просто ошибки. На высоких ISO у Fuji, на дробных Lo у Никонов встречал. Лучше проверять.

> Не. Просто ошибки.

казалось бы приличная фирма - в коде для всего что собирается(ACR/LR/DNG converter/whatever) константа один раз написана цифрой и в одном месте вообще - дальше все ссылки по имени... как можно принципиально ошибиться ?

Z / V

А как можно в Бридже меню в адресной с троке не сортировать? Или там же не отрезать пробелы от скопипасченнойго пути? Ну вот так.

> А как можно в Бридже меню в адресной с троке не сортировать? Или там же не отрезать пробелы от скопипасченнойго пути? Ну вот так.

ну UI там хз кто делает, мб свежие выпускники 3-x годичного областного техникума в одной теплой, южной стране - но все что относится к конверсии raw вроде приличные же люди.

Z / V

Не везде и не у всех это константы.

> Не везде и не у всех это константы.

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

Z / V

И для одного ISO могут быть разные величины.

у одной и той же модели камеры ? это в зависимости от чего - версия прошивки (например поменяли что-то) ?!

Z / V

От настроек камеры (или, может быть, от внешней среды?)

Камера ставит теги, адоб их читает. Или не читает, хотя лучше было бы читать.

> Камера ставит теги, адоб их читает. Или не читает, хотя лучше было бы читать.

Минутку ! а причем здесь теги прописанные прошивкой камерой ? речь про то что Adobe сама тайно правит (скрытый push/pull) и про то что это видно когда создается DNG кодом Adobe и Adobe сама это значение (которое код Adobe будет использовать) пишет в DNG тэг соотв-щий.

Z / V

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

Z / V

Adobe для чего правит?

В частности для того, чтобы картинка в ACR была близка по яркости к камерному JPEG.

> В частности для того, чтобы картинка в ACR была близка по яркости к камерному JPEG.

да, но вопрос в соотв. того что у Adobe в коде тому что сама Adobe пишет в тэг в конвертированный DNG... тут утверждалось что бывает разница ! я не про случай когда Fuji пишет в свой raw = конвертер надо поправить на 2EV, а Adobe правит на 2.5 ЕV и в DNG пишет 2.5EV... ибо в этом случае и в коде и в DNG одинаковые значения, даже если они не совпадают с пожеланиями Fuji... пример придуманный для иллюстрации

Z / V

Утверждается следующее. Точка калибровки у Адоб x%. Их знвчение baseline exposure не всюду обеспечивает приведение к этой точке. Второе утверждение - baseline exposure не всегда берется по таблице, оно в ряде случаев вычисляется на основании тэгов, записанных камерой.

> оно в ряде случаев вычисляется на основании тэгов, записанных камерой.

т.е. утверждается что одна и та же модель некоей камеры с одной и той же прошивкой на одном и том же ISO (то что на разных разные понятно - например Fuji) может записать разные тэги на основании которых Adobe может применить разные экспопоправки... т.е. никому верить нельзя

Z / V

Ну да.

Многие камеры пишут нечто в теги, это нечто, в первом приближении, "как мы тут пушили наш JPEG".

И Adobe (и FRV, естественно, мы же матчим Адоб) это используют при расчете "скрытой экспопоправки".

И, да, это нечто может быть разным на одном ISO.

> И, да, это нечто может быть разным на одном ISO.

ну а все-таки где же пример-то ?! модель камеры ...

Z / V

Кодаки, Олимпусы, Фуджи, Панасы.

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

Таки пишут - откройте ACR в каком нибудь дизассемблере (типа HopperApp или IDA если есть) и поищите где распознается модель камеры (текст). Оттуда недалеко для кода который инициализирует для данной модели камеры декодер с параметрами явно и прямо в коде прописыающим экспокоррекцию, контраст (или кривую) и еще пару (со всеми параметрами я не разбирался)- и даже для одной модели там есть вариации. Код страшно тупой и все константы прописаны прямо в гигантской функции раcпознавания.

> Код страшно тупой и все константы прописаны прямо в гигантской функции раcпознавания.

а как вы поняли что это написал программист, а не компилятор ?

Z / V

Компиляторам не свойственно превращать структуры данных в код и наоборот.

т.е. если в исходном коде переменная обьявлена как const и присвоено значение, то где-то дальше ни с какими опциями оптимизации не будет после компиляции в коде для CPU компилятором прямо вписано это значение ?

Z / V

А с чего const, если мы ее инициализируем в результате анализа метаданных камеры?

> А с чего const, если мы ее инициализируем в результате анализа метаданных камеры?

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

Z / V

Вот смотрите о чем я

- вменяемая инициализация данных о камере: нашли make/model/iso, всосали основные данные из таблицы, возможно подправили чуть-чуть, самую малость, какими-то коллбеками.
Собственно ровно вот то, что вы и писали выше "глобальная таблица" или что-то там в этом духе.

- невменяемый ad hoc: читаем dcraw.c, функцию identify(). Где-то по модели разруливаем, где-то по размерам или каким-то еще косвенным признакам. LibRaw в этом месте не сильно лучше, впрочем, стараемся соответствовать лучшим образцам (а FRV, где не довлело, - сильно лучше).

И такой "невменяемый ad hoc"
a) видно в ассемблере тоже, особенно если понимать (ну или там IDA подскажет), что вот этот вот инлайн - это на самом деле strcmp
б) никакой оптимизирующий компилятор такого говна не наоптимизирует.

И вот примерно это вам и пытается рассказать Алексей.

> невменяемый ad hoc: читаем dcraw.c, функцию identify().

это тем не менее квалифицируется как одно место в исходном коде, нет ?

Z / V

Я не знаю что означает "квалифицируется как одно место" в вашем понимании.

В моем понимании, identify() сделан вот именно что через одно место, рукожопно. А нам тут рассказывают, что у Adobe - аналогично.

и вообще все началось с утверждения что увидеть скрытую (от пользователя) экспопоправку применяемую ACR/LR можно сконвертировав raw в DNG использую ACR/LR/DNG converter (одного поколения/релиза) и засмотрев потом соотв. тэг в этом свежесконвертированном DNG... тема плавно утекла в сторону... в сухом остатке - то что для одной модели камеры (конкретные модели так и не назвали - только brand'ы) на одном и том же ISO в зависимости от чего-то другого firmware может писать данные в исходный raw на основании которых для одного raw ACR/LR рассчитает одну скрытую экспопоправку, а для другого raw - другую (опять же модель камеры одна и таже, ISO одно и то же)... и побочный спор что Adobe вот __ИЛИ__ пишут эти экспопоправки как числа цифрами в коде повторя числа в > 1 месте кода (вместо даже #define/#include) __ИЛИ__ рассчитывают опять же не в одном месте, а вот повторяют код расчета в > 1 месте кода (вместо даже #define/#include)

Z / V

>а как вы поняли что это написал программист, а не компилятор ?
Ну вот объясните мне как компилятор может сам вызывать одну и ту же функцию раз 150 при этом умно расставляя вызовы для каждой распознанной модели камеры и более того сам добавляя туда зависящие от модели камеры константы. Я как бы уже 20 лет этим занимаюсь но такого в компиляторах пока не видел

вызов функции я могу 150 раз написать да, а про константы - чем же случай когда const делается компилятором inline при оптимизации вместо программистя явно пишушего число цифрами...

Z / V

Еще раз если непонятно - цифры все сильно разные, при чем тут константы?

> Еще раз если непонятно - цифры все сильно разные, при чем тут константы?

уже сильный офтопик с нашей стороны... я (если что то я последний раз глядел на листинг дизассемблера /"sourcer"/ > 20 лет назад) если числа цифрами все разные то на мой взляд это компилятор мог кучу const вставить прямо в генерируемый код или макросы для этих всех разных чисел, а вовсе не значит что вот прямо в исходном коде (C/C++) было написано присваивание этих чисел написанных цифрами... я несомненно могу быть не прав на 1000%...

Z / V

Какой смысл программеру задавать 150 констант типа 1.1, 1.5, 1.25 итп. Я бы понимал если бы была таблица с моделью камеры и там прописанными константами и код который оттуда вытягивает - но этого нет в упор, а таблицы компилятор таким образом не оптимизирует.

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

Нынешние компиляторы умнее программеров. :-)
Если написанный программером цикл в данной версии программы пока/уже не используется, компилятор его просто игнорирует.
Если константы для человека неочевидны и заданы, например, функциями, являясь по сути константами - компилятор наверняка пересчитает их в массив констант...
И т.д.
Компиляторы давно уже живут своей жизнью...

>> компилятор наверняка пересчитает их в массив констант.

Но никогда не сделает наоборот

... посмотрите полный exif камер Panasoniс, там столько чудес, - я был в шоке!

Когда это Adobe считалась приличной фирмой?

Сколько помню, к ней претензии - сплошным потоком.

> казалось бы приличная фирма - в коде для всего что собирается(ACR/LR/DNG converter/whatever) константа один раз написана цифрой и в одном месте вообще - дальше все ссылки по имени... как можно принципиально ошибиться ?

Вы бы видели что этот код (хотя бы DNGConvertor не говоря уж об ACR) творит внутри...

> Вы бы видели что этот код

только DNG SDK доступен...

Z / V

Все проще - берете выполняемый файл и дизассемблируете. Потом изучаете с отладчиком, просматривая символы итд итп. От С++ много мусора остается в коде - некоторые вещи вполне себе восстановимы.

IDA???

Если есть IDA то можно и ей, ну а так и Hopper подходит.

Мне после олимпуса дико непривычно, что 0 EV по экспонометру на K-5 транслируются на стык IV и V зон. То есть вот у меня сейчас стабильно живёт экспокоррекция в +1.7 EV (точечный замер, естественно). И то, бывает мало. Благо, он не шумит на разумных ISO, тени стерильные.

Вот та же фигня. +1 всегда, +1.7 часто. И редко-редко я об этом жалею.

У меня есть ощущение, что прошивка АДСКИ боится бликов. Если ни одного блика, всё серое -- то как раз поправка не нужна. Любой блик в кадре -- вкручивая полторы ступени вверх.

Хотя при точечном замере это как раз влиять не должно.

А, ну я именно про точечный, взвешенный и матричный даже не включал, и, боюсь, рычажок там и заржавеет :)
Но тенденция недодерживать в целом видна даже невооружённым взглядом. Меня это не смущает, но очень непривычно. Приходится привыкать замерять по более тёмным объектам, когда влом считать.
А так я дико камерой доволен. Сейчас ещё адаптер приедет на М42, а 55/1.8 пентаксовским я сразу обзавёлся.

Опечатался: на стык III и IV вообще. То есть вот точечный замер при 0 EV после конвертации «по умолчанию» даёт в среднем L*=30 единиц (плюс-минус 3, в зависимости от конвертера и его кривой). А прожечь область замера не всегда получается даже при +4 EV коррекции.
Поэтому и ставлю пока +1.7, чтобы попадать ориетировочно в середину пятой зоны. Возможно, даже выкручу больше со временем, т.к. привык целиться ещё выше.

Bill Claff намерял типа = photonstophotos TOЧКА net/Charts/PDR.htm#Nikon%20D5,Sony%20ILCE-7RII,Sony%20ILCE-7S

Z / V

А вот "цифровое усиление" - дает в PDR полку, по идее?

> А вот "цифровое усиление" - дает в PDR полку, по идее?

у Claff если я помню то полка когда ISO by tag - например график PDF у Fuji XT-1... а если "честное" умножение DN при записи данных в raw то полки нет на этом графике

Z / V

> график PDF

график PDR

Z / V

А почему нет полки?

> А почему нет полки?

ну так если умножаем данные при записи в RAW то к clipping (ограничению сверху) же приближаемся (в отличии от ISO by TAG где ничего не трогаем, только в тэг пишем что конвертер должен сам умножать, если захочет)...

Z / V

т.е. D5 неосилил, последняя надежда что Canon 1Dx Mk II преодолеет теорию :-)

Z / V

Надо бы сравнить D5 с A7S пушенным до 3.2M
Кстати, по ДХО A7SII получается хуже первой версии, с чего бы это?

> Кстати, по ДХО A7SII получается хуже первой версии, с чего бы это?

если не сильно меньше можно списать на ошибки эксперимента, если сильно меньше на "никон/кэнон" проплатили Ё-)!!!

Z / V

я даже не знаю, что думать, смотрите сами: http://www.dxomark.com/Cameras/Compare/Side-by-side/Sony-A7S-II-versus-S...

Ну, к примеру, включили электронный затвор и пару бит потеряли.

Или просто попугаи маленько подросли.

там вроде бы и цветовые фильтры другие....

Адоб считает, что одинаковые. Мы, впрочем, тоже.

Ну непонятно, почему адобу доверия должно быть больше, чем дхо.
А почему вы не прокомментировали мою симуляцию фотонного шума 0.3 электрона на пиксель?

>> А почему вы не прокомментировали мою симуляцию

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

А сил и желания не было.

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

... но обе гонят лажу.
Но по разному, да.

Моё доверие к ДхО растаяло после прочтения их сказок про ИХ камеру "DxO ONE".

DxO не учитывает как минимум один фактор (не спрашивайте, какой, он достаточно очевиден). Мы рассчитывали преобразование сами, и разница между A7S и A7SM2 - в пределах погрешности.

А вот до какого ISO картинка у D5 еще имеет хоть какую-то информационную ценность при приведении к условному FullHD? С точки зрения подачи этой картинки в новость о прилете инопланетян на Землю.

FullHD можно заменить условно на картинку в 2Мп по площади.

Z / V

У таких картинок проблема не в количестве света (в общепринятом смысле)

Ну если там (как мне кажется) выше 200k - цифровое усиление, то выше 200k и нет смысла ходить?

Репортеры массово в RAW не снимают :)

Вот беру мы А7, накручиваю iso до максимума (26к) и снимаю в темной комнате с приемлемой выдержкой. В жпег наименьшего размера. Потом простейшей програмой уменьшаю до ~2Мп по площади и получаю картинку, которой более чем достаточно для иллюстрации новости о пришельцах: https://cloud.mail.ru/public/MRT9/c5xaaZujH

Похожая операция с D800 дает практически аналогичный результат: https://cloud.mail.ru/public/7sPu/ZbuKFHpcL

Вот где у D5 находится "предел", за который заходить не имеет практического смысла? Никто ведь в здравом уме не будет снимать на iso 500к с выдержкой 30с :) В том же спорте вполне реально задирать чувствительность ради коротких или очень коротких выдержек.

С практически-репортерской точки зрения этот предел будет определяться типичным шаблоном: "быстро сняли в жпег, потом (редактор) что-нибудь выберет"

Между 26k и 3mln - разница в 7 стопов.

У Д800 на 26к при недодержке в 2 с лишним ступени, картинка после обработки и масштабирования до 2Мп не сказать что приличная, но еще информационно-значимая. Т.е. 100к использовать можно, если припрет.

https://cloud.mail.ru/public/L8eB/yfbhviKsD

У меня вот мысль мелькнула, что эти вот 100..400к можно использовать для получения превью перед тем, как поставить исо 100 и накапливать свет на штативе

Высокие ISO для кадрирования/выставления горизонта на место - вопросов нет

И высокие ставятся ради того, чтобы камера JPEG запушила на правильное количество стопов.

Вообще, вопрос про "информационную ценность" мне непонятен. Поэтому давай рассуждать из физики и математики:

  • В "насыщении" у нас 3 электрона на пиксель.
  • В среднем тоне - 0.3
  • Говорить надо именно о среднем тоне, потому что если вдруг мы на 3mln ISO попали близко к насыщению, то надо скрутить три стопа с чувствительности.
  • Значит усредняя 10 пикселей (т.е. переходя от 20Mpix к двум) мы получим сигнал ~3e.
  • Сигнал-шум там будет, только за счет фотонного шума, sqrt(3)
  • Приемлем ли такой сигнал шум для "новости об инопланетянах"? Я не знаю.

Посмотрел на все еще раз. В общем, скорее всего iso 200к будет еще рабочим для новостной съемки. А в нормальной жизни лучше сидеть, охлаждать сенсор и накапливать фотоны по пол-часа :)

Ну типа да. Как и у A7S - ейные 200-400k не полностью бесполезные. Но не в 10 же раз больше!

написал скриптик на питоне
# photon noise simulation, produces KOEFF1 random poisson events at each pixel
# the picture is converted to greyscale before

from PIL import Image
import numpy as np

KOEFF1 = 0.3

imfile = Image.open("imsa2.jpg")
pix = imfile.load()
(sx,sy) = imfile.size
avg=0
for yy in xrange(sy):
        for xx in xrange(sx):
                (r,g,b) = pix[xx,yy]
                avg+=((r**2.2)*3+(g**2.2)*5+(b**2.2))

avg/=sx*sy

for yy in xrange(sy):
        for xx in xrange(sx):
                        (r,g,b) = pix[xx,yy]
                        cur=((r**2.2)*3+(g**2.2)*5+(b**2.2))/avg

                        s = int(64*(np.random.poisson(cur*KOEFF1)/KOEFF1)**0.4545)
                        s = min(s,255)
                        pix[xx,yy]=(s,s,s)

imfile.save("outmin.jpg")

кстати Гугол поиск нашел оригинал картинки с девушкой сразу ))))) а говорите бесполезное )))

С учётом того, что "имеем только то, что имеем", тестировщику лучше предъявлять сэмплы по одному и начиная с наивысшего ИСО.