О сортах RAW у Sony

Про тоновую кривую в новых камерах 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) не пользуется):

// Process 32 pixels (16x2) per loop.
    for (uint32 x = 0; x < w - 30;) {
      bits.checkPos();
      int _max = bits.getBits(11);
      int _min = bits.getBits(11);
      int _imax = bits.getBits(4);
      int _imin = bits.getBits(4);
      int sh;
      for (sh = 0; sh < 4 && 0x80 << sh <= _max - _min; sh++);
      for (int i = 0; i < 16; i++) {
        int p;
        if (i == _imax) p = _max;
        else if (i == _imin) p = _min;
        else {
          p = (bits.getBits(7) << sh) + _min;
          if (p > 0x7ff)
            p = 0x7ff;
        }
        dest[x+i*2] = curve[p << 1];
      }
      x += x & 1 ? 31 : 1;  // Skip to next 32 pixels
    }
Если простыми словами, то
  • Пишутся, действительно, 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 - относится только к диапазону значений в тоновой кривой.

Comments

Напоминает DXT сжатие

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

Кросс-корреляция дает DXT уйти до 1-4 бит на пиксель, но для насыщенных оттенков это, естественно, неприменимо. Ну и плюс DXT в реальном времени упаковывать очень накладно.

Поэтому для меня это выглядит как "DXT покомпонентный из-за требований к CPU + артефактам"

Не, просто принципы же другие. Кросс-корреляция и прочие 4:1:1 они как-то физиологичны.
А тут - все тупо и банально.

Стоп, но ведь в DXT нет никакого chroma subsampling, а палитра растянута по RGB а не HSV/Lab, где тут физиологичность?)

В корреляциях

тут становится интересно еще вот что: народ баянит (http://www.photoclubalpha.com/2012/12/27/sonys-alpha-99-mastery-wrapped-...),
что обещанные 14 бит работают также как в D3X - доп.считыванием сигнала с матрицы и соотв. растет лаг закрытия затвора (точнее открытия обратно)
и при серийной съемке обратно 12 бит (7 т.е.;-)

По-моему про "доп считывание сигнала с матрицы" - это какая-то ересь.

http://www.bythom.com/nikond3xreview.htm

это есть в спецификациях матрицы сониной (для матриц 12мп кроп и 24мп ФФ)

Сенсоры в D3X и a99 - разные по обвязке.

Да, н оя отчетливо помню еще при анонсе матриц Сони (а не камер) было сказано, что ест ьвозможность считывать по-другому и получать больше бит, с потерей скорости (хоть 16, но тогда это раз в полторы секунды ЕМНИП)

Это достигается за один такт считывания, программированием величины ступеньки АЦП. Киркпатрик за критерий точности экспономериии принимает гистограмму в ACR - что вполне характеризует его понимание вопроса.

возможно (вопрос конвертации в ACR и Килпатрица тут вообще не причем по-моему, он писал про доп. задержку), меня как юзера интересует:
а) где обещанные 14 бит
б) во всех режимах они есть или нет?
в) наскольо ни честные

У Хогана я не нашел слов "дополнительное чтение", может быть плохо искал. Покажите пожалуйста точнее.

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

FX Format, Lossless Compressed 14 bit NEF (1.8 fps): 28 frames
FX Format, Lossless Compressed 12 bit NEF (5 fps): 24 frames
FX Format, JPEG Fine (5 fps): 44 frames
DX Format, Lossless Compressed 14 bit NEF (2.6 fps): 52 frames
DX Format, Lossless Compressed 12 bit NEF (7 fps): 32 frames
DX Format, JPEG Fine (7 fps): 76 frames

Я не вижу тут слов "дополнительное чтение".

То что АЦП может иметь два режима работы, 12 и 14 бит, с разной предельной частотой считывания - это нормально.

А "дополнительное чтение" - это какая-то ересь.

ок, читает дольше, так вернее, мне важно, что дольше

И, да, покажите мне файл с A99 в котором было бы не ~24 мегабайта - обсудим 14-битность и его внутреннее содержание.

