Последние 2 бита - зачем они?


В последнее время высказывается мнение, что 14 бит - излишество, так как в двух последних битах нет ничего, кроме шума. Никакой информации. Соображения о том, что каждая зона в 14-битной картинке содержит в 4 раза больше уровней, также не принимаются, так как оппоненты утверждают, что эти дополнительные уровни - "неправильные", ничего, кроме шума, не содержащие. Демонстрации, что дополнительные 2 бита поднимают разрешение - также игнорируются. Однако - судите сами.

На первой иллюстрации - результат конвертации ночного снимка Парижа (Nikon D3) с коррекцией на 12 eV перед конвертацией. Заметим, что если диапазон яркостей в сцене не столь велик, то уже после коррекции на 8-9 eV изображение часто пропадает полностью.

На второй - демонстрация гистограмм синего патча Macbeth ColorChecker. Снимки сделаны Nikon D3 на эффективной чувствительности ISO 3200. Левый патч на иллюстрации снят в режиме записи 12 бит, правый - в режиме записи 14 бит.

На третьей - сопоставление разрешения мишени, представляющей собой три малоконтрастные тонкие полоски (они отличаются от фона на 1/6 eV), после коррекции в конверторе на 7 eV. По сути, это воспроизведение малоконтрастных деталей в тенях.

И, наконец, на четвёртой и пятой - независимый эксперимент, поставленный участником форума DPReview David'ом.

В своём эксперименте он модифицировал dcraw, заполнив нулями старшие 12 бит 14-битного NEF'а, полученного из камеры Nikon D300. Иллюстрация 4 - вся сцена, иллюстрация 5 - та же сцена после усекновения 12 бит, до баланса белого и гамма-коррекций.

Возьмём результат Дэвида (а он, заметим, представляет собой JPEG, к тому же - уменьшенный в нецелое число раз, 2.1 по каналу, 4.2 по разрешению матрицы - что никак не улучшает наши шансы на экстракцию деталей) и подвергнем его обработке с целью выделения яркостного канала. Получим иллюстрацию 6. Обработка проводилась с применением вычислений в плавающей точке. Удалось получить не только контуры и текстуры в тенях, но и следы в среднем тоне. Тем самым, последние 2 бита содержат информацию не только о глубоких тенях.

Итак, можно видеть, что последние 2 бита содержат информацию, а, следовательно, и дополнительные уровни в 14-битном представлении - не все "неправильные".

Разумеется, вопрос состоит главным образом в этих "промежуточных" уровня, обеспечивающих ту самую "гладкость" изображения, о которой говорят разработчики камер. Именно они, эти уровни, и позволяют на большинстве high-end камер с 14-битными АЦП недодерживать примерно на 1.5 eV, получая качество изображения, сопоставимое с правильно экспонированными кадрами на 12-битных камерах. Или же применять более жёсткие режимы sharpening к деталям в средних тонах, не рискуя вырождением изображения. Вариантом того же является более решительный upsize и более плотный кроп. Изображение, полученное от 14-битных камер, более пластично поддаётся обработке.

Всё вышесказанное приложимо к разным моделям камер в разной степени.

Comments

the whole 14 bits

Ну, допустим, полезность последних двух битов доказана. На самом деле вопросов остаётся много. 12 бит не на всех камерах одинаковы. Как пример 5D и 350D -- некоторые люди считали, что у 350D в последних двух битах вообще только шум, но я думаю, что правильнее считать, что в них полезной информации меньше 2х бит. Многие фотографы замечали, что 5D лучше передаёт полутона, чем 20D/350D. Из чего напрашивается вывод, что биты в 5D честнее, как-то полнее использованы, что ли. После выхода 40D было много сравнений 5D и 40D, и те же фотографы, кто находил передачу полутонов 5D лучше, чем 20D, сказали, что теперь в 40D стало так же хорошо, как в 5D. Собственно, вопрос: как оценить "плотность", что ли, не знаю как выразить, полезной информации? Т.е. может все эти 14 бит 40D имеют такую же полезность, как 12 бит 5D?

