Skip to Content

Обработка RAW

В очередной раз о линейности RAW

Попался мне в руки даташит на АЦП AD9974, это тот, который ставят в Nikon D3 и вроде бы в D3s - тоже.

А там - вот такая вот картинка:

Это - Integral Nonlinearity т.е. максимальное отклонение от линейности в битах (LSB - Least Significant Bit).

И думаю я следующую мысль:

  1. Уровень 3-4k - это самая что ни есть "5-я зона по Адамсу" т.е. важные полутона.
  2. Уровень сигнала там, соответственно, 11.5-12 бит.
  3. Отклонение от линейности - до 7 бит.
  4. Получается, что "достоверных бит" - 4.5-5 т.е. отклонение от линейности 3-5%.
3-5% - это - довольно много, глаз заметит даже без увеличения контраста. И это - без нелинейности сенсора (не знаю, есть ли она, какая она и т.п.).

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

Вполне вероятно, конечно, что такая нелинейность возникает только при выкрученных на максимум усилителях, а на низких ISO (и коэффициентах усиления) все лучше.

Особого веселья добавляет 6-я страница, где таблица спецификаций, в максимальная INL - 15 бит. Это у 14-битного АЦП.

Update: прочистили моск. Это не битов ошибки, а ошибка, считая в единицах младших разрядов. Т.е. 8 и 15, 3 и 4 бита соответственно. А не 8. Отлегло.

О синем цвете и зеленых каналах: Panasonic G3

Я уже про это писал, но во-первых чисто умозрительно (на пальцах), а во-вторых не полностью верно, пришло время вернуться.

Чтобы не троллить больше владельцев Sony A77, возьмем для примера Panasonic G3. А именно, возьмем с imaging resource снимки мишени CoolorChecker и постараемся разобраться, что же камера с них выдает.

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

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

Для начала, сформулируем тезисы, которые ниже я пытаюсь проиллюстрировать.

Суть проблемы (профилирования)

Проблему я формулирую так:

  • Все поля мишени с точки зрения программы профилирования - равнозначны. В лучшем случае профилировщик учтет дисперсию сигнала в данном поле, да и то, скорее интегральную, а не поканальную.
  • С точки же зрения камеры, величина ошибки по полям и по каналам - очень разная. Тут и шум и разная чувствительность каналов и ступенчатость восприятия, особенно на высоких ISO.
Естественно, проблема касается не только профилирования, но и вообще захвата слабых каналов. Посмотрим с этой точки зрения на изучаемый панасоник.

О высоких ISO и о дырках: Sony A77

Возьмем, к примеру, Sony A77. Самой камеры у меня нету, поэтому возьмем самплы с Imaging Resource. Я взял те, где есть большое серое поле (как на картинке в заставке этого поста) для разных ISO: 50, 100, 800, 1600, 6400, 16000.

А дальше выберем кусочек на сером поле размером, скажем, 450x200 пикселов и построим по нему гистограмму. Прямо вот по RAW-данным.

И вот что получается:

О линейности RAW: Nikon D3, D7000

Нас спрашивают: "а что с RAW-кривыми в D3 и D7000?"

Отвечаем:

  • У D3 в 12/14-битном lossy режиме кривая в точности как у D700. Включая и артефакты, когда два разных входных значения дают одно выходное.
  • У D7000 в 12/14-битном lossy RAW кривая в точности как у D5000/D51000. До копейки.
В lossless-сжатии никакой кривой нет.

О линейности RAW: Nikon D700

Продолжаем копаться во внутренностях алгоритмов цифровых фотоаппаратов. На очереди Nikon D700.

Благодаря любезности Ольги Бухваловой, у меня в руках оказалось 12 самплов RAW с этой камеры, один и тот же сюжет снятый:

  • в двух режимах битности (12 и 14);
  • в трех режимах сжатия: нежатый, lossless и "normal";
  • с двумя разными тоновыми кривыми

Вытащив оттуда кривые, применяемые при распаковке RAW могу сказать следущее:

  • Тоновая кривая на вид RAW-кривой не влияет, вероятно накладывается позже.
  • RAW-кривая есть только при "normal"-компрессии, во всех остальных случаях RAW "честный", просто или вовсе нежатый, или жатый lossless jpeg (то же сжатие без потерь используется в DNG, Canon CR2 и много где еще)