Все файлы что я видел - упакованы по процедуре, описанной в посте: 11 бит на 1/8 пикселов и 7 бит на остальные 21 мегапиксел.
Возможно, как и у A900, там есть два формата, ну так покажите мне второй.

а99 меня нет, но этот вопрос меня весьма интересует как раз

Судя по dpreview-шному review, у A99 нет регулировки видов RAW (а у A900 - оба формата упомянуты)

нету, да
юзеры подтверждают,
вопрос только в том сейчас, куда деваются обещанные 14 бит

Жаль, если в новых камерах этот ARW2 нельзя переключить на старый ARW.

Я ни разу не видел файлов с NEX, SLT-Axx, RX-nn в другом формате, только в этом.
Кроме того, конкретно для A99 два режима RAW не указаны в обзоре dpreview (а для A900 - указаны).

Это не означает несуществования, но позволяет его подозревать с 99%-й вероятностью. Иначе бы хоть в каком-то обзоре упомянули бы, что есть файлы на 24 мегабайта, а есть на 36 или что-то вроде того.

ни в одной SLT, NEX, и RX камере нет выбора типа RAW (кроме кропа)

Следовательно, 14-битность - есть какая-то фантазия. Подкрепленная, конечно, диапазоном значений тоновой кривой (там аккурат до 16к)

тогда это уже не фантазия, а обман покупателя

http://forums.dpreview.com/forums/thread/3358494
What I found in the RX1 file (A99 is similar, but the particular file was a bit worse):
There are 1530 distinct values in my best raw file out of the sample set of files I tried.
The range of values is 0-4093 (which is twelve bits per channel output, not 14, alas)
The values in certain ranges are consolidated, in other words:
0-800 contains 801 unique values (i.e. is continuous)
801-1424 contains 320 unique values (skips 1 out of every 2)
1424-1427 contains 1 unique value (skips 2 of 3)
1428-2023 contains 149 unique values (skips 3 of 4)
2024-2029 contains 1 unique value (skips 5 of 6)
2030-4093 contains 258 unique values (skips of 8)

По-моему, 14-битных RAW никто не обещал.
А процессинг и изготовление JPEG там вполне могут быть 14-битными, отчего нет.

1530 distinct values - это правильный порядок. 11 бит (после декомпрессии), минус 64 уровня черного (если считать до применения тоновой кривой и деления на 4).

Впрочем, обещали.
"14-bit RAW output" - прямо на Store.sony.com.

Это размах значений тоновой кривой.

"14bit raw output..."
http://www.dpreview.com/news/2012/09/12/Sony-announces-Alpha-SLT-A99-24M...

пока, как я понял выходит следующее:
а) во всех режимах, кроме покадрового - с матрицы читают 12бит
б) в покадровом на а99 (RX1?) читают 14 бит
в) в любом случае упаковывают в эти 7(11) бит

Кстати, с учетом экспандящей кривой, эта самая 14-битность может быть не полным фейком.

Т.е. уровней - ~2000
А диапазон рабочий - "14 стопов" (минус шум)

т.е. при описанной вами компрессии подать вход 14 бит вместо 12 будет реальный профит?

а если это соотнести с гипотетическими (если не включат вновых прошивках) нежатыми 12 битами?
(ну или теми же 12 нежатыми на а900)

Я не знаю насколько профит будет реальный, что там с шумом - мне непонятно.

Но в эти 7/11 бит кодируется 14-битный выходной диапазон. Какой при этом входной - мне неведомо (впрочем, по дыркам на гистограмме наверное можно оценить).

Мыльницы, потому что de facto это не RAW.
Камера должна быть или с DNG, или телефоном.

Сонькины ARW2 прекрасно конвертируются в DNG.

Преобразование с потерями уже произошло. Это такое же мошенничество, как и линейные DNG из RAF.

Ну а как в DNG описать нормально (так, чтобы любой DNG-enabled конвертор понял) то, что у нас две (полу)картинки с разной чувствительностью, смешением пикселов и, судя по всему, с несколько разными цветовыми данными?

Опубликовать свой формат, естественно. Будет ли он называться "DNG" - пофиг.
Да, для разных CFA нужна разная обработка, но DNG на это никак не влияет.