> как оценить "плотность",

> как оценить "плотность", что ли, не знаю как выразить, полезной информации?

Я пользуюсь сравнением разрешения на малоконтрастных мишенях.

14 бит

Я всегда считал, что "последние 2 бита" - это те, которые идут после 14, т.е. заполняют дырку до полных 16. Совершенно честно.

Не надо забывать, что

Не надо забывать, что существуют еще повышенные ISO и вытягивание (специально/случайно) недодержаных кадров.

при чём здесь "честность"

при чём здесь "честность" битов на 350D? у камер разные прошивки (т.е. алгоритмы), разные матрицы (размер, возможно нюансы технологии). не удивительно, что результат получается разный. цифровая камера это очень сложная система со множеством параметров.

сейчас новые датчики, видимо, имеют большую чувствительность, что и позволило перейти к 14 битам. не правильно думать, что теперь все камеры с 14 бит дают одинаковую картинку, и что камера с 14 бит даёт картинку заведомо лучше, чем камера с 12 бит.

Есть же случаи, когда можно

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

Про то что "не все камеры.... дают одинаковую картинку" даже спорить нет смысла.

D300 - 2 разные камеры в

D300 - 2 разные камеры в одной по сути. Там нет "прочих равных". В D3 - да, при прочих равных, настолько равных, что похоже просто на сдвиг.

Разряды АЦП - это не Динамический Диапазон!

Мне кажется у многих тут есть недопонимание в терминологии. Дело в отм, что ДД сенсора определяется чисто его электро-механическими, аналоговыми свойствами. Далее, этот ДД можно оцифровать с некоторой дискретностью по уровням, которая определяется разрядностью АЦП. Эта самая дискретность позволяет картинке быть "пластичной" в обработке, т.е. растягивать и сжимать зоны без потери плавности градиентов. Но одинаковый ДД оцифрованный в 12 или 14 бит останется тем же самым. Это - что касается границ ДД. Что касается промежутка - все интереснее. Не надо забывать, что сенсоры - линейные устройства, а глаз воспринимает освещенность гармонически. Это грубо говоря означает, что на десятую зону приходится половина битового пространства, на девятую - четверть, и т.д. Соответственно, в тенях мы просто не имеем достаточной цифровой информации для "вытягивания" малоконтрастных деталей. Увеличение разрядности увеличивает число уровней, с которыми мы можем работать в тенях. Что касается "честных-нечестных" битов - ничего не могу сказать, все зависит от честности производителя сенсора - сколько шума он давит аналоговым способом и сколько цифровым (до записи RAW) - на их совести.

Я тут подумал..

.. таки я неправ. На десятую зону приходится половина не битового пространства, а числового. Т.е. при оцифровке 10-ти битовым АЦП - ровно один бит. Однако, количество различимых (цифровфм способом) уровней в зоне - это и есть числовое пространство, ширина которого значима при разделении деталей и критична, когда мы пытаемся различить детали в тени.

Сенсор - не только волна, но

Сенсор - не только волна, но и частица. Я к тому, что фотонная емкость там вполне конечна и само количество уровней, которые он может зарегистрировать (до всякого АЦП) - тоже конечно. У Кларка были подсчеты, там порядок величины - несколько десятков тысяч, не так и много.
Другими словами, растить разрядность АЦП за 16 бит не имеет смысла.

А про дискретность и плавность вы все правильно говорите - 14-битная камера допускает на полтора-два стопа недодержки среднего тона (много выше всех шумов) больше, чем 12-битная.

Дискретность

Дискретность аналогового сигнала пока что за рамками обсуждения, хотя мысль интересная. С другой стороны, никто не станет отрицать, что уровень шума всегда будет больше дискретизации по фотонам. Вопрос стОит ли регистрировать шум с точностью 16 или более бит довольно прозрачен. Когда я занимался ядерной физикой помнится АЦП регистраторов были 22-х битовыми и дипломы с диссертациями писались в частности о том, как выделять полезный сигнал из-под уровня шумов. Так что, запас карман не тянет! :)