При этом тоновая кривая, сохраняя очевидный принцип (сжатие светов), в деталях заметно отличается о того, что используется в Nikon D5000/D5100.

О линейности RAW: Nikon D5x00

Модифицировал свой тул для дампа RAW-кривых, так что он стал понимать не только кривые из EXIF (как у Sony), но и кривые, хранящиеся вместе с RAW-данными. И смотрю, значит, в Nikon D5xx.

Вот какие большие огурцы продают теперь в магазинах какая кривая накладывается на распакованное из RAW в Nikon D5000 (после чего данные становятся линейными, а до того они были пожаты обратной кривой):

Масштаб осей - логарифмический, 1 клеточка по вертикальной оси - стоп, отчего тонкие особенности загиба не видны, а общая картина видна прекрасно:

  • Всего разных RAW-значений - 769 (минимум кривой - 0, максимум 768). То есть больше градаций просто не будет никогда. Это "9.6 бит".
  • На выходе: 12 линейных бит, диапазон 0-4095
  • Число градаций в верхних 5 стопах: 229-161-116-86-64. Что, естественно, хуже, чем у честной 12-битной камеры (2048-1024-512-256-128), но для самых важных 4-5-го стопов сверху (полутона) это лучше чем было бы у линейной 10-битной (512-256-128-64-32).
  • Дальше в тени все линейно, как у "обычной" камеры без RAW-кривой.
На графике в логарифмическом масштабе видно плохо, но наклон доходит до 11 в самом верху самого верхнего стопа (распакованые значения 3687-4016), а на последних 16 строчках таблицы есть закорючка с наклоном 5. Может быть случайно так получилось :), а может быть - чтобы модуляции в самых-самых светах спасти.

Какие из этого есть следствия:

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

Рядовой Иванов, о чем вы думаете, глядя на эту кучу кирпича?

На картинке - кривая, которая применяется к RAW-данным камеры Sony NEX-C3 при их распаковке. NEX-C3 просто первая попалась под руку, в компрессированных RAW A77 или A900 совершенно такая же по смыслу кривая, немножно отличается в деталях.

После наложения этой кривой, RAW-данные становятся линейными. Соответственно, при упаковке используется обратная кривая, линейная в тенях и полутонах и загибающаяся в светах (последних 3 стопах диапазона). По сути, три верхних стопа диапазона сжали в 1 стоп сигнала.

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

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

Об академической науке

Читаю на Роеме эпический тред про РОМИП и хочу рассказать следующую историю уже про обработку фото и академическую науку.

Существует огромное количество алгоритмов демозаики. Вот несколько устаревший список. Сайт куда-то подевался, поэтому из архива, но с 2009-го появилось еще немало публикаций, поверьте (или почитайте IEEE Image Processing и подобную литературу).

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

Так я о чем, собственно? А, вот: если алгоритм получился не совсем позорным, то в разделе "сравнение", ближе к хвосту статьи, как правило публикуют сравнение: вот маяк, обработанный нашим алгоритмом, а вот маяк, обработанный стандартным AHD, LMMSE, VCD, наш найкращий!. Так парадокс в том, что "стандартный AHD" в каждой статье - свой, особенный. И "стандартный маяк обработанный стандартным алгоритмом" - соответственно, заметно отличается от статьи к статье.

При этом производители коммерческих конверторов, которые за деньги их продают, на эту тему и вовсе не парятся и используют кто AHD, а кто и вовсе bilinear interpolation для скорости. И, собственно, я согласен: типичным на сегодня 16-18Mpix демозаика нафиг не нужна при печати до A4 (а может и крупнее), не говоря о показе на 2-мегапиксельном мониторе.

LibRaw 0.14.0 (Release)

После трех месяцев разработки и тестирования вышла LibRaw 0.14.

По уже сложившейся традиции, помещу тут несколько отредактированный Changelog.

В этой версии одно принципиальное изменение, влекущее за собой множество мелких:

Разрешены повторные вызовы постобработки (LibRaw::dcraw_process) без переоткрытия файла парой вызовов open()/unpack(). При этом, постобработку можно повторять меняя любые параметры обработки (за исключением выбора кадра через shot_select).

