О битности у камер Sony

После рассказа о битности A900 в режиме cRAW стали задавать вопросы про другие камеры.

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

  • у обычных камер половина всех уровней это самый верхний стоп (где столько не нужно), четверть второй сверху стоп (тоже не нужно)
  • в случае с cRAW, уровни распределены по всему диапазону значений гораздо более правильно (с фотографической точки зрения), на самые света выдают поменьше (чем в обычном линейном случае), на полутона и тени побольше.
Поскольку мне нужно было проверить правильность установки уровня черного для всех камер Sony, поддерживающих RAW, я заодно изучил битность в тенях практически для всех камер этой компании (за исключением трех мыльниц и A5000, примеров с которой пока нет).

Введение в проблему и методика

Как мы помним, у камер Sony есть 4 формата данных:
  • "Старый ARW" (камеры вроде A100)
  • Нежатый новый ARW (A700/850/900 в 12-битном режиме)
  • cRAW: сжатый новый 11/7-битный ARW, про который я неоднократно писал
  • SRF (который был у F828), по причине древности уже неинтересен.
Первые два формата обычные 12-битные и линейные , с ними все просто (тем не менее, см. ниже).

У cRAW имеется тоновая кривая (насколько я видел, одинаковая для всех камер), которая линейна на участке 0 2000 (после вычитания черного на участке 0..1488) а дальше загибается (вверх при распаковке, вниз при паковке в камере).

Во всех трех случаях, количество уровней в светах достаточное. Их, как минимум, несколько сотен на 1EV (в случае 12-битного линейного формата - 2048 уровней на самый верхний стоп). С точки зрения фотографа, интерес представляет количество уровней в полутонах и тени , например, от уровня ~3EV ниже насыщения и до абсолютно черного.

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

Случай с cRAW требует более подробного пояснения.

  1. После наложения тоновой кривой в процессе распаковки RAW, мы получаем линейный сигнал, размах которого соответствует 14-битной камере.
  2. В этом сигнале есть дырки - значения, которые никогда не наблюдаются.
  3. Дырки в светах нас не интересуют количество уровней там достаточное.
  4. В области от полутонов (~3.3 стопа ниже насыщения) и ниже в сторону черного, в силу особенностей формата данных, мы в лучшем случае видим каждое четное значение.
  5. Дальше мы считаем дырки в гистограмме и битность (т.е. сколько бит АЦП нужно обычной камере с линейным АЦП, чтобы получить такую же детальность уровней в тенях, точная формула приведена ниже)

Использованные данные

При подсчетах использовались снимки, снятые на ISO100 (или ближайшем более высоком, если у камеры нет ISO100), ISO400 и ISO3200. Этот набор чувствительностей выбран из следующих соображений:
  • На ISO100 мы, скорее всего, будем иметь наибольшее количество уровней.
  • Однако если ISO100 самое нижнее в линейке чувствительностей, то там возможны всякие чудеса (оно может быть вообще фейковым, как ISO50 у Canon), поэтому возьмем еще ISO400, где чудес обычно меньше.
  • А на ISO3200 уже могут быть другие чудеса, например цифровое повышение ISO .
Таким образом, процедура исследования заключалась в выборе небольшого кусочка изображения (небольшого чтобы не нарваться на выравнивание двух половинок сенсора, как на Sony A900), так чтобы значения там были ниже ~1500, рассматривания гистограммы этого кусочка в RawDigger и подсчете числа уровней.

Основной массив данных скачан с сайта Imaging-Resource.com. Для тех камер, которые там не представлены данные взяты из других (достаточно разнообразных) источников, но таких камер немного: A300, A450, A900 (нежатые RAW), NEX-5R.

Шумопонижение

Во многих камерах Sony есть шумопонижение которое влияет на RAW-данные (как минимум, в некоторых камерах; целенаправленно это не исследовалось)

При подборе примеров выбирались варианты с отключенным шумопонижением, а при их отсутствии с минимальным шумопонижением из доступных вариантов.

Странные гистограммы

Среди камер Sony встречаются такие, где гистограмма ровного поля выглядит как-то так:
Здесь между, к примеру, 650 и 700 мы видим 4 высоких палочки, причем гистограмма по высоким палочкам выглядит ожидаемым колоколом.

Но к каждой высокой палочке в комплект входит одна низкая.

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

Палочки гистограммы, которые систематически (т.е. повторяющимся паттерном) ниже соседей в подсчете уровней не участвовали.