Выделять можно, если мы знаем

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

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

> а десятую зону приходится

> а десятую зону приходится половина битового пространства

Не стал бы я зоны так однозначно к битам привязывать. В большинстве случаев десятая зона в raw обрезана, да и полторы-две следующих - тоже.

> Но одинаковый ДД оцифрованный в 12 или 14 бит останется тем же самым.

Как минимум, в тенях это не совсем так, точность отсечки повышается с ростом точности оцифровки.

Непонятно

Я не понимаю, о чем Вы говорите. Что такое отсечка в RAW? Заметьте, про RAW я даже не упоминал, я оворил про АЦП. В АЦП может быть ограничение по максимальному уровню сигнала (насыщения мы избегаем правильной экспозицией), минимальный сигнал определяется тепловым шумом (возможно есть некий выставленный порог срабатывания) и между этими двумя пределами - все линейно. Что пишется при этом в RAW я не знаю, а кто знает - не скажет. Скорее всего, однако, "обрезания", Вами упомянутые, происходят в процессе обработки RAW, не верю я, что простой линейный АЦП они станут программировать какими-то кривыми на уровне сенсора.

Кстати, если кто пользовался замечательной софтиной LightZone мог заметить, что при импорте RAW она вешает (в принципе отключаемый) тональный фильтр довольно сложной конструкции. Строит она его из EXIF. Если RAW начать преобразовывать не отключая этот фильтр, то все коррекции вносятся поверх этой тональной кривой. ARC об этом например молчит и привести файл к изначалному, "сырому" виду не позволяет.

> Что такое отсечка в RAW? Я

> Что такое отсечка в RAW?

Я не употреблял такого термина. Информация о яркостях в светах обрезается самим сенсором - из-за переполнения "колодца". Соответственно и в raw она уже не попадает. Правильная экспозиция кадра часто вызывает обрезание (clipping) ярких светов - всего, что ярче диффузного белого. Десятая же зона - по определению - печатается нулевой относительной плотностью и в подавляющем большинстве случаев в экспозиции не учитывается вовсе.

Точность определения отсечки была упомянута в контексте теней. В 12-битном режиме D3 на 1 выходной уровень приходится около 16 фотонов, а в 14-битном - 4 фотона. Аналогичная ситуация и с уровнем шума - меньший квант оцифровки способствует более точному учёту уровня шума. Соответственно и нижнее пороговое значение определяется в 14-битном режиме точнее. Таким образом, в тенях 14-битный режим потенциально имеет несколько более продолженный динамический диапазон.

PS. Некоторые из АЦП представляют собой генератор, управляемоый таблицей, ЦАП и компаратор. Таблица - нелинейна, с её помощью выполняется сжатие (с потерями).

А, я понял!

Нет, десятая зона в моем понимании - это нечто иное, чем "совсем белый" :) Зона - это "зона" яркостей - 1/10 линейной по восприятию тональной шкалы. Она конечно включает в себя но не исчерпывается "совсем белым", а начинается от верхней границы девятой +1. Я нигде не читал такого определения но из того что читал, понял именно так. Опять же, LightZone.

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

Я знаю, что АЦП можно построить с любой характеристикой но классики настаивают, что АЦП в фото-сенсорах линейны. Можно конечно провести эксперимент и вывести производителей на чистую воду, построив реальную характеристику для сенсора, однако что это даст?

> уровень темного шума может

> уровень темного шума может быть гораздо выше, чем 16 фотонов.

На порядки выше. Несколько тысяч фотонов во многих случаях. Но это ничего не меняет в смысле подхода. Чем точнее отсекается нижняя граница, тем лучше можно воспроизвести тени.

> классики настаивают, что АЦП в фото-сенсорах линейны

Классики обычно не занимаются программированием конверторов, а несколько нелинейных характеристик самого сенсора - до АЦП - приводится в документации на сенсоры, доступной широкой публике в виде pdf'ов. Как именно делается сжатие в камерах - вопрос иной, есть программные реализации, есть аппаратные, в том числе и прямо в АЦП. Отличить их обычно можно по скорости работы, недоступности несжатого raw, по интенсивности и характеру шумов.