В сочетании с повышением скорости обработки, на (очень) приличной современной машине можно получить:

  • "Почти realtime" показ изменений изображения при смене параметров RAW-конвертации в режиме половинного разрешения. На 40-мегапиксельное изображение уходит примерно 250 мсек (т.к. half-mode, то выдается 10 мегапикселей, что сильно больше любого современного монитора).
  • "Совсем realtime" показ изменений небольшого окошка (например, вокруг курсора) в полном разрешениии с настоящей демозаикой (получается 30-50 кадров/сек для окошка 450x300)
Осталось дождаться, пока это подопрут разработчики конверторов. digiKam обещал, но пока еще не сделал...

О legacy и форматах данных

Есть устоявшееся мнение, дескать обработка (изображений) в целых (16-битных) числах - это быстро, а делать то же самое в плавучке - медленно.

А я вот тут читаю ассемблер, порожденный компилятором из C-шного кода обработки изображения. Много думаю.

Имею сказать, что распространенный в настоящее время формат "16-битное целое на компонент" - это максимально неудачный способ с точки зрения эффективности обработки:

  • от малейшего чиха переполняется или превращается в тыкву обнуляется, нужно постоянно следить за диапазоном;
  • векторные (SSE,AVX) операции с этим типом - очень ограничены, да и не векторные - тоже.
В результате, сплошные мучения компилятору, а результат - медленно работает. Скажем, вот такой вот код (из dcraw), который делает преобразование по матричному профилю для 3-4 входных каналов (цветов) и трех выходных:
  1. out[0] = out[1] = out[2] = 0;
  2. for (сc=0;сc<colors;сc++) {
  3.   out[0] += out_cam[0][сc] * img[сc];
  4.   out[1] += out_cam[1][сc] * img[сc];
  5.   out[2] += out_cam[2][сc] * img[сc];
  6. }
  7. for(=0;сc<3;сc++) img[сc] = CLIP((int) out[]);
img[] - unsigned short, out[] - int, out_cam[] - float.

Смотрю на код, который порождает интеловский компилятор. Ну код, да. (три-)четыре load по 2 байта (количество loads зависит от colors /количества цветов/), дальше "вручную" выписанный dot product (нормальный, насколько это возможно), ну и обрезание до диапазона 0-65к и store.

Скорость работы этого кода - 100 мегапикселей в секунду на Sandy Bridge 4.5Ghz (в один поток, понятно что параллелится это на ура). Как-то не очень....

Да, считаем в мегапикселях т.к. в unsigned short у нас 8 байт на (4-компонентный) пиксель, а для float/int - 16 байт.

О фотографическом цвете

Вот смотрю я в новую dcraw, точнее в diff с предыдущей, и вижу там:

  1. -      pix[0] = rp[0] + ((  200*rp[1] + 22929*rp[2]) >> 14);
  2. +      pix[0] = rp[0] + ((   50*rp[1] + 22929*rp[2]) >> 14);
Это расчет красной компоненты пикселя при распаковке из Canon sRAW (YCbCr) в RGB.

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

А, да, а потом некто перестроит профили под новую формулу, а затем достанет из загашника старые DNG (где в linear-RGB все распаковано по-старому).

Так и живем.

LibRaw 0.14 Alpha

По сложившейся традиции, анонсирую тут новую major версию LibRaw, которая пока существует в альфа-варианте.

Скачать ее можно в обычном месте, почитать формальный Changelog там же, а тут хочется рассказать об изменениях человеческим языком.

До сего момента жизнь в LibRaw была устроена просто: открыл файл (LibRaw::open()), распаковал (LibRaw::unpack()), если своего постпроцессинга нет, то попользовался нашим (LibRaw::dcraw_process()). Если какие-то параметры поменялись, то все сначала, open, unpack и так далее.

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

Минус - тоже понятно какой: поменял ББ, даже в интерактивной программе и .... опять надо распаковывать RAW, а скажем в кэноновских CR2 тамошний Хаффман (lossless JPEG) устроен так, что хрен распараллелишь его распаковку. И секунда-две только на 30-мегабайтный CR2 - просто в природе вещей.

Что делаем? Правильно, меняем память на скорость.

