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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Gigapan Epic Pro - $895.
• Meade ETX-80AT-TC - $299. В три раза дешевле.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

8x10 Inch: ... Drum scanned (Dainippon screen SG 608) at 745 dpi which results in 8874 x 7229 pixels.

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

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

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

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

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

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

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

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

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

По сложившейся традиции, анонсирую тут новую 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 задников могут и пару гигабайт памяти докупить.

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

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

• Взял в одну руку три флэшки, медленные и быстрые: 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.

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

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

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

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

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

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

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

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

Тут померял (методически, возможно, неидеально) и офигел.

Постановка:

• Затемненная (слегка) комната)
• На столе - монитор.
• На тот же стол кладем Oly E-P2 со снятым объективом, так чтобы в отражении на матрице был виден монитор.
• И меряем спотметром.

• Монитор сзади
• Камеру держим в руках, ловя отражение монитора под углом, близким к прямому (т.е. монитор работает "как объектив" в смысле положения источника света)
• Опять меряем яркость.

Получается порядка 25%

Навеяно вот этим вот обсуждением, пожалуй запишу.

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

К примеру, Monaco Profiler с удовольствием сделает вам цветовой профиль с таблицами 33x33x33. То бишь почти 108 тысяч коэффициентов (+тоновые кривые). Круто, да.

А на вход ему при этом подадут ну, скажем, 1728 патчей (12 в кубе). Так как жрет он не спектральные данные, а простой рабоче-крестьянский XYZ, то это будет примерно 5200 значений.

Допустим, даже, мы введем еще ограничений: на гладкость интеполяционных функций, на знак третьей производной, ну придумаем еще. Ну еще десяток ограничений на точку (три на одно входное значение). Ну значит будет порядка 20 тыс. входных параметров.

Сколько можно построить интерполяционных функций, которые бы точно проходили через входные данные (dE -- нулевая) с учетом прочих ограничений? Имея в руках сотню тысяч параметров и 20 тысяч ограничений? Согласно общей теории всего - чуть меньше, чем дохрена. И они могут очень сильно отличаться в тех точках, где нет эксперимента. Но профиль - это модель (цветовоспроизведения) устройства, не может быть много сильно разных моделей.

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

Я клоню к тому, что вижу в имеющемся подходе тупик: маленькие профили (с маленькой таблицей) дают плохую точность, это все знают из опыта. Большие профили (33x33x33) - основаны на выдуманных данных, а снабдить их невыдуманными данными, скажем промерять не пару тысяч патчей, а тысяч тридцать - невозможно на практике, слишком трудоемко.

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

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