Описание зон по Адамсу - http://www.libraw.su/node/31

ARC об этом например молчит и

ARC об этом например молчит и привести файл к изначалному, "сырому" виду не позволяет.
Уже не так. DNG Profile Editor позволяет сделать профиль для ACR с любой тоновой кривой. В том числе -- и с абсолютно линейной.

Кстати, было бы интересно услышать мнение авторов сайта об этом новом инструменте.

Тоновая кривая - это часть

Тоновая кривая - это часть проблемы. Есть еще, например, primaries камеры (а если совсем нормально - цветовой профиль)

Там настраивается всё,

Там настраивается всё, посмотри. Правда, primaries камеры -- не прямо, но всё же.
Впрочем, есть описание формата профиля (в DNG 1.2), так что наверняка и их можно, но уже не этим инструментом.
А ещё он строит профиль по color checker'у моментально и честно (используя 20 переменных, а не 6 как все старые скрипты).

Возвращаясь к исходному

Возвращаясь к исходному вопросу - как посмотреть (!) тоновую кривую, которая используется до всех редактирований?

Потому как линейная - это все хорошо, только не нужно, а строить изменения относительно неизвестной кривой - тоже как-то глупо...

(1) Качаем DNG Profile Editor

(1) Качаем DNG Profile Editor из Adobe.Labs
(2) Обновляем ACR до 4.5/LightRoom до 2.0-Release (другие версии не поймут самодельных профилей, если нам только посмотреть имеющийся, то можно этого и не делать)
(3) Если у нас не-DNG камера, берём DNG COnverter и делаем из своего RAW'а DNG.
(4) Запускаем DNG Profile Editor (его даже ставить не надо, это Standalone EXE, по крайней мере на Win).
(5) Открываем DNG от своей камеры.
(6) Выбираем базовый профиль, который будет взят за основу при редактировании -- как мы знаем, у ACR их несколько для каждой камеры, обычно "родной", ACR 3.7 и ACR 4.4. Так же можно поставить новый набор профилей -- Adobe Standard Beta, который обещает быть лучше, особенно для Canon и Nikon.
(7) Идём на закладку Tone Curve и включаем галку "Показ базовой тоновой кривой"

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

Все, я понял. Это не профиль,

Все, я понял.

Это не профиль, который в терминах спеков DNG (который, похоже, нормальный ICC),
а профиль в смысле сохранения настроек конвертора.

При этом, результат какой-то неубедительный в смысле тоновой кривой. Я взял DNG от Синара и Лейки, выбираю тоновые кривые default/Base profile/Linear, вижу для первых двух достаточно крутые тоновые кривые ( полутонах-тенях, а отображение меняется только в светах.
Кидалово?

Ты плохо читал документацию.

Ты плохо читал документацию. Это именно профиль в терминах спеков DNG. И там в FAQ'е шесть раз подчёркнуто, что это вовсе не ICC, а именно спец-построение для конверсии. И там доступны настройки (color table) которых НЕТ в настройках конвертера через его GUI.

Что где меняется -- я, если честно, пока не исследовал, ограничился построением обоих таблиц (обрати внимание, что там можно редактировать отдельно обе части DNG-профиля -- и для A и для D65) по XRite color Checker, вместо скриптов. Ну и почитал документацию.

Ну я же смотрю одним глазом

Ну я же смотрю одним глазом на тоновую кривую, а другим - на изменения изображения. И вижу, что они не согласуются.

Вот, например, вопрос - там где тоновая кривая, там что по осям?

А профиль в "спеках DNG" - это ты про какой набор тегов? И где там теги с цветовыми таблицами?

Второй вопрос снимается - это

Второй вопрос снимается - это ProfileLookTableData - "starting point for user adjustment". Я же говорю, это все настройки конвертора (пусть часть их и не видна в гуе).

Я понимаю, что приложений с DNG 1.2 еще толком нету в природе, но когда будут (не адобовские) - попробуй скормить им результаты редактирования, скорее всего удивишься.

Я так понимаю, что в DNG 1.2

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

А про настройки -- так ВСЁ -- это настройки конвертера. Точно так же как ICC -- настройки конвертера из RGB в RGB (грубо говоря). И если кто-то будет использовать ICC, не реализуя (или реализуя неверно) алгоритмы, описанные в стандарте, то результаты тоже будут наверняка удивительные.

Описан, блин, алгоритм. Вот

Описан, блин, алгоритм. Вот есть теги AsShotICCProfile/CurrentICCProfile, отлично.
Но почему они не используются в 6-м разделе?

Они, конечно, неплохо описали некий метод (алгоритм задокументировали, не иначе), только это ересь, начиная с RIMM

Авторы, между прочим, очень

Авторы, между прочим, очень отзывчивы в соотв. разделе форума :)
Адобовского.
Можно пойти и спросить.
И если это ересь -- то как работает ACR? Или описали не то, что реально используют, диверсия такая? спеку-то авторы ACR пишут...