Начиная с 0.14 байеровские данные распаковываются в один буфер, а весь постпроцессинг идет в другом. Для байеровских камер это penalty по памяти в 25% (40Mb для 20-мегапиксельной камеры), зато счастье велико есть. Для не-байеровских камер потери больше (вдвое), но там и кадры, как правило, небольшие (sRaw - 3-10 мегапикселов, фовеоны - 4Mpix), а владельцы Sigma SD1 или multi-shot задников могут и пару гигабайт памяти докупить.

О цветовом сдвиге за счет светорассеяния

А вот другой прикол на тему светорассеяния.

На картинке две серые шкалы снятые/обработанные следующим образом

  • Экспозиция - одинаковая до копейки.
  • Обработка в ACR - одинаковая до копейки же. Какой-то баланс белого не подбирался, поставил As Shot по нижнему снимку, он чуть-чуть проврался. Но баланс - одинаковый для двух кадров.
  • Нижняя снята просто при рассеянном свете из окна, а при съемке верхней в кадре был яркий объект (на 11 стопов ярче патча M), световой столик, свет с которого не попадал на шкалу
Впрочем, это он на сцене не попадал, а внутри камеры очень даже попадал.

Результат таков:

  • На нижней (без засветки) средний тон ползет чуть-чуть, от -1/-1 (a-b в Lab) на нулевом патче до -2/-7 в 14-м.
  • На верхней, с засветкой, все куда масштабнее, от -5/-5 в нулевом патче до -5/-18 в 14-м

После этого удивительные цвета на HDR-снимках уже не так удивляют.

Да, насколько я понимаю, механизм примитивен: два источника света с разной ЦТ. Просто смешиваются они не на объекте, а уже в камере.

О светорассеянии

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

Важно только, чтобы контраст сцены был более-менее контролируем, тогда получаемые данные будут интереснее.

Методика съемки

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

Под крышку поставим источник света, который не будет освещать серую карту. Я взял мусорный светостолик Hoya, можно было бы взять настольную лампу и загородить ее листом бумаги, несущественно, главное чтобы яркость была в пределах разумного.

Всю сцену (собственно, серую карту) я освещал светом из "западного окна" (дело было утром, т.е. никакого прямого солнца). На окне имеются занавески и регулируемые жалюзи, позволяющие регулировать свет в достаточном диапазоне:

  • Включенный световой столик на спотметре выглядит как 1/500-f/5.6@ISO200.
  • Соответственно, жалюзями я подобрал такие уровни освещения:
    1. Патч M цветовой шкалы: 1/6-f/5.6@ISO200. Т.е. контраст от M до столика - ~6.5 стопов.
    2. 1s-f/5.6@ISO200, контраст 9 стопов
    3. 4s-f/5.6@ISO200, 11 стопов

Дальше я поставил на штатив 5DMarkII с Цейсовским 2/100-Macro, выставил там ручную экспозицию по замеру по патчу M и сделал по паре кадров, с включенным столиком и выключенным.

О фотошопе

А вот, допустим, вы обрабатываете фотографии в Фотошопе. Цветные.

Внимание, вопрос: должны ли вы обращать внимание на установку Gray profile в Color Settings, а если да, то почему?

О Rawspeed

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

Вспомнив, как я три месяца назад брызгал слюной в направлении RawSpeed сделал svn up, чтобы убедиться, что слюна не подействовала (я в личной переписке автору тоже все рассказал).

Однако, подействовало. Внимательно я не вчитывался, но на первый взгляд все сделано очень хорошо и правильно. Если вызывающее приложение использует scaleValues(), то и прозрачно для него.

Я рад. И за RawSpeed и за использующих ее приложения.

О ДД и ББ в тенях

Предыдущая моя заметка О линейности в тенях как-то не вызвала того эффекта, который я ожидал. Давайте усугубим.

Представим себе некое серое тело разной яркости, снимаемое при некоем (примерно дневном) балансе белого на 5D Mark II.

Вот по уровню "среднесерого" имеем отклики (R-G-B) равные 435-1035-650. Применяя коэффициенты баланса белого 2.38-1-1.59 (я везде немножко округляю), получим серое в среднем тоне: 1035-1035-1035.

Теперь идем на 6 стопов в тени (у нас же камера с 12-ю стопами ДД по DXO Mark и с 9-ю стопами Tonal Range по тем же данным, можем себе позволить), снимаем то же серое тело.

За счет нелинейности стопов и разной чувствительности каналов накопленная за 6 стопов нелинейность будет разной.

