Фото

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

• В горизонтальной плоскости крутим вокруг нодальной точки.
• В вертикальной плоскости делаем сдвиг с помощью шифт-объектива (3 кадра).

Понятно, что можно склеить тройки, обозвать все это кадром 58x24 (или 44x36) и дальше клеить обычную однорядку, но это же ручной работы сильно больше.....

Update. Что-то ответы, которые пишут - какие-то разочаровывающие. Так недолго и мизантропом стать. Разжую помельче:

Поправил сегодня серьезную багу в LibRaw, что заставило меня призадуматься о жизни. Если в подробностях, то:

• У некоторых мыльниц (ряд моделей Nikon, Pentax, Samsung, Casio) режим RAW включается через инженерное (скрытое) меню.
• В этих RAW нет никаких метаданных, а только данные с сенсора, обычно просто дамп байтов в каком-то некомпрессированном формате.
• Метаданные сохраняются в JPEG-файле с обычным снимком, который записывается рядом (с тем же именем файла и другим расширением или же с другим номером файла).
• В dcraw, а оттуда и в LibRaw есть поддержка этого составного формата: вычисляется имя файла, открывается, загружается EXIF.

И вот эта вот поддержка - категорически не работала. Даже хуже: наличие JPEG с метаданными приводило к неправильной распаковке собственно RAW, а отсутствие этого файла - к падениям.

Эта ошибка была начиная с LibRaw 0.0 и до сегодняшнего дня. И ни одна зараза - не заметила. Несмотря на то, что LibRaw уже несколько месяцев используется в digiKam и Krita, а у этих программ должны быть десятки тысяч пользователей, если не больше.

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

Естественно, этот режим работы может быть интересен только тем, кто сам пишет RAW-конверторы или анализаторы RAW или подобные вещи. Ну и любопытствующим, ибо поставляемый в составе библиотеки пример unprocessed_raw (в версиях под Win32/Mac/Linux он лежит скомпилированным и готовым к использованию) способен эту опцию включить и показать ваши данные прямо как они из файла раскодированы.

Тоновая кривая есть не во всех камерах и форматах данных, среди распространенных это Nikon (compresssed NEF) и Sony A700/A900 (8-битный cRAW)

Достаточно очевидно, что от тоновой кривой нет вреда (или практически нет вреда) если выходное пространство шире чем входное, скажем из 8 бит делаем 12 (как оно у Sony). А вот если входное и выходное пространство имеют одинаковую битность, а кривая отлична от линейной, то мы обязательно потеряем градации. Такое должно случаться, насколько я понимаю, с 12-битными NEF-ами, было бы прикольно, если бы кто-то проверил.

Аналогично предыдущему анонсу просьба: если unprocessed_raw -N падает на каком-то файле, то я хочу этот файл пощупать.

Я точно знаю, что есть люди, читающие анонсы LibRaw именно здесь, остальным придется потерпеть.

В третьей альфе LibRaw 0.7.0 случились две группы существенных идеологических изменений и одна группа несущественных:

1. Данные для камер FujiFilm распаковываются без поворота на 45 градусов. Это открывает путь к легкому получению 12-мегапиксельных картинок с Fuji S5Pro и прочим подобным радостям. При этом, горизонтальное разрешение должно быть заметно лучше, чем у 6-мегапиксельных, выдаваемых dcraw и всеми использующими этот код.
   Посмотреть на реальные RAW-данные Fuji можно с помощью примера unprocessed_raw, очень поучительно (чтобы извлечь второй кадр, используйте ключ -s 1).
2. Не менее сильно поработали над PhaseOne:
   • Придуман и для PhaseOne реализован режим (не)фильтрации данных, отключающий тоновую кривую для RAW (более raw-данных вы еще не видели!). Идея мне настолько понравилась, что в следующих версиях тоновую кривую можно будет отключить для всех случаев, когда она есть (Nikon NEF, Adobe DNG, далее везде).
   • Рассчитанные камерой уровни черного доступны в метаданных
   • Исправлена ошибка расчета уровня черного, имеющаяся в dcraw (впрочем, на результат она влияет не очень сильно).
3. Ну и по мелочи: баги, ключ -s у unprocessed_raw, импортирована свежа версия dcraw.

Более подробно и более формально в changelog, скачивать с той же страницы

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

Чтобы не писать очередного update к предыдущей записи напишу я новую.

Все упражнения с поворотом, а затем с масштабированием файлов Fuji S5, которые проводятся в dcraw - они конечно интересны. Но ровно до тех пор, пока в руки не попадется "12-мегапиксельный" JPEG, который делает сама камера. Из его размеров становится очевидным, что камера делает очень просто: растягивает файл вдоль короткой стороны, отчего он из (примерно) 4300x1400 становится 4300x2800. И все, собственно.

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

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

Меж тем, Fuji - не первая компания, использующая сей нехитрый трюк. Как мне напомнили, у Nikon D1X та же фигня: пиксели прямоугольные, разрешение сенсора 4028x1324, правда камера масштабировала эту картинку в примерно 6 мегапикселей, а не в 10.5. При этом, разница горизонтального и вертикального разрешения у D1X (по DPReview) очень даже есть.

Вот пишут мне знакомые в почту, что всем российским покупателям Vuescan автор предлагает халявно проапгрейдиться по случаю появления русского перевода. Даже тем, кто стандартную версию покупал с годом апгрейдов. Я, правда, не сумел вспомнить E-mail на который свою копию регистрировал и подозреваю, что это был профуканый мой мейлбокс на rambler.ru.

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

Если рассматривать черную рамку у 5D Mark II, взяв кадры с разных камер, то становится очевидно, что матрицы делаются вручную (китайские крестьяне в своих фанзах?). Вот, собственно, пример: два кадра (сложены слоями в фотошопе со смещением), оба ISO 100, камеры разные. У одного по верхнему краю просто насечки от шестеренки, а у другого - еще и темная полоса.

Вышла LibRaw 0.7.0-Alpha0.

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

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

Вот, например, "черная рамка" или маскированные пикселы. Они считываются с матрицы, но в финальное изображение - не попадают. Значения считанных оттуда пикселов - это источник данных для выставления уровня черного. Если читать исходные тексты dcraw, то видно, что для большого числа камер Dave Coffin (а за ним - и многие последователи) банально вычисляет среднее по некоему участку черной рамки (или же в последних версиях для некоторых камер делает чуть-чуть сложнее, считая отдельное среднее для четных и нечетных столбцов), затем это среднее вычитается из значений, считанных с активных пикселов и все.

Впрочем, некоторые производители завесу немножко приоткрывают. Вот, скажем, Kodak. В Кодаковских datasheets на сенсоры написано много всего интересного. И если почитать, например, документацию на KAF-50100 (картинка справа взята из нее), то становится понятно, что структура неактивных пикселов - сложная, тут и референс для выставления уровня черного и что-то тестовое и какие-то буферные пикселы.