Последние 2 бита - зачем они?
Иллюстрация 1
В последнее время высказывается мнение, что 14 бит - излишество, так как в двух последних битах нет ничего, кроме шума. Никакой информации. Соображения о том, что каждая зона в 14-битной картинке содержит в 4 раза больше уровней, также не принимаются, так как оппоненты утверждают, что эти дополнительные уровни - "неправильные", ничего, кроме шума, не содержащие. Демонстрации, что дополнительные 2 бита поднимают разрешение - также игнорируются. Однако - судите сами.
Иллюстрация 2
На первой иллюстрации - результат конвертации ночного снимка Парижа (Nikon D3) с коррекцией на 12 eV перед конвертацией. Заметим, что если диапазон яркостей в сцене не столь велик, то уже после коррекции на 8-9 eV изображение часто пропадает полностью.
На второй - демонстрация гистограмм синего патча Macbeth ColorChecker. Снимки сделаны Nikon D3 на эффективной чувствительности ISO 3200. Левый патч на иллюстрации снят в режиме записи 12 бит, правый - в режиме записи 14 бит.
Иллюстрация 3
На третьей - сопоставление разрешения мишени, представляющей собой три малоконтрастные тонкие полоски (они отличаются от фона на 1/6 eV), после коррекции в конверторе на 7 eV. По сути, это воспроизведение малоконтрастных деталей в тенях.
Иллюстрация 4
И, наконец, на четвёртой и пятой - независимый эксперимент, поставленный участником форума DPReview David'ом.
В своём эксперименте он модифицировал dcraw, заполнив нулями старшие 12 бит 14-битного NEF'а, полученного из камеры Nikon D300. Иллюстрация 4 - вся сцена, иллюстрация 5 - та же сцена после усекновения 12 бит, до баланса белого и гамма-коррекций.
Иллюстрация 5
Возьмём результат Дэвида (а он, заметим, представляет собой JPEG, к тому же - уменьшенный в нецелое число раз, 2.1 по каналу, 4.2 по разрешению матрицы - что никак не улучшает наши шансы на экстракцию деталей) и подвергнем его обработке с целью выделения яркостного канала. Получим иллюстрацию 6. Обработка проводилась с применением вычислений в плавающей точке. Удалось получить не только контуры и текстуры в тенях, но и следы в среднем тоне. Тем самым, последние 2 бита содержат информацию не только о глубоких тенях.
Иллюстрация 6
Итак, можно видеть, что последние 2 бита содержат информацию, а, следовательно, и дополнительные уровни в 14-битном представлении - не все "неправильные".
Разумеется, вопрос состоит главным образом в этих "промежуточных" уровня, обеспечивающих ту самую "гладкость" изображения, о которой говорят разработчики камер. Именно они, эти уровни, и позволяют на большинстве high-end камер с 14-битными АЦП недодерживать примерно на 1.5 eV, получая качество изображения, сопоставимое с правильно экспонированными кадрами на 12-битных камерах. Или же применять более жёсткие режимы sharpening к деталям в средних тонах, не рискуя вырождением изображения. Вариантом того же является более решительный upsize и более плотный кроп. Изображение, полученное от 14-битных камер, более пластично поддаётся обработке.
Всё вышесказанное приложимо к разным моделям камер в разной степени.
Comments
Знают ли авторы, что вот тут
http://photo.stateika.net/2008/06/30/%d0%9d%d1%83%d0%b6%d0%bd%d1%8b%d0%9...
перепечатка?
Внизу, конечно, указано, что по материала libraw.su, но даже не ссылкой, а простым текстом.
Мне кажется у многих тут есть недопонимание в терминологии. Дело в отм, что ДД сенсора определяется чисто его электро-механическими, аналоговыми свойствами. Далее, этот ДД можно оцифровать с некоторой дискретностью по уровням, которая определяется разрядностью АЦП. Эта самая дискретность позволяет картинке быть "пластичной" в обработке, т.е. растягивать и сжимать зоны без потери плавности градиентов. Но одинаковый ДД оцифрованный в 12 или 14 бит останется тем же самым. Это - что касается границ ДД. Что касается промежутка - все интереснее. Не надо забывать, что сенсоры - линейные устройства, а глаз воспринимает освещенность гармонически. Это грубо говоря означает, что на десятую зону приходится половина битового пространства, на девятую - четверть, и т.д. Соответственно, в тенях мы просто не имеем достаточной цифровой информации для "вытягивания" малоконтрастных деталей. Увеличение разрядности увеличивает число уровней, с которыми мы можем работать в тенях. Что касается "честных-нечестных" битов - ничего не могу сказать, все зависит от честности производителя сенсора - сколько шума он давит аналоговым способом и сколько цифровым (до записи RAW) - на их совести.
> а десятую зону приходится половина битового пространства
Не стал бы я зоны так однозначно к битам привязывать. В большинстве случаев десятая зона в raw обрезана, да и полторы-две следующих - тоже.
> Но одинаковый ДД оцифрованный в 12 или 14 бит останется тем же самым.
Как минимум, в тенях это не совсем так, точность отсечки повышается с ростом точности оцифровки.
Я не понимаю, о чем Вы говорите. Что такое отсечка в RAW? Заметьте, про RAW я даже не упоминал, я оворил про АЦП. В АЦП может быть ограничение по максимальному уровню сигнала (насыщения мы избегаем правильной экспозицией), минимальный сигнал определяется тепловым шумом (возможно есть некий выставленный порог срабатывания) и между этими двумя пределами - все линейно. Что пишется при этом в RAW я не знаю, а кто знает - не скажет. Скорее всего, однако, "обрезания", Вами упомянутые, происходят в процессе обработки RAW, не верю я, что простой линейный АЦП они станут программировать какими-то кривыми на уровне сенсора.
Кстати, если кто пользовался замечательной софтиной LightZone мог заметить, что при импорте RAW она вешает (в принципе отключаемый) тональный фильтр довольно сложной конструкции. Строит она его из EXIF. Если RAW начать преобразовывать не отключая этот фильтр, то все коррекции вносятся поверх этой тональной кривой. ARC об этом например молчит и привести файл к изначалному, "сырому" виду не позволяет.
ARC об этом например молчит и привести файл к изначалному, "сырому" виду не позволяет.
Уже не так. DNG Profile Editor позволяет сделать профиль для ACR с любой тоновой кривой. В том числе -- и с абсолютно линейной.
Кстати, было бы интересно услышать мнение авторов сайта об этом новом инструменте.
Тоновая кривая - это часть проблемы. Есть еще, например, primaries камеры (а если совсем нормально - цветовой профиль)
Там настраивается всё, посмотри. Правда, primaries камеры -- не прямо, но всё же.
Впрочем, есть описание формата профиля (в DNG 1.2), так что наверняка и их можно, но уже не этим инструментом.
А ещё он строит профиль по color checker'у моментально и честно (используя 20 переменных, а не 6 как все старые скрипты).
Да, строит профили по ColorCheker, и я посмотрел эти профили. Там колориметрия выходит совершенно неверная.
Подробностей бы технических...
Очень интересно, как оно всё внутри устроено именно с точки зрения RAW.
Вообще никаких статей на эту тему нет за пределами самых азов почему-то :(
Там колориметрия выходит совершенно неверная.
У меня результаты странные -- цветовая температура врать начала здорово. Может быть, потому что мишень я снимал не при D65 а при двух вспышках с рассеивателями, что, по идее, 5500K а не нужные примерно 6500K... В общем, пока отказался от.
Надо, надо им на форум писать, не зря же бета-версия. Но всем лень!
Не в лени дело, а в бессмысленности. Проблема - в подходе, принятом Adobe. Использование ProPhoto и баланса белого, основанного на преобразованиях пространств по модели ICC, необратимо ведёт к нестабильности цвета. Профилировать же камеры по цвету на основе скромного набора из 24 матовых патчей с ограниченным гамутом, полностью укладывающимся в NTSC, и потом выкручивать оттуда ProPhoto - малоприемлимый подход.
Использование ProPhoto и баланса белого, основанного на преобразованиях пространств по модели ICC, необратимо ведёт к нестабильности цвета.
Вот [мне] хотелось бы понять -- почему. Для этого нужна статья с теорией :)
Статья с теорией инъективных и сюръективных отображений? Суть-то именно в этом.
Да нет, с теорией какие преобразования там могут применяться и с указанием, какие из них инъективны, а какие -- сюръективны.
Ну, вот, для начала. Мы имеем определение красного, зелёного и синего по ColorChecker'у. Вот они в ProPhoto RGB, XYZ и Lab:
Красный (C3)
(120.516, 56.396, 45.060); (21.730946, 12.183037, 3.644387); (41.506, 56.409, 28.453)
Зелёный (B3)
(85.578, 123.422, 68.697); (15.134044, 23.317943, 7.785330); (55.398, -38.042, 32.053)
Синий (A3)
(56.662, 50.091, 119.735); (6.847261, 5.727165, 21.163560); (28.713, 14.324, -49.976)
Если Вы построите на этих цветностях цветовое пространство, гамут его будет сильно меньше ProPhoto. Тут сразу видно, что ни одна из координат не достигает и половины от 255 по сновному красителю, да к ней ещё и другие цвета примешаны, что снижает насыщенность далее.
Если Вы прочтёте RGGB значения из raw, получаемые при правильной репродукции (экспозиция зелёного в патче A4 эквивалентна 247 в пространстве с гаммой 2.2) серого клина в нижнем ряду при применении баланса белого по патчу В4 (Нейтральный 8), то увидите, насколько же приходится растаскивать цветовое пространство, чтобы получить из него ProPhoto. Для разных 14-битных камер это число варьируется от 4 до 8 раз. О 12-битных даже говорить скушно.
Да блин, все же просто.
Вот есть у нас картинка какая-то, реальный охват ее - какой-то (не больше охвата камеры). Дальше мы ее преобразовали в 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 (не залезая на край охвата, простые такие цвета, ненасыщенные), потом нам этот профиль экстраполировали на весь охват, потом там яркие цвета куда-то попали, потом их подвигали и так далеее...
А что тут не понятного? Кодак разработал для свох CMOS и СCD сенсоров цветовой стандарт sRGB Color Space Profile - sRGB IEC61966-2.1, используя в своей фототехнике и принтарах. И все бренды производители Leica, Hasselblad и др. покупающие у них сенсоры используют sRGB IEC61966-2.1.
Adobe в своих продуктах предлагает использовать sRGB Adobe, а Corel в своих по умолчанию ставит CMYK, и всё ради того чтобы не платить Кодак.
Суть проблемы исключительно в конвертации цветовых схем, не говоря уже о битности.
Выход очень простой - единая цветовая схема в фоторедакторе, на мониторе, и принтере.
По своему орыту могу сказать, для фото идеально подходит Kodak ProPhoto sRGB Color Space Profile, для "глянцевого грамура" только режущий глаз CMYK, а для видео конечно NTSC.
В общем, вполне ясно, да.
Встаёт вопрос -- неужели в Адобе такие идиоты, с Томасом Ноллом во главе?
И второй вопрос -- если они там такие идиоты, то почему таки нет конвертера удобнее ACR'а в использовании? Что ни пробовал -- всё НЕУДОБНЕЙ, а принципиальной разницы в качестве не вижу...
И второй ответ (на первый вопрос, про идиотов)
"дура, дура, а десятку в день имею...."
Оно как-то работает. 95% пользователей не видят разницы, еще 4% увидели бы ее, но негде посмотреть.
В фотошопе много лет не работал движок гамма в диалоге Level (давал жуткую постеризацию даже в 16 битах) - и ничего, не разорились.
А мак есть?
Я тут знакомому конвертировал для панорамы RPP. Разница в качестве - ЕСТЬ, причем это не мои слова.
Ну и таки про удобство -- та же RawTherpee содержит отличные идеи, но вот отстуствие "Alt+exposure" и "Alt+recovery" для меня убивает всё удобство и все идеи, например :(
Ну а я и слов таких не знаю :) Хотя даже книжку про ACR читал, но давно все забыл.
Это регулировка exposure и highlight recovery с ПОКАЗОМ вживую того, где какой канал выбит/залечен. Очень удобно, удобнее показа пересветов/недосветов на живой (незамаскированной) картинке и, тем более, гистограммы. Мелочь, но помогает жутко.
А ты чем пользуешься?
Для сколько-нибудь ответственной работы использую RPP. А там реалтайма и вовсе нету....
Но как тогда?!
Э, ну я же вижу на гистограмме насколько нужно подвинуть движок (гистограмма по куску - доступна). Если не уверен - Command-R, которая покажет угадал ли.
А в ~90% случаев просто подходят настройки от предыдущей картинки и делать ничего вообще не надо.
Это место действительно сделано у Андрея неудобно.
Да, RPP я не пробовал. Потому что мака нет. Ни у меня ни в ближайшем окружении.
Возвращаясь к исходному вопросу - как посмотреть (!) тоновую кривую, которая используется до всех редактирований?
Потому как линейная - это все хорошо, только не нужно, а строить изменения относительно неизвестной кривой - тоже как-то глупо...
Вообще, не смотря на beta-статус у DNG Profile Editor'а нефиговая документация уже есть.
http://labs.adobe.com/wiki/index.php/DNG_Profiles: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 1.2, но его я тоже не читал пока -- завал на работе.
И, да, профили, идущие в комплекте с ACR, тоже в этом формате (они его просто открыли).
Но в каком-то смысле -- любой профиль есть просто сохранение настроек конвертера в стандартизованном формате.
Ты плохо читал документацию. Это именно профиль в терминах спеков DNG. И там в FAQ'е шесть раз подчёркнуто, что это вовсе не ICC, а именно спец-построение для конверсии. И там доступны настройки (color table) которых НЕТ в настройках конвертера через его GUI.
Что где меняется -- я, если честно, пока не исследовал, ограничился построением обоих таблиц (обрати внимание, что там можно редактировать отдельно обе части DNG-профиля -- и для A и для D65) по XRite color Checker, вместо скриптов. Ну и почитал документацию.
Ну я же смотрю одним глазом на тоновую кривую, а другим - на изменения изображения. И вижу, что они не согласуются.
Вот, например, вопрос - там где тоновая кривая, там что по осям?
А профиль в "спеках DNG" - это ты про какой набор тегов? И где там теги с цветовыми таблицами?
(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) Только по первому пункту - я ставлю галку "показать базовую" и выбираю эту базовую из "defaults" (степенная кривая) и "Linear".
Больше вообще ничего не делаю.
И вижу, что изображение на экране не соответствует кривой.
2) Можно ли профайл эдитором редактировать ColorMatrix1/ColorMatrix2 (я такой возможности не вижу т.к. на закладке редактирование в виде HS и только для трех цветов, а их может быть и больше)?
3) Ну да, expands. Мне весь их шестой раздел кажется ересью, ну да я им не судья.
Ну да, expands. Мне весь их шестой раздел кажется ересью, ну да я им не судья.
Ну, вот это я и имел ввиду там раньше, говоря об алгоритмах и их [не]оптимальности :)
1. У меня -- меняется. Linear -- типичное без гаммы блёкло-тёмное изображение, Base Profile и Camera RAW Defaults -- одинаковая степенная и картинка поживее.
Повторил Base Profile пользовательской кривой, выбрал Linar в качестве base -- результат тот же, что "наоборот"...
2. Я так понимаю, дальше ты можешь всё тонко настраивать любым числом цветов на первой закладке... Но я, повторю ещё раз, не читал всей математики которую они к этому предлагают, и не знаю хватает ли трёх primary или действительно их должно быть больше.
Меняется, конечно.
Но тени явно меняются не так, как нарисована тоновая кривая.
Второй вопрос снимается - это ProfileLookTableData - "starting point for user adjustment". Я же говорю, это все настройки конвертора (пусть часть их и не видна в гуе).
Я понимаю, что приложений с DNG 1.2 еще толком нету в природе, но когда будут (не адобовские) - попробуй скормить им результаты редактирования, скорее всего удивишься.
Я так понимаю, что в DNG 1.2 описан алгоритм использования этих настроек (как был описан алгоритм использования ColorMatix в 1.1), и если не-адобовское приложение будет селдовать тут стандарту, то результаты должны получиться консистентные. На сколько эти алгоритмы адекватные и нельзя ли сделать лучше -- я не компетентен, не удивлюсь, если не очень адекватные и можно таки сделать.
А про настройки -- так ВСЁ -- это настройки конвертера. Точно так же как ICC -- настройки конвертера из RGB в RGB (грубо говоря). И если кто-то будет использовать ICC, не реализуя (или реализуя неверно) алгоритмы, описанные в стандарте, то результаты тоже будут наверняка удивительные.
Описан, блин, алгоритм. Вот есть теги AsShotICCProfile/CurrentICCProfile, отлично.
Но почему они не используются в 6-м разделе?
Они, конечно, неплохо описали некий метод (алгоритм задокументировали, не иначе), только это ересь, начиная с RIMM
Авторы, между прочим, очень отзывчивы в соотв. разделе форума :)
Адобовского.
Можно пойти и спросить.
И если это ересь -- то как работает ACR? Или описали не то, что реально используют, диверсия такая? спеку-то авторы ACR пишут...
Не, оно естественно будет работать, RGBtoXYZ и обратно никто не отменял.
Вопрос в качестве результата.
Ересь это по многим причинам
а) вовсе не нужна матричная математика для баланса белого (достаточно диагональной матрицы). Результат оверкилла - пролезающий из слабых каналов шум
б) вовсе не нужен ProPhoto RGB, особенно при работе в целых числах
в) делать из ProPhoto HSB, потом редактировать в нем, потом обратно -- а что делать, когда мы попадаем в несуществующий цвет после редактирования?
Ну а лечить адобу голову про все это - мне это не нужно.
> Что такое отсечка в 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
Сенсор - не только волна, но и частица. Я к тому, что фотонная емкость там вполне конечна и само количество уровней, которые он может зарегистрировать (до всякого АЦП) - тоже конечно. У Кларка были подсчеты, там порядок величины - несколько десятков тысяч, не так и много.
Другими словами, растить разрядность АЦП за 16 бит не имеет смысла.
А про дискретность и плавность вы все правильно говорите - 14-битная камера допускает на полтора-два стопа недодержки среднего тона (много выше всех шумов) больше, чем 12-битная.
Дискретность аналогового сигнала пока что за рамками обсуждения, хотя мысль интересная. С другой стороны, никто не станет отрицать, что уровень шума всегда будет больше дискретизации по фотонам. Вопрос стОит ли регистрировать шум с точностью 16 или более бит довольно прозрачен. Когда я занимался ядерной физикой помнится АЦП регистраторов были 22-х битовыми и дипломы с диссертациями писались в частности о том, как выделять полезный сигнал из-под уровня шумов. Так что, запас карман не тянет! :)
Выделять можно, если мы знаем характер шума (скажем, бэндинг подавлять вполне можно).
Но если посмотреть соседнюю статью про засветку то видно, что проблемы с динамическим диапазоном есть и у оптики, например. Засветка, конечно, поднимет нам сигнал повыше, была бы она равномерной и регулируемой - эффект был бы просто полезным. А так - он вредный и тоже ограничивает нам счастье.
.. таки я неправ. На десятую зону приходится половина не битового пространства, а числового. Т.е. при оцифровке 10-ти битовым АЦП - ровно один бит. Однако, количество различимых (цифровфм способом) уровней в зоне - это и есть числовое пространство, ширина которого значима при разделении деталей и критична, когда мы пытаемся различить детали в тени.