Получим отсчеты R-G-B: 5.18-9.68-6.59 (это усреднено по большим плашкам).

Наложим тот же баланс белого, что и в полутонах. Получаем: 12.33-9.68-10.49. Был серый, стал "темно-розовый".

О линейности в тенях

Товарищи солдаты, о чем вы думаете, глядя на эту картинку:

Как она получена:

  • Берем серую карту, экспонируем по экспонометру.
  • Дальше начинаем крутить выдержку (сохраняя диафрагму) в сторону уменьшения, пока не упремся в 1/8000.
  • Дальше берем (усредненные) RAW-значения для выдержки, скажем, 1/4000 и делим на значения для 1/8000.
  • Повторяем для пары 1/3000-1/6000, 1/2500-1/5000 и так пока тестовый набор не кончится.
  • Ожидаем, что значения различаются ровно вдвое.

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

Механизм явления понятен, у нас не сигнал, а "сигнал+шум", базовый уровень шума (т.е. при околонулевом сигнале) в районе 4-5 единичек, вот шум то и жрет контраст. Если смотреть на значения еще ниже, то там график аккуратно стремится к единице (полному отсутствию контраста).

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

Надеваете сверху валенок! И никаких сношений!

Третий день мучаюсь со съемкой ровного поля, не такая это простая задача получить реально ровно.

Пока наилучший вариант такой:

  • Берем адаптерное кольцо Lee (или любое другое с подходящей резьбой).
  • Клеим на него кусок пенополиэтилена от коробочек от фильтров Schneider (квадратные кусочки) или Canon (круглые). Сигмовский "крупноячеистый" не подходит. Чистый, естественно.
  • Все это навинчиваем на достаточно длинный телевик (300мм в самый раз)
  • Который диафрагмируем на пару стопов от максимума. Дальше не надо, лезет мусор с матрицы, но и меньше не надо, виньетирования у телевиков как-бы нет, но несколько процентов есть.
  • Который (телевик) наводим на бесконечность.
  • Снимаем ровное поле без бликов
Удается получить 1% по центру кадра (1/4 площади) и 3% по всему полю.

Самое в этом удивительное, что если убрать последний пункт и снимать просто "пейзаж за окном", неравномерность заметно растет.

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

P.S. Астрономы с flat field не парятся, как я выяснил. Пишут "а вот белую майку на телескоп накинь и сними что-нибудь". Наверное, с совсем длинным фокусом этот номер лучше проходит.

P.P.S. Про астрономов я погорячился: http://www.astrosurf.com/comolli/flatfield2.htm

О дробных ISO у Canon 5D Mark II

До недавнего времени я считал, что у 5D Mark II "честными" являются только "целые" ISO (100,200,400 и т.д).

В свое время я поверил исследованию уровней насыщения, которые Павел Буров сделал для 40D (у Павла получилось, что нецелые ISO сделаны умножением после АЦП) и для 5D2 не переделывал.

А тут переделал. Получилось, что ситуация у 5D Mark II несколько другая:

  • Ряд 100-200-400-...3200 - "честный", уровни насыщения одинаковы до ISO3200 (около 14740 для моего экземпляра камеры). Ряд 6400-12800-25600 тоже "честный", но диапазон значений там больше, до 15349 (все диапазоны - после вычитания уровня черного, который в районе 1000, чуть больше).
  • Ряд 125-250-500...4000 - имеет такие же максимумы, как и предыдущий ряд. Каких-то еще причин подозревать "нечестность" пока не вижу.
  • Ряд 160-320-640-2500: судя по всему, получен цифровым делением результата съемки на следующем (200-400...4000) ISO на 1.25. В пользу этого максимумы, составляющие 11787 и насыщение, наступающее при одинаковой экспозиции (если ISO400 насытилась на 1/25 и почти насытилась на 1/32, то и ISO320 ведет себя ровно так же).

    5000 в этом же ряду "честная", имеет максимум в 14740.

Итого: я продолжу пользоваться "целым" рядом ISO, тем более что его достаточно для любой практической жизни.

Кроме того, есть ряд мелких замечаний:

О Равномерности

