Выбор: беззеркальная камера со сменными объективами

nDrju:

ee2, там же еще и кривая накладывается.

Да, накладывается и кривая, то есть все эти биты сами по себе всего лишь индекс к тоновой кривой. Вообще не зная, что конкретно дает матрица, сложно даже утверждать, что там будет постеризация. Но да, возможно при перепаде больше 7 бит, пойдут потери точности. Вопрос бывают ли там перепады больше 7 бит в принципе, может у тетки 7 бит - это разница между черной дырой и солнцем на расстоянии метра - ведь распределение информации по битам нелинейно...
Если бы данные были линейными и был известен формат, в котором снимает матрица, можно было бы говорить наверняка.
Плюс там данные записываются с некоторой избыточностью, т.е. 11 бит минимум + 7 бит дельта приводятся в итоге к 11 битам...

nDrju:

Что вы имеете ввиду под нелинейными значениями? С матрицы данные идут линейные.

К линейным их приводит тоновая кривая при распаковке. А данные с матрицы перед записью в RAW тоже проходят через кривую (обратную кривой, которую они проходят при распаковке), которая делает данные нелинейными.

nDrju:

ee2, я вот как-то не особо понял как в 11 бит можно уместить максимум если максимум 2^14=)

Экспоненциальная кривая "разжимает" данные из 11 бит в сколько нужно, как-то так.

nDrju:

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

Там все сложно. Поэтому я и не стал бы так смело заявлять, что там полезет постеризация - не зная, что реализовано в железе на камере. А если постеризация и будет, то вероятность ее ничтожна, думаю в блоках 16х16 очень редко встречается резкий переход света силой в 7 бит. Может и попадется один такой блок 16х16 на 100 снимков, никто и не заметит... Если бы постеризация была чем-то закономерным, эта информация и жалобы пользователей уже были бы везде.

nDrju:

ee2, горячие пиксели. Может еще материал с мелкой структурой? Блики мелкие.

Ну так горячие пиксели пусть теряют в точности, всем пофиг. Они все равно не несут информации, а на точность соседних по блоку влиять не будут.
Сложно представить блики меньше 16 пикселей на 20-24Мп матрице, да еще и без плавного перехода...

nDrju:

На самом деле не понимаю почему нельзя давать возможность пользователю самому выбрать, надо ли ему сжатие или нет.

Возможно в угоду скорострельности. Возможно действительно нет разницы, сжимать или не сжимать - вряд ли инженеры тетки просто тупые.

nDrju:

ee2, так горячий пиксель будет максимумом же. Как я понимаю потери будут вокруг него, но не в самом пикселе, не?

Счет идет от минимума. Максимум просто записывается, но в вычислениях не участвует (в другом месте участвует). Теряют информацию пиксели, которые ярче минимума на 7 бит.
Горячий пиксель будет сам себе одиночка, потерявший информацию. Остальной блок будет в полном порядке.

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

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

Где мои биты на пиксель?

Съели!

nDrju:

А разве в 12 году уже были A7?

А эту статью буду упоминать еще лет десять. Применительно ко всем камерам вообще. Так что и про А7 увидим, и про А7 mark 10

Def:

nDrju,
4. Далее специалисты сами найдут откуда взялось значение переменной "bpp", а остальные верят мне на слово - значение может быть 8 или 12 и означает кол-во бит на пиксель, читается из метадаты этого самого рава. Кстати для А7 там будет 14 и работать не будет вообще ничего.

(не буду цитировать все, только для контекста)

Есть одно существенное обстоятельство: если этому коду скормить данные от, к примеру, A7, то он их раскодирует. Сюрприз.

Причем, сделает это так же, как (к примеру) Adobe: бинарные данные после Adobe DNG Converter в точности такие же, как после этого кода.

Смотря что понимать под битами.
RAW-данных в A7 - 8 бит на пиксель. Ровно. Формат - вот прямо как написано в той заметке, которую вы критикуете: 11-битные базовые значения, 4-битные координаты min/max, 7-битные дельты.

После раскодирования (вышеприведенным кодом, хм) и наложения тоновой кривой (линеаризации) - получается размах данных от 0 до 16 тысяч с хвостиком (сюрприз, реальный размах может быть чуть больше чем 16383, в тоновой кривой лимит вообще чуть выше 17к, только дотуда не доходит).
Этот размах одинаков и у NEX 3 (12-битный АЦП) и у A7 (по спекам - 14-битный АЦП) и у других камер с тем же форматом данных.

Если считать "уникальные значения", то у A7 их будет порядка 8тысяч (опять же как считать, то что ниже уровня черного - считаем или нет?) то есть соответствует 13 битам.

Родной соневский софт, заметим, декодирует так же абсолютно. С теми же артефактами на (очень) контрастных границах.

Да, exiv2.org как "официальный сайт EXIF" отдельно меня повеселило.

Сказка или не сказка - а этот код эти RAW раскодирует. Получается то же что у Adobe (можно побитно сравнить) или Sony (увы, только визуально)

Такая вот история.