Не, оно естественно будет

Не, оно естественно будет работать, RGBtoXYZ и обратно никто не отменял.
Вопрос в качестве результата.

Ересь это по многим причинам
а) вовсе не нужна матричная математика для баланса белого (достаточно диагональной матрицы). Результат оверкилла - пролезающий из слабых каналов шум
б) вовсе не нужен ProPhoto RGB, особенно при работе в целых числах
в) делать из ProPhoto HSB, потом редактировать в нем, потом обратно -- а что делать, когда мы попадаем в несуществующий цвет после редактирования?

Ну а лечить адобу голову про все это - мне это не нужно.

(1) Твоя тоновая кривая

(1) Твоя тоновая кривая накладывается ОТНОСИТЕЛЬНО базовой, это описано в документации. Думаю, всё дело в этом.

(2) Надо читать спеку.

(3) Я ещё не читал спеку, я исключительно про:
the DNG 1.2 specification, which expands and formalizes the concept of a color profile for raw (i.e., scene-referred) image data captured by digital sensors,

Спеку, повторюсь, ещё не читал.

1) Только по первому пункту -

1) Только по первому пункту - я ставлю галку "показать базовую" и выбираю эту базовую из "defaults" (степенная кривая) и "Linear".
Больше вообще ничего не делаю.

И вижу, что изображение на экране не соответствует кривой.

2) Можно ли профайл эдитором редактировать ColorMatrix1/ColorMatrix2 (я такой возможности не вижу т.к. на закладке редактирование в виде HS и только для трех цветов, а их может быть и больше)?

3) Ну да, expands. Мне весь их шестой раздел кажется ересью, ну да я им не судья.

1. У меня -- меняется. Linear

1. У меня -- меняется. Linear -- типичное без гаммы блёкло-тёмное изображение, Base Profile и Camera RAW Defaults -- одинаковая степенная и картинка поживее.
Повторил Base Profile пользовательской кривой, выбрал Linar в качестве base -- результат тот же, что "наоборот"...

2. Я так понимаю, дальше ты можешь всё тонко настраивать любым числом цветов на первой закладке... Но я, повторю ещё раз, не читал всей математики которую они к этому предлагают, и не знаю хватает ли трёх primary или действительно их должно быть больше.

Ну да, expands. Мне весь их

Ну да, expands. Мне весь их шестой раздел кажется ересью, ну да я им не судья.
Ну, вот это я и имел ввиду там раньше, говоря об алгоритмах и их [не]оптимальности :)

Формат этого профиля есть в

Формат этого профиля есть в спеках DNG 1.2, но его я тоже не читал пока -- завал на работе.

И, да, профили, идущие в комплекте с ACR, тоже в этом формате (они его просто открыли).

Но в каком-то смысле -- любой профиль есть просто сохранение настроек конвертера в стандартизованном формате.

Да, строит профили по

Да, строит профили по ColorCheker, и я посмотрел эти профили. Там колориметрия выходит совершенно неверная.

Подробностей бы