Чтобы достичь неравномерности по полю в пределах 2% пришлось:

  1. Взять средний телевик (Цейсс 100/2 макро).
  2. Закрыть его до f/8.
  3. Надеть на объектив матовую крышечку от чипсов Pringles колец Lee (белый полиэтилен).
  4. Навестись на бесконечность.
  5. Фотографировать лист белого картона.
И то, такая равномерность получилась только в центре кадра (примерно 10% по площади), если по всему, то там процентов 8 разницы.

Удивительнее всего, что первых четырех шагов - не хватает.

Кто бы мне объяснил, как без "крышечки от чипсов" можно снимать те же Колорчекеры....

P.S. Неравномерность оценивалась так: по изучаемому полю брались самплы 300x300 (это для всего кадра, для центральной части 150x150), общим числом 24, по ним считалось среднее и сравнивалось. То есть речь не о выбросах отдельных пикселов, а именно о среднем.

Update: нашел ссылку на таблицу (самому считать скучно). 8% на 100-мм - это в чистом виде удар косинусом.

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

О линейности в светах

Смотрю тут на свеженамеряные данные по линейности Canon 5D Mark II (текст пишется, в ближайшие дни будет) и думаю вот какую думу:

Максимальный уровень сигнала (на ISO100) в районе 14700. Даже если весь шум определяется исключительно фотонным шумом, среднеквадратичное отклонение будет в районе 120. А на самом деле оно и вовсе 250-260 (при измеряемой плашке 160x160 пикселов).

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

Природа обрезки принципиального значения не имеет, это может быть и переполнение пиксела и и обрезка в АЦП и обрезка после АЦП, эффект чисто "математический".

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

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

О Qt и рисовании прямоугольничков

Мой опыт с Qt достаточно своеобразен: как только я начинал лобзиком выпиливать что-то свое руками, внезапно обнаруживалось, что все украдено до нас и есть уже готовое или почти готовое решение. Из последних открытий в этом месте: QGraphicsItemGroup, подошедший мне на 98% после того, как я изготовил свое частное решение (которое, конечно, выкинул после этого).

Но вот столкнулся с задачкой, которая, вроде бы, не решена:

Дано: картинка (разноцветная), на которой рисуются прямоугольнички (selections). Чтобы они были видны на любом фоне, нужно делать XOR в каком-то виде. Или что-то подобное.

В-принципе, QPainter это все умеет, у него есть CompositionMode, где все подобные преобразования можно задать. Но:

Много неясного в странной стране

Сижу, пишу секретный варез, отлаживаюсь на попавшихся под руку кадрах с Nikon D700.

И вот у этого D700 в области довольно сильного пересвета:

  • В синем канале - насыщение, нулевая дисперсия.
  • В красном канале - можно найти места с нулевой дисперсией, хотя и трудно. И в этих местах значения красного - выше чем у синего.
  • А в зеленых каналах (которые засвечены, по идее, сильнее, ибо это выбив на облаке, дневной свет) - сигма около 50, а сами значения зеленого примерно на 200 единиц пониже чем синий канал. При этом, каналы я рассматриваю отдельно, т.е. речь не о бэндинге между зелеными каналами.

При этом на нейтральных непересвеченных объектах значения в каналах ведут себя ожидаемо: самый сильный зеленый, самый слабый - красный (на стоп слабее зеленого), синий - посередине (это горы, свет мог быть сильно синим).

О чем мы думаем, когда глядим на эту кучу кирпича видим такую хрень?

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

Да, кстати, разные поканальные максимумы могут дать интересные оттенки в пересветах. Разница, конечно, крохотная, но она есть.

LibRaw 0.13

По традиции, анонсируем LibRaw 0.13-Release.

В сравнении с бетой-1 (анонсированной ранее), случились некоторые изменения к лучшему:

  • Обновились распаковщики данных (на dcraw 9.06), отчего добавилась поддержка шести новых камер, включая Панасоники GH2 и GF2 и Sony A-580. Еще для девяти камер обновились цветовые данные.
  • Экспокоррекция со сжатием светов теперь работает просто по такой тоновой кривой, линейной внизу и корнекубичной вверху. Без всяких заумных контекстных расчетов яркости (изначально заимствованных из RawTherapee), которые подглюкивают на изображениях, сильно окрашенных в синие тона (и красные тоже, но в меньшей степени).
  • Ну и много всяких правок по мелочи.
Прошу любить и жаловаться.
Syndicate content


.