Ну так Fuji и использует свой формат. И он очень простой. И "99%" конверторов на второй кадр просто ложит с прибором (или пробором).

То что он не "опубликован" - не имеет значения т.к. все кто хочет - его умеют читать.

> но DNG на это никак не влияет.

за исключением того, что он не поддерживает экзотические варианты... не говоря уже о том foveon-oбразных вариантах

мда, некрасиво получилось. но, видимо, так данные и приходят с матрицы. матрицы Sony выдают 60p, это нужно для видео и для быстрого контрастного автофокуса на беззеркалках. экономят bandwidth, иначе нужно больше времени и полосы для оцифровки.

Ну началось то все с A900, где был настоящий 12-битный режим и появился еще вот этот.

И прямо в таком виде - не должно бы приходить, АЦП ведь цвета не интерливит.

тогда я не вижу смысла в этой схеме.

Ну такое вот простое сжатие.

Пипл - хавает. Мне тут на хоботе написали, что "4 года снимаю в этот формат и постеризации не вижу". Ну вот не видят они, зачем делать лучше тогда?

User referenced to your post from особенности RAW в камерах Sony saying: [...] разработчик libRAW пишет [...]

Я тут попросил владельца сделать маленький тест,
экспозиция идентичная, ISO 200 и 1600
режима протяжки Single (в котором, согласно Килпатрику только и есть 14 бит) и Continous (в котором 12).
По размеру файлы одинаковые.
Raw digger показывает:
на ISO 200 в файле DSC02420 (Single) в самом дохлом красном канале 1509 значений
на ISO 200 в файле DSC02423 (Continous) в самом дохлом красном канале 1126 значений
на ISO 1600 в файле DSC02430 (Continous) в самом дохлом красном канале 1148 значений
на ISO 1600 в файле DSC02433 (Single)в самом дохлом красном канале 1634 значений

Значений никогда не будет больше ~2000 (2048 минус уровень черного "до умножения на 2" т.е. 64).

Более того, тоновая кривая во всех виденных мной случаях была одинаковой и вот такой.

Из тоновой кривой вытекает такая постановка эксперимента: снять серую плашку так, чтобы она вся попала на участок с наклоном 1 (это меньше чем 2048 "после умножения на 2" т.е. 3 стопа ниже насыщения после наложения кривой) и посмотреть на постеризацию.

Предполагая что у соньки headroom - стопа 2.5-3, надо дать экспопоправку где-то -2 и снимать себе равномерное поле.

Пару лет назад мрачно разглядывая тот-же кусок кода я медитировал на возможные последствия и в общем ни к чему мало-мало стоящему внимания не пришел. С тех пор я снимаю только на NEX-ы у которых есть только этот cRaw/ARW2 и никаких практических последствий для себя тоже пока не увидел. Я уверен, что постеризацию теней заметил бы за все это время просто потому что тяну их в 100% моих снимков на исо от 100 до 400 и даже бывает на 800. На A900 с форматом без компрессии замечал по крайней мере (история с исо 320). Я думаю инженерный расчет у сони был на то, что там где градации реально нужны их схема не будет создавать потерь.
Правда постеризацию светов я мог и не заметить, потому что ETTR у меня практически не бывает.

Практическая ценность офигенная, можно соневодов потроллить!

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

Я вообще не уверен, что термин постеризация применим к термину резкая граница :)
В любом случае на своих снимках я не вижу ничего заслуживающего порицания.

С Новым годом кстати!

C Новым годом, да!

Там все-таки блок относительно здоровый, 32 пиксела. Т.е. при печати 160dpi - 5 миллиметров.
Должны быть - при хорошей оптике - к примеру, эффекты на закатном небе со звездами (небо еще синее, а звезды уже яркие). Микроскопические, но на ровном небе могут быть видны.

I cannot believe I am reading (via google translate) and responding to posts in Russian, and I don't have definitive examples yet--but I believe there could be a significant practical difference in terms of tone curve manipulation and tone mapping.

