RawDigger 1.0.5: обнаружение (возможной) постеризации в файлах Sony cRAW

Тема потерь при сжатии в файлах Sony cRAW (а этот формат используют все современные камеры Sony) поднималась у меня многократно. Вот только за последнее время:
  1. RawDigger 1.0.3: раскапывая Sony описание (в очередной раз) формата данных и новых фишек RawDigger для его анализа.
  2. Sony cRAW ETTR: сжатие с потерями, теория и практика практический пример поиска проблемных областей
  3. Sony A7: околозвездная постеризация (ссылка на diglloyd.com) еще один пример, который был в точности предсказан.
Но для быстрой практической оценки изображения имеющегося в RawDigger режима показа только дельт (относительно нуля) оказалось недостаточно. Пришлось добавить еще один режим, о котором, собственно, эта заметка. Блок в настройках 'Sony ARW2 processing options' переупорядочился, добавился один режим показа

Data Processing Sony ARW2 options Processing mode Delta step relative to value

(и еще одна дополнительная настройка о которой ниже):

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

Давайте посмотрим на практику. Вот кадр с звездными треками, который уже поминался (ссылкой на diglloyd).

Вот как выглядит кусочек этого кадра в RawDigger в обычном RGB-режиме:

Аналогичная "борода" вокруг трека видна и в Adobe Camera Raw даже без увеличения контраста (только сдвиг экспозиции):
Теперь, собственно, новый режим, который такие бороды должен ловить. Ставим ARW2 Processing Options: Delta step relative to value и видим:
Среднее значение 'delta step to value' - 10 (т.е. 1%, на грани потенциально видимой постеризации), а максимум - 47% (470 промилле).

Можно сделать еще нагляднее. Допустим, нам интересны области, где шаг дельты не меньше 10% от фона (т.е. 100 промилле). Берем и ставим OE Level в 100:

Включаем OE warning, постеризация больше 10% будет подсвечена красным:
Увы, но нужно вручную сопоставлять выловленное с ровностью фона (были всякие идеи, что нужно убирать edges, что можно как-то взвешивать на дисперсию - но пока успеха нет). На уже использовавшемся снимке с башней (на котором ловили тоже всякую ерунду, но видимую только после увеличения контраста), данный режим, естественно, подсветит все блоки, где есть контрастные границы:
Что неудивительно любая контрастная граница приведет к постеризации, причем в темной части блока к большой. Вопрос же в том, будет ли это видимо глазом на отпечатке.

Смотрим на сам кадр:

Нет, конечно, по большей части нет никакой задачи в точной передаче тонов на черепичных крышах, ошибку никто не увидит.

И, как обещал выше, о второй настройке.

Понятно, что в тени всегда большая возможная постеризация: скажем при минимальном шаге в 2 единицы, на уровне 64 возможная постеризация уже не менее 3% даже без дельта-кодирования. Для того, чтобы ее подавить при показе и добавлена еще одна регулировка:

Ignore shadows below level NN

Если ее выключить (поставить в 0), то на снимке с башней проявятся (как потенциальные места с постеризацией) тени на переднем плане:

Как правило, тени нас волнуют мало и стандартное значение ignore below 64 прекрасно работает.

Для тех, кто дочитал до этого места бета-версии RawDigger 1.0.5 RawDigger 1.0.5 вышел, берите с официального сайта.

Comments

Кстати, если в маленьком "RAW" будет документированный способ уменьшения - это будет просто другой извращённый CFA, и для него в принципе можно придумать демозаик.
(стоит ли заморачиваться - это другой вопрос)

Комментарий кажется убежал отсюда: http://blog.lexa.ru/2014/02/06/otkrytii_chudnykh.html#comment-39874

Но отвечу тут: никто пока этих файлов не видел. Одно дело, там будет half или какой-то аналог (вроде sRAW кэноновского), т.е. 3-4 компонента на пиксел. Тогда интерполяция уже сделана.
Другое дело - если это будет уменьшенный байер. Тогда да, можно пытаться восстановить тот способ, которым уменьшали и что-то делать.

Браво. Крайне удобно, гипернаглядно.

А overexposure для сонек (А7) у тебя сейчас как считается на автомате? Sens. 1% выдает, похоже, фигню :)
На фото в G вижу большие плоские заливки с 15860, но они не выделяются. Выделены только "фальшивые" пики в 15924 на контрастных границах