Дробные значения

Подсчет количества уровней производился в окне шириной 32 уровня. Уменьшение битности относительно максимального значения (12 бит для 12-бит линейных файлов, 14 бит для cRAW) считалось по формуле 5-log2(число уровней в окне шириной 32), результат которой округлялся до одной десятой.

Режим съемки

Как минимум, у SLT-A99 разрядность зависит от режима съемки (у A99, согласно руководству, 12 бит при включении одной из опций: Long Exposure NR, BULB-выдержка, Continuous Shooting /включая режимы со склейкой кадров/, 14-бит в остальных случаях).

Возможно, аналогичное изменение битности есть у других камер Sony.

Данный эффект никак не изучался ввиду невозможности получить достаточное количество примеров. В частности, для SLT-A99 все найденные в интернете примеры сняты в режиме покадровой съемки и 14-битные (согласно EXIF-тегу).

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

Результаты

Прочерки в таблице - у меня нет примеров RAW.
ModelISO
 1004003200
A3000121211
A712.912.912.7
A7R131312.9
DSC-RX112.912.912.9
DSC-RX1R12.912.912.9
DSC-RX10121211.6
DSC-RX100121211.6
DSC-RX100II121212
DSLR-A10012----
DSLR-A20011.511.412
DSLR-A23011.511.59
DSLR-A29011.611.69
DSLR-A3001211 (ISO 800)10 (ISO1600)
DSLR-A33011.511.59
DSLR-A35011.911.912
DSLR-A38011.711.712
DSLR-A39011.611.612
DSLR-A45011.611.611.3
DSLR-A50011.811.811.3
DSLR-A55011.811.811.3
DSLR-A58011.811.811
DSLR-A700 cRAW11.8----
DSLR-A700 uncompressed11.611.611.2
DSLR-A850 cRAW------
DSLR-A850 uncompressed11.511.511.2
DSLR-A900 cRAW11.611.611.3
DSLR-A900 uncompressed11.611.611.2
NEX-311.811.811.6
NEX-3N121211.3
NEX-511.811.811.6
NEX-5N11.811.811
NEX-5R121210.6
NEX-5T121210.6
NEX-6121210.6
NEX-711.811.811
NEX-C311.311.311
NEX-F3121211.3
SLT-A33121211
SLT-A3511.811.811
SLT-A37121210.6
SLT-A55V11.311.310.6
SLT-A57121210.6
SLT-A58121210.6
SLT-A65V11.811.810.6
SLT-A77V11.811.810.6
SLT-A99V131312.9

Выводы

  1. Использование тоновой кривой сильно улучшает жизнь. Скажем, у A900, несмотря на то, что всего уровней в файле в режиме cRAW становится немного, тени от сжатия вовсе не ухудшаются (другой вопрос, что в ETTR в этом режиме снимать не надо, но это мы отдельно разберем при случае).
  2. Нет ни одной "14-битной" (в тенях-полутонах) камеры. Есть "13-битные", но и их немного: A7(R), RX1(R), A99. Все остальные - в лучшем случае 12-битные.
  3. Цифровое ISO (т.е. сильное уменьшение реальной разрядности при увеличении чувствительности) - Sony очень любит. Если вы снимаете на высокие ISO, сверяйтесь с табличкой при выборе камеры.
  4. Кроме этого, Sony любит цифровые манипуляции с RAW. Так как они делаются в целых числах после АЦП, это приводит к потере уровней. В частности по этой причине, у A7 битность капельку меньше, чем у A7R: дырок в гистограмме чуть больше.

Comments

Массивно. Исчерпывающе.
Жаль, что троллить соневодов теперь можно только на основании 13-битности верхних камер.

Ну я видел уже больше одного примера, где "локальная 7-битность" заметна.

Их, вероятно, больше, надо просто иметь тул для поиска (и он будет!)

Тул - это хорошо.
А среди новых сонек какое самое меньшее разрешение? 14?

Там было очень много новых NEX-ов, я в них путаюсь, проще даты выхода в википедии посмотреть.

Вот еще примеры со странностями нашлись: http://www.fredmiranda.com/A7R-review/

При вытаскивании теней на границе со светлым, в середине статьи.

А вот мне другое интересно.
Аффтор пишет там:
"Sometimes, I fantasize about a firmware update that could delay the time between the closing of the shutter and the reopening of the shutter to start exposure."