In other words, the visual impact of the compression is undetectable in most normal editing scenarios, including a bit of highlight and shadow manipulation. However, when performing single file HDR, or any significant amount of editing that pushes the histogram around in all kinds of ways, the loss of precision should begin to show up sooner than it would with true 14-bit files.

But I don't have the right raw files and tools to prove it with yet. (For one thing, once I produce any output, I do not have the excellent raw digger to provide me with good histogram data, and I haven't found something comparable that I can use with Tiff file output. I also ideally need to create test raw files with both a Sony and a 14 bit camera for a demonstration, though I might be able to make do with some existing sample raw files posted on the web, provided they are well exposed for that purpose.

> For one thing, once I produce any output, I do not have the excellent raw digger to provide me with good histogram data, and I haven't found something comparable that I can use with Tiff file output.

It is not obvious how to obtain tiff files to be compared with raw data, as raw conversion adds dithering to the image. I think half mode bitmaps (binning 4 RGGB pixels into one full-colour), white balance applied, no gamma applied, no colour management, - is the most "mathematically" telling, but in practice accurate real-world raw processing can eliminate many defects (and introduce defects of its own).

We will see about TIFF histograms in RawDigger, but it is not currently the first priority ;) In most of the cases it is really hard to explain why the temptation to compare histograms of raw data with histograms of fully rendered tiffs may be so misleading.

Спасибо за разъяснения к статье.

Вот похоже пример его работы:

вот пример работы алгоритма компрессии идет клипинг
http://www.flickr.com/photos/107097587@N08/11082420615

Но по-моему и пофиг, классно что фотки меньше!

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

Итак, по пунктам.
1. Код, приведенный в статье - некая поделка для линукса под названием RawStudio. Работает сие вообще или нет - не известно, но будем придерживаться мысли что работает
2. Полный код класса, из которого выдернут кусок для статьи лежит здесь - https://github.com/wjakob/hdrmerge/blob/master/rawspeed/RawSpeed/ArwDeco...
3. Теперь неспециалисту придется просто мне верить, остальные смотрят в код, на строку 147.
4. Далее специалисты сами найдут откуда взялось значение переменной "bpp", а остальные верят мне на слово - значение может быть 8 или 12 и означает кол-во бит на пиксель, читается из метадаты этого самого рава. Кстати для А7 там будет 14 и работать не будет вообще ничего.
6. Алгоритм, обосранный в первоначальной статье применяется только для случая bpp = 8 и автор опуса не мог этого не знать (хотя кто его знает). У каких сониевских камер 8-битный рав - я не знаю, и в чем смысл паковать 8 бит в 7 - тоже. В комментариях есть некое упоминание о какой-то Sony E-550.
5. Если bpp = 12 (т.е. как во всех бзк кроме А7/А7р) - используется совершенно другой алгоритм и разбираться в нем мне лень. Пока - достаточно факта что автор статьи сознательно все это умолчал, справедливо рассчитывая что недалекие юзеры побегут друг другу пересылать линки на статью с криками "все пропало", что собсвенно и произошло.

Дополнение, чисто для задротов: чтобы не было сомнений, что bpp будет равно 12.
Это читается тэг из экзифа Exif.Image.BitsPerSample, его id = 0x0102. В большинстве программ-вьюверов экзифа сей тег не показывается вообще, только тэг Exif.Image.CompressedBitsPerPixel (id=0x9102), который кстати = 8.
Тэг BitsPerSample можно разглядеть только программой с официального сайта экзифа - http://www.exiv2.org/download.html, запустив ее с параметрами "exiv2.exe -p v pr имя_файла". И даже для старого некс 5н там значение 12.

Есть одно обстоятельство: приведенный алгоритм берет и работает. И для NEX-ов, и для A7/A7r/A7x, и для RX1 и для Axx.
А тот в котором "разбираться лень" - он для старых камер (переход состоялся в A900, где были оба формата, в более новых камерах - вот только обсуждаемый)

exiv2.org - это не официальный сайт exif-а, а официальный сайт библиотеки exiv2, но это уже мелочи.

Для истории. Обсуждение случилось тут: http://forum.onliner.by/viewtopic.php?t=4945205&start=13740