Там за счет того, что базовые пикселы - ~15800, а дельта - до 16100 (это после вычитания черного) - стандартные детекторы работают плохо (1% - это 161, соответственно).

Full Well limited - работает нормально, насколько я вижу (делалось для панаса@125ISO, но работает и тут). А можно просто руками поставить в 15500.

> А можно просто руками поставить в 15500.

a почему __15500__ ? я наверно что-то упустил... или это 15800 +/- 300 = 15500...16100 ?

Z / V

А потому что нет разницы, 15000, 16000 - это все такие доли стопа что было бы о чем говорить (1/16-я это ~0.1EV, т.е. в пределах точности затвора, замера и всего подобного)

Рекомендованное Sony значение вовсе 15360 (и никто не знает, не до вычитания ли черного эта цифра, предположительно - до)

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

Ну это надо спрашивать у авторов конверторов.
В LibRaw - поддержим. Соответственно, libraw-based конверторы - будут работать, но толку то от них.

Если такой хак будет - скорее всего сделают, как у ML, raw2dng - и все будут счастливы.

Слушай, я может чего-то не понимаю. Скачал 1.0.5, открыл DNG от Pentax K-5 и вижу гистограмму типа hit the wall на значениях порядка 65020. Но это не 16-ти битная камера! И пересветов (при точности в 1%) при этом поазывают мне 1.2% по зелёному и 0 по остальному.
При этом в любом Selection'е без рамки (ну, отступив пикселей по 20-30 со всех сторон) максимумы уже адекватные -- 15867-15869. Таким образом полная чтатистика просто в мусорную корзину, увы.

Ах, да, картинка не скроллится в режиме выделения, неудобно.

Файл в дропбокс (али еще куда) - посмотрю.
Без файла нет предмета для обсуждения.

Че-то оно дохнет где-то внутри Хетцнера, таймаут, файл не скачивается.

Чорт. По всем признакам сдох сервер. Вовремя, ничего не скажешь.

Я плохо понимаю дропбокс -- вот такое видно?
https://www.dropbox.com/s/x34y567ndysk710/_IGP0841.DNG

Да, все правильно, скачал

Вот беру файл
- со снятой галкой Masked Pixels - максимум 16382 до вычитания черного, около 15867 (чуть разное по каналам т.к. уровень черного 513-516) после вычитания.

И, да, если поставить галку Masked Pixels - тогда вылезают данные over 16k (ну так они там наверное и есть, насколько я вижу?)

То есть, "все правильно" ж

Хмм... Осталось понять, почему у меня эта галка стоит. Мне казалось, что на эту машину я не ставил раньше RD. Ну, значит, казалось.
Прошу прощения за беспокойство.

Может добавлять какой-нибудь значок типа /_!_\ в табличку с общей статистикой и тултипом у неё "У вас включены show masked pixels"? Маленький, в уголок блока? Иконкой, как фотошоп на гистограмме по устаревшим данным показывает.

Их же видно. Чорные полосы по краям.

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

Кстати, а зум на гистограмме (по оси X) мышкой? Есть такой фичреквест?

Вот стоит "Auto" -- а начал выделать на гистограмме, в любом канале, и оно снялось с Auto и заполнило поля Range?

Да, клики по меткам (типа Auto, Log scale, Grid и Update linear scale) не работают -- по всем гайдлайнам должны. И Update linear scale очень оторвано от своего чекбокса.

Записал пожелания.

Гистограмма - реально сложное очень место, страшно что-то трогать!

При этом клики по мтекам в основном окне (OvExp/UndExp) работают как надо.

Да-да, потому что Qt. Можно сделать чекбокс и надпись одним элементом и тогда кликается. Иногда приходится разными (например, чтобы надпись слева) - тогда нет.

У них нет отдельного контрола типа Label (а не Static text) с полем "Labeled control" (ну, по смыслу)!? В 2014 году!? Этому сто лет как даже HTML научили!

Ну может я не умею. Поизучаю.

Не, стандартно у QLabel нету.

Можно легко (в пару строк) имплементировать.

Ну да, там же слоты, сигналы... По идее, любые события с мышиными кнопками надо просто форвардить в другой контрол, это не должно быть сложно.

Впрочем, и мой сервер ожил.