Подробностей бы технических...
Очень интересно, как оно всё внутри устроено именно с точки зрения RAW.
Вообще никаких статей на эту тему нет за пределами самых азов почему-то :(

Там колориметрия выходит совершенно неверная.
У меня результаты странные -- цветовая температура врать начала здорово. Может быть, потому что мишень я снимал не при D65 а при двух вспышках с рассеивателями, что, по идее, 5500K а не нужные примерно 6500K... В общем, пока отказался от.

Надо, надо им на форум писать, не зря же бета-версия. Но всем лень!

Не в лени дело, а в

Не в лени дело, а в бессмысленности. Проблема - в подходе, принятом Adobe. Использование ProPhoto и баланса белого, основанного на преобразованиях пространств по модели ICC, необратимо ведёт к нестабильности цвета. Профилировать же камеры по цвету на основе скромного набора из 24 матовых патчей с ограниченным гамутом, полностью укладывающимся в NTSC, и потом выкручивать оттуда ProPhoto - малоприемлимый подход.

Использование ProPhoto и

Использование ProPhoto и баланса белого, основанного на преобразованиях пространств по модели ICC, необратимо ведёт к нестабильности цвета.
Вот [мне] хотелось бы понять -- почему. Для этого нужна статья с теорией :)

Да нет, с теорией какие

Да нет, с теорией какие преобразования там могут применяться и с указанием, какие из них инъективны, а какие -- сюръективны.

Да блин, все же просто. Вот

Да блин, все же просто.

Вот есть у нас картинка какая-то, реальный охват ее - какой-то (не больше охвата камеры). Дальше мы ее преобразовали в ProPhoto, пока еще все отлично (кроме точности, ну да на точность наплюем пока). Дальше мы делаем операцию ProPhoto RGB->HSB->операции в HSB->ProPhoto RGB. Все опять отлично по меньшей мере теоретически.

Ну а потом мы эту картинку выводим (конвертируем в sRGB/Adobe, просто выводим на принтер, ну мало ли). И с удивлением обнаруживаем, что на пред-предыдущем этапе (редактирование в HSB) мы получили цвета
* либо далеко за охватом исходной камеры, но хотя бы теоретически видимые человеком
* либо вообще за пределами добра и зла, точнее за пределами того, что человек видит (в теории).

Дальше есть варианты gamut mapping
а) все out of gamut двигаем на край gamut, все что внутри - не трогаем. Рискуя тем, что разные цвета станут одинаковыми (или просто нарушатся тоновые/цветовые соотношения). Это, как я понимаю, Relative Colormetric
б) делаем gamut mapping для всего, сдвигая и внутригамутные цвета тоже (Perceptual)

А теперь вопросы
1) А какой gamut mapping у ACR когда выходное пространство - не профото?
2) А какой вообще gamut mapping у большинства фотографов (и думали ли они про это вообще когда нибудь)
3) Нахрена вообще ProPhoto в этом месте? И нахрена кодак его придумал, убить бы....

Заметим, что мы не делали "ничего такого". Просто подвигали какие-то цвета на HSB (не залезая на край охвата, простые такие цвета, ненасыщенные), потом нам этот профиль экстраполировали на весь охват, потом там яркие цвета куда-то попали, потом их подвигали и так далеее...

В общем, вполне ясно,

В общем, вполне ясно, да.
Встаёт вопрос -- неужели в Адобе такие идиоты, с Томасом Ноллом во главе?
И второй вопрос -- если они там такие идиоты, то почему таки нет конвертера удобнее ACR'а в использовании? Что ни пробовал -- всё НЕУДОБНЕЙ, а принципиальной разницы в качестве не вижу...

А мак есть? Я тут знакомому

А мак есть?

Я тут знакомому конвертировал для панорамы RPP. Разница в качестве - ЕСТЬ, причем это не мои слова.

Ну и таки про удобство -- та

Ну и таки про удобство -- та же RawTherpee содержит отличные идеи, но вот отстуствие "Alt+exposure" и "Alt+recovery" для меня убивает всё удобство и все идеи, например :(

Pages