RAW SONY - всего 7 бит?

Кросспост из блога автора.

Про тоновую кривую в новых камерах Sony я уже писал и повторяться не буду.
Но тут переписывался с Ллойдом Чамберсом на тему Sony RX1 (прежде всего, конечно, как щупать RawDigger-ом неподдерживаемые камеры, как уровень черного определить и т.п.) и обнаружил массу веселья в самом формате ARW, точнее в новых его версиях.
В камерах Sony используются три формата записи RAW:

• "Старый ARW" - камеры поколения Sony A100-A290 (точный список не составлял, по ощущениям это именно "старые камеры"). Это обычное такое хаффмановское сжатие, без потерь. При использовании этого режима - RAW-файлы будут сильно разного размера, в зависимости от детализации и шума.
• Нежатый 12-битный RAW. Просто пишутся 2 пикселя в 3 байта, без сжатия, без потерь, без прочих глупостей. Этот формат используется в A900 в режиме "большие файлы" (~36Mb + размер JPEG), в Minolta 5D, возможно в еще каких-то, опять же не изучал. При использовании этого режима размер файлов "примерно одинаковый", полтора байта на пиксель плюс размер JPEG-а и EXIF-блоков. Соответственно, с A900 получается 36-37-мегабайтный файл.
• Формат "ARW2" (так его называет Dave Coffin, а за ним и я). Этот режим записи используется во всех новых камерах Sony: NEX-xx, SLT-Axx, RX1, RX100. Его можно включить и на A900 (никогда не было этой камеры, надеюсь что этот режим включился не насильно после апдейта фирмвари, а есть возможность переключения юзером).
  При использовании этого режима RAW-файл имеет размер "1 байт на пиксель" (+JPEG и EXIF, конечно). 24-мегапиксельная A99 или NEX7 (или A900 в этом режиме) выдают, соответственно, 24-мегабайтный файл.

Вот последний режим нам и интересен, потому что он (и только он?) используется в актуальных камерах. Вот как выглядит исходный код кусочка декодера (тот кусочек, который собственно распаковывает) этого формата в библиотеке RawSpeed (в dcraw - то же самое по смыслу, но Dave Coffin - истинный хакер и всякими глупостями вроде getBits(7) не пользуется):

1. // Process 32 pixels (16x2) per loop.

2.     for (uint32 x = 0; x < w - 30;) {

3.       bits.checkPos();

4.       int _max = bits.getBits(11);

5.       int _min = bits.getBits(11);

6.       int _imax = bits.getBits(4);

7.       int _imin = bits.getBits(4);

8.       int sh;

9.       for (sh = 0; sh < 4 && 0x80 << sh <= _max - _min; sh++);

10.       for (int i = 0; i < 16; i++) {

11.         int p;

12.         if (i == _imax) p = _max;

13.         else if (i == _imin) p = _min;

14.         else {

15.           p = (bits.getBits(7) << sh) + _min;

16.           if (p > 0x7ff)

17.             p = 0x7ff;

18.         }

19.         dest[x+i*2] = curve[p << 1];

20.       }

21.       x += x & 1 ? 31 : 1;  // Skip to next 32 pixels

22.     }

    Если простыми словами, то
    

    • Пишутся, действительно, 8 бит данных на пиксель.
    • Конкретнее
      • Строка пикселов разбивается на куски по 16 пикселов.
      • Четные/нечетные пикселы обрабатываются отдельно т.к. они разных цветов.
      • В 16 байтном блоке, описывающем 16 пикселов одного цвета, содержатся:
        • 11-битный максимум значений в блоке.
        • 11-битный минимум значений в блоке.
        • 4-битные индексы минимального и максимального пикселов в блоке, что позволяет эти пикселы закодировать 4-мя битами и точно.
        • 14 7-битных дельт относительно минимума.
      • 7-битные данные превращаются в 11-битные путем сдвига на 0-4 бита влево и прибавления минимума в блоке.
    • Соответственно
      • Если у нас внутри 16-пиксельного блока одного цвета - маленькие вариации (меньше 128 единиц АЦП), то данный метод пакует без потерь. И всякие ровные градиенты будут переданы хорошо.
      • А если в блок попала какая-то контрастная граница (или просто пиксель зашумел), то точность представления остается все той же, 7-битной и данные о цвете/яркости будут переданы приблизительно (с 7-битной точностью).
    • 11-битные данные (точнее, "локально 7-битные") значения сдвигаются на бит влево и засовываются в кривую которую мы обсуждали тут год назад.

    Короче, если вы хотите потроллить соневладельца (но только с новыми камерами, NEX-xx, SLT-Axx, RX-1, RX-100), вы просто скажите ему, что у него RAW - 7-битный (а начнет возмущаться - ну уточните, что 1/8 пикселов - 11 битная, но остальные то - точно 7-битные). P.S. Эти самые 7 бит - несравнимы с 8-битным TIFF и подобными. У TIFF - гамма-коррекция, а RAW-данные - линейны и в тенях там, при наличии хот-пикселов, резких границ и т.п. будет нехорошо.
    P.P.S. Сдается мне, что пресловутая 14-битность, про которую пишут для RX1 и A99 - относится только к диапазону значений в тоновой кривой.