У меня такая фича на Олике есть. А на каких ещё камерах присутствует такая задержка?

На кэнонах, если снимать с таймером и предподъемом зеркала, зеркало поднимается сразу, потом отрабатывает таймер, потом съемка кадра.

Это по смыслу - ровно оно же, уменьшение тряски.

Ну вот я про "предподъём" и говорю. В соньке же поднимать нечего, там просто пауза нужна. А на сапопах какого уровня она есть?

В 5/6 - точно так. В более младших - давно не пользовался предподьемом, не помню.

Если кому интересно то вот я недавно раскопал что Сони оказывается не первая кто применил нелинейную тоновую кривую. В Кодаках 14n/SLR/n/c очень похожая кривая используется для компрессии 12 битных данных (не совсем raw) в 10 битный .DCR файл. Сами кривые выглядят вот так
http://wowcamera.info/viewtopic.php?p=43893#p43893

Sony точно не первая.
Первым был, вероятно, Canon D2000C (он же Kodak DCS520), либо какая-то из 8-битных камер.

А сама по себе возможность иметь кривую - есть у многих современных форматов (CR2 /никогда не видел вживую с кривой/, NEF, естественно DNG).

Интересно. Я на Кодак этот уже 2 года снимаю и пока не видел никаких внешних признаков применения этой кривой. Правда я не ETTRю. Наткнулся на нее тоже случайно ковыряясь во внутренностях Libraw (использую ее в своем софте) и смотря на файлы экспонированные на грани насыщения.

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

Беда у сони (иногда, довольно редко, но наблюдаемая глазом) от дельта-кодирования с огрублением.

Ну да - посты про Сони я читаю с интересом...

Ну и вот как это понимать ? Что и y Sony, и y Canon? и прочих Nicon цвета в cырых RAW могут сохраняться не в линейной, а в ;-) логарифмической шкале ? Ну, диапазон сенсоров конечен. А шкала какая ?

Сначала надо договориться о терминах.

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

Аналогично у Nikon - lossy/lossless форматы у одной камеры.

И?

Похоже что в этой гисторамме смешаны RGGB каналы. Тогда в одном из них может быть другой коэффициент усиления.

В камерах с параллаксной фокусировкой ещё есть дефектные пиксели (используемые для фокусировки). В них может быть тоже другой коэффициент усиления (или они могут интерполироваться).

Ilya Zakharevich

Конкретная гистограмма - красная, то есть и канал - красный. Смешивать нечего.

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

Вообще же, в dcraw-LibRaw-RawDigger два зеленых канала в классическом байере - не смешиваются.

Что наблюдается: в редкой ситуации, raw converter выдаёт значения которые слегка выше ожидаемых Очень похоже на ту блоху в конвертерах которая видна около следов звёзд; очень интересно

(Я обсуждал эту блоху с Джимом в комментариях к http://blog.kasson.com/?p=4838.)

Ilya

"Блоха" (с бородой вокруг star trails) же не в конвертерах, а в самом формате хранения данных, ее ж видно в непроцессированных RAW-данных вполне прилично.

А в случае процессированных данных - "борода" вокруг star trails прекрасно видна и в соневском конверторе, то есть он делает так же "неправильно", как и все прочие.

Что касается "dequantization error", то там ошибка должна быть порядка единички ADC т.е. единичка или двоечка (если считать A7R - 13битной) в выходных данных, по меньшей мере в теневых участках (ниже 1400 после применения кривой). Но реальная то "ошибка" (отклонение) - сильно больше, она может быть до 32 в том же линейном участке. Эффект этого мы видим на снимке со star trails: http://blog.lexa.ru/2014/02/28/rawdigger_105_obnaruzhenie_vozmozhnoi_pos...

"Блоха" (с бородой вокруг star trails) же не в конвертерах, а в самом формате хранения данных, ее ж видно в непроцессированных RAW-данных вполне прилично.

Непроцессированные RAW-данные это последовательность битов. В них ничего не может быть видно . Видно может стать только после того как данные разжаты в последовательность целых чисел. Блоха в декомпрессоре.

соневский конвертор, делает так же "неправильно", как и все прочие.

Не аргумент.

Что касается "dequantization error", то там ошибка должна быть порядка единички ADC

Неверно. Декомпрессор должен знать каким образом происходит округление в компрессоре. Если ошибка в этом знании, возникает bias, типично порядка 0.5*quantization_step что и наблюдается.
(Как я писал, этот bias неважен если он постояннен, или зависит только от яркости. Однако здесь он зависит от локального контраста, поэтому виден.)

Ilya

Проблема в том, что сам по себе шаг в этих 7-битных данных (дельтах) - слишком велик (в пределе, если очень сильно не повезло - до 512 единиц в линейной шкале 0-16к).

Отсюда и большая ошибка.

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

Да, я не согласен с тем, что знание "как происходит округление" - сильно поможет.

Вот у вас на выходе компрессора, скажем, возможные значения - с шагом 256. 256, 512, 768...
На вход пришло значение 384. Даже если мы знаем, к примеру, что округление всегда вниз (или всегда к ближайшему) - мы не отличим на выходе 385 от 639 (для "ближайшего") или 256 от 511 (для "вниз").

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

Высокий шаг квантизации (по сравнению с шумом сигнала) имеет следующие негативные последстия:

Блохи (bias) в деквантизаторе видны сильнее;
Шум исходного сигнала может быть заметно понижен на выходе;
Ожидаемое значение выхода Е(I) (с учётом dithering на входе) может
заметно отличаться от среднего входного значения I (постеризация).

(Дальнейшее триггерит spam filter; увы!)

Илья

Первые две проблемы наиболее заметны и тривиально устранимы (вторая если известны шумовые характеристики входа; просто добавляем шум на выходе [output dithering]). Третья проблема немного сложнее, и ответ сильно зависит от S=step/ . В определенном интервале S она несушественна. Кроме того, вблизи границы этого интервала проблема сушестенна, но всё ещё легко устранима адаптивным деквантизатором.

Например, проанализируем Ваши данные на D800: http://blog.lexa.ru/2012/05/12/o_strannostyakh_nikon_d800.html

Я предполагаю, что насыщение происходит при 8191, так что 204 это насыщение/40 (конечно, если я ошибаюсь здесь, всё нуждается в поправке). Используя кривую с рис. 10 на http://www.rawdigger.com/howtouse/sony-craw-arw2-posterization-detection, поправленное значение это 50, соответсвенно шум 17/4. При 7-битной квантизации, шаг=16.

(Дальнейшее триггерит spam filter; увы!)

Результат? Максимальная постеризация достигается (в предположении нормально распределённого шума) при Е(0.25)=0.17 (ошибка 0.08 всё в единицах шага квантизации). Если бы шум был 28, а не 17, ошибка бы уменьшилась в 10 раз! (Это значит, что адаптивный деквантизатор не будет иметь ни малейшей проблемы.) Так что даже наивный деквантизатор (который не смотрит на другие ближайшие пиксели) вносит ошибку не больше 1.28 шага 11-битного компрессированного сигнала.

(Дальнейшее триггерит spam filter; увы!)

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

Илья

Очень трудно отвечать на разрезанную реплику. Зарегистрируйтесь - и будет мимо спам-фильтра будете работать.

Так вот, насыщение у Nikon D800 - на 16к.

Но я не понял, какое отношение D800 имеет к Sony A7

Извиняюсь: уехал, и не мог отвечать раньше

Очень трудно отвечать на разрезанную реплику

Так отвечайте на эту. ;-)

Но я не понял, какое отношение D800 имеет к Sony A7

Я использовал те данные которые мог найти, и наиболее близкие к A7. Вы знаете экспериментально подтверждённые данные о шумах A7 на разных уровнях серого? Посколько эти сенсоры не следуют закону √(readNoise² + dropNoise²), применять что-нибудь менее непосредственное чем напрямую измеренный шум неправомерно.

Илья

Да, я не согласен с тем, что знание "как происходит округление" - сильно поможет.

Могу ли я спросить: ПОЧЕМУ? В тех местах где борода видна, наиболее различимая (для меня) черта это что она слегка ярче окружения. Будут ли другие черты различимы если эти блоху убрать может да, может нет, но стобы ЗНАТЬ, надо сначала убрать эту блоху.

мы не отличим на выходе 385 от 639

Извиняюсь, но этот Ваш аргумент показывает что любое квантование неправомерно. Без анализа какая была у шума на входе, всё это не имеет никакого смысла. Сам шаг квантования неважен; важно только его отношение к шума (и даже с отношением ≈ 1.5 деквантователь может сделать приличный выход).

Но Вы всё это и так знаете
Илья

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

Но не всегда - что мы видим на примере со star trails.

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

А в красном - и так и сяк:

Мне кажется, вы из каких-то частично ложных предпосылок исходите.

P.S. Контраст поднимал на глазок, сравнивать количественно не стоит, качественно - все видно.

А в красном - и так и сяк:

Я повернул, выделил два прямоугольника; identify -verbose даёт:

Image: farther-from-trail.png
Geometry: 19x340+0+0
Channel statistics:
Gray:
min: 76 (0.298039)
max: 121 (0.47451)
mean: 94.4711 (0.370475)
standard deviation: 5.40536 (0.0211975)
kurtosis: 0.436501
skewness: 0.0739209
Image: near-trail.png
Geometry: 19x340+0+0
Channel statistics:
Gray:
min: 72 (0.282353)
max: 145 (0.568627)
mean: 101.85 (0.399414)
standard deviation: 8.65991 (0.0339604)
kurtosis: 1.71035
skewness: 0.857351

Я бы сказал что весьма существенно ярче

Мне кажется, вы из каких-то частично ложных предпосылок исходите.

Может быть У меня было просветление после того как я увидел результаты моделирования Kasson а. У него явно была блоха. После того как он её исправил, бороды около симулированных следов звёзд исчезли. (Исправленные результаты на http://blog.kasson.com/?p=4847, не знаю как найти блохастые.)

Я не понимаю что такое геометрия 19x340+0+0. Это координаты плюс нулевой размер или что?
Или вы выделили оптом два прямоугольника 19x340 (а нули - что?)

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

Но, по-моему, более темные полоски в зеленом прекрасно видны и так.

Я не понимаю что такое геометрия 19x340+0+0
Не важно; размер=19x340. (identify может работать с многослойными графическими форматами, и слои могут быть сдвинуты.)

нужно, очевидно, ходить кусками шириной 16

Я лично не живу в идеальном мире. Я взял Ваш пример, и в нём это невозможно.

Усреднять вместе с треком - странно. Усреднять, захватывая как блоки с большой дельтой, так и соседние - тоже странно.

Who cares? Кусок near-trail.png захватывал бороду примерно на своей площади; кусок farther-from-trail.png находится очень близко, но не трогает бороду . Получается что на бороде среднее примерно на (101.85 - 94.4711)/ ярче. (Конечно, это может быть также результатом постеризации; но мне кажется что всё примеры выглядят очень похоже; при постеризации должно быть округление вверх так же часто как округление вниз, и примеры должны были бы выглядеть по-разному.)

Я продолжаю не понимать. Как вырезка 19x340 может захватывать бороду на 1/3 площади, если высота блока бороды ~50 пикселов (максимальное что увидел), т.е. это 1/7 в лучшем случае?

Как удалось избавиться от основного star trail и от прочих (коих там миллиарды по очевидным причинам)?
Самый большой блок бороды, который мне удалось выделить без явных трейлов - 14x21 пиксел. Примерно 1/20 по площади от 19x340.

Ну вот нарисуйте ваши блоки поверх картинки что ли?

Но, по-моему, более темные полоски в зеленом прекрасно видны и так.

Это обсуждение в режиме ОБС . Я сделал то же что сделал раньше в красном (что Вы не понимаете ;-), но в зелёном канале. Результат:

Image: G-near-trail.png
Geometry: 19x220+0+0
Channel statistics:
Gray:
min: 52 (0.203922)
max: 98 (0.384314)
mean: 72.6507 (0.284905)
standard deviation: 6.96605 (0.0273178)
kurtosis: 0.345157
skewness: 0.603942
Image: G-farther-from-trail.png
Geometry: 19x220+0+0
Gray:
min: 57 (0.223529)
max: 80 (0.313725)
mean: 66.3612 (0.26024)
standard deviation: 2.92803 (0.0114825)
kurtosis: 0.530137
skewness: 0.519886

Опять ярче и на очень похожее число (6...8)!

Я бы добавил картинку как я вырезал прямоугольники, но Ваша помощь (Images can be added to this post) остаётся загадкой КАК?

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

>>Я бы добавил картинку как я вырезал прямоугольники, но Ваша помощь (Images can be added to this post) остаётся загадкой КАК?

Анонимусам - увы, никак. Авторизуйтесь - будет кнопка. Но можно URL картинки привести, впрочем.

Add new comment