Фото

Об артефактах демозаики

Один из соседних домов - это старая советская панельная 14-этажка, отделанная мелкой (кафельной?) плиткой, буквально квадратики 3x3 сантиметра или около того. Серая плитка на сером цементе. Ну, многие видели.

Снимаю с рук, 1/800s, камера без антиалиасинговых фильров (и цветового алиасинга на самом деле нет, про камеру ниже), засовываю в Adobe Camera Raw 6.6 и получаю вот такую вот пятнистую прелесть (100% crop):

Черные точки там в натуре есть, я в бинокль посмотрел. Не мыли его много лет.

Оттенок поправлен настолько, насколько конвертор это может: оба движка ББ выкручены максимально влево, дальше никак.

А на самом деле снимок выглядит вот так:

В очередной раз о линейности 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. Отлегло.

Про Nikon D4 (и EOS 1dx)

Что, гонка мегапикселей все?

Как-то странно видеть micro-4/3 на 16Mpix (с вполне приемлемым качеством картинки при нормальном освещении) и вчетверо больший по площади сенсор на те же 16.

По мне, так 36-40 на FF были бы в самый раз.... Ну и биннинг до 10 при ISO800 и выше.

О синем цвете и зеленых каналах: 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-данным.

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

О моторизованных панорамах

Вот смотрю в веб:

В комплекте телескопа при этом, помимо моторизованной головы, имеется собственно телескоп, штатив и рюкзак для ношения этого. И штатив там, очевидно, достаточный для 400-мм телескопа.

Ну ладно, допустим голова и штатив у этого телескопа - слабые и тяжелую камеру не вынесут. Но Epic 100, который для P&S, тоже стоит $495. Без штатива. А для более тяжелого и у Meade есть вариант: штатив и Meade GOTO system за $599, до 30 фунтов можно вешать.

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

Не, я не стал фанатом гигапиксельных панорам, просто мучает вопрос третью неделю.

О линейности 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-мегапиксельном мониторе.

Фотобарахолка в RSS

В очередной раз починил всегдашнюю жертву апгрейда, фотобарахолку в RSS.

Раз уж она попалась мне под руку, то добавил еще один фид для любителей micro-4/3: Поиск Olympus/Panasonic/Lumix.

Остальные фиды перечислены в этом посте, не буду повторяться.

Если есть что добавить для Oly/Panas, пишите, сейчас там банально Olympus/Panasonic/Lumix в английском и русском написаниях. Естественно, для Oly туда будут попадать и пленочные камеры (а для Панаса - видео и телевизоры), но в этом потоке уже легче ловить.

P.S. Если кому нужен E-P2 - пишите, я свой хочу апгрейдить :)

О Betterscanning

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

Сегодня до меня доехали рамки для Epson V700/750 имени Betterscaning.com и я их немного потестировал.

Имею сказать:

  1. Они действительно нереально удобны. Всё предыдущее что я пробовал (родные от Epson разных моделей, родные от Nikon-9000) - не идет ни в какое сравнение. С перегородками (которые T-lock) совсем удобно: просто суешь пленку и прижимаешь этими T-locks в нужных местах. Никаких вылезающих краев и прочего безумия.

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

    Короче, лучшие 150 баксов месяца.

  2. Три кадра 6x7 лезут в холдер, но, увы, не влезают в окно сканирования. Т.е. можно резать 6x7 по три (для сливера), а не по два. Но сканировать такое, увы, придется в два приема.
  3. Глубина резкости у сканера оказалась миллиметра полтора. То есть та точность подгонки, что у этих штук есть (~0.2мм, полный оборот ножки - 0.8) - избыточна.
  4. Чуда не случилось, 9000-й никон по проработке деталей не догнали и изрядно не догнали. Но A3 с 6x7 вполне можно печатать.
Если будете заказывать, учтите мой опыт:

О методологии

На сайте LL креативное сравнение 80Mpix IQ180 и форматки 8x10, которое меня просто порадовало.

8x10 Inch: ... Drum scanned (Dainippon screen SG 608) at 745 dpi which results in 8874 x 7229 pixels.
И это в то время, когда корифеи спорят, нужно ли сканировать форматный слайд на 8000dpi или хватит 3-4 тысяч (кроме foto.ru есть еще смысл на mformate поискать сломаных копий). А, да, и не надо ли выводить на струйник на 720 dpi вместо 360, это что, для 745dpi сканирования будем печатать 8x10 "контактом"?

Результат получился ожидаемый: Если отсканировать пленку с разрешением 64-Mpix (не вдавался, сколько пикселей в мегапикселе, считаю что 106), то по 100%-м кропам она сольет 80-Mpix заднику без AA-фильтра. Еще бы, вы самплите один цифровой сенсор (пленку) другим, не попадая в шаг (которого, собственно, у пленки и нет), понятно что будет размытие. Помимо размытия, будет еще aliasing ("наведенное зерно") с размером элемента порядка единиц пикселов.

Вместе с тем, интересно было бы переделать нормально: со сканированием в 4000-8000 и уменьшением в 6-12 раз. Я предвижу совершенно другую картинку....

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 входных каналов (цветов) и трех выходных:
out[0] = out[1] = out[2] = 0;
for (сc=0;сc<colors;сc++) {
  out[0] += out_cam[0][сc] * img[сc];
  out[1] += out_cam[1][сc] * img[сc];
  out[2] += out_cam[2][сc] * img[сc];
}
for(cс=0;сc<3;сc++) img[сc] = CLIP((int) out[cс]);
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 с предыдущей, и вижу там:

-      pix[0] = rp[0] + ((  200*rp[1] + 22929*rp[2]) >> 14);
+      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 задников могут и пару гигабайт памяти докупить.

О фотобарахолке в RSS

Имею повод сообщить, что трансляция барахолки foto.ru в RSS в очередной раз починена. В ленту опять попадают начала текстов сообщений, а не только заголовки, как это было последние несколько недель.

Увы, но при минимальной смене дизайна мне приходится править скрипт импорта.

Более длинное описание сервиса и адреса всех имеющихся фидов тут: О барахолке foto.ru в RSS

О выравнивании

Подниму, пожалуй, из комментариев тему о выравнивании разделов на флэшках.

Имею сказать:

  • Взял в одну руку три флэшки, медленные и быстрые: Transcend 120x (8Gb), Transcend 300x UDMA (16Gb), Sandisk Extreme 60Mb/s UDMA (16Gb). Все три - compact flash, скорость на SD меня пока мало волнует.
  • Во вторую руку взял камеру (5D MkII) и читалку карточек памяти. Читалка несовременная, какая-то левая, USB2.
  • В третью руку ногу взял Paragon Alignment Tool 3.0, а в еще одну руку ногу - Crystal Disk Mark 3.
  • И все это совокупил, благо на эксперимент надо ну минут 10.
Получается

Pages

Subscribe to Фото