О линейности RAW и ETTR

На картинке - кривая, которая применяется к RAW-данным камеры Sony NEX-C3 при их распаковке. NEX-C3 просто первая попалась под руку, в компрессированных RAW A77 или A900 совершенно такая же по смыслу кривая, немножно отличается в деталях.
После наложения этой кривой, RAW-данные становятся линейными. Соответственно, при упаковке используется обратная кривая, линейная в тенях и полутонах и загибающаяся в светах (последних 3 стопах диапазона). По сути, три верхних стопа диапазона сжали в 1 стоп сигнала.
Где именно происходит процесс сжатия светов из формы кривой (и процедуры распаковки) выяснить нельзя, это может быть и цифровой процесс над линейными данными обычного АЦП и сжатие в нелинейном АЦП или нелинейном предусилителе.
Собственно, ничего плохого в такой компрессии светов нет. От того, что в верхнем стопе будет не 2048 градаций (предполагая 12-битный АЦП), а "всего" около 600 - становится только хорошо, потому что поэкономленные 1400 градаций переезжают на второй и третий стопы сверху (полутона и следующий стоп за ними).

В случае Sony градаций на самом деле меньше: прежде чем наложить кривую, RAW-значение умножается на 2, т.е. реальная битность RAW-данных не 12, а 11. Cоответственно, в светах у нас примерно по 300 градаций на стоп, а в тенях - обычное линейное убывание, но в 4-м сверху стопе будет не 1024 градаций, а 512, в 5-м - 256 и так далее.
Следствий из этого я вижу два:

1. Если на вашей камере есть выбор между нежатым и жатым RAW (как он есть на A900), используйте нежатый. Вы не для того снимаете в RAW, чтобы сходу терять бит из данных, там их всего 12.
2. Для рассматриваемого же формата получается интересный вывод относительно ETTR:
   • Больше всего градаций - в 4-м сверху стопе. Т.е. "полутонах", "средне-сером".
   • Во всех стопах светлее средне-серого и в 5-м сверху - градаций около 300.
   • И только в более глубоких тенях количество градаций в данных начинает уменьшаться
   Как следствие, сдвигать, к примеру, 4-ю зону (по Адамсу) в 6-ю нет никакого смысла, градаций не прибавится. А вот гемороя прибавится т.к. цветовые профили поползут.

Помимо Sony, подобные кривые, хранящиеся в метаданных, есть у большинства снимающих в 8-битный RAW камер, у некоторых камер Kodak, некоторых 12-битных камер Canon (подозреваю 1D/1Ds, но пока не проверял), кинокамер Red. Но содержимое кривых на этих камерах я пока не смотрел. Хотя по смыслу должно быть похоже, ибо делается для одного и того же.
Ну и в DNG тоже есть, но тоже не исследовал, используется ли, кем и как.