Фото

Смотрел всякие кадры, где была сфотографирована белая стенка с вилкой, чесал репу, но на ровных плашках особо выдающегося ничего видно не было. А тут прислали ссылку на такой вот кадр: imaging-resource.com/PRODS/nikon-d800/YDSC_0099.NEF.HTM, собственно вот он открытый в RawDigger:

Смотрим подробнее:

1. Очень быстрая (к примеру, 21-мегапиксельный файл от Canon 5D2 распаковывается на моей машине за 230мс, а код на основе dcraw делает это за 750мс. Притом, это сильно улучшенный мной код, до улучшений было больше секунды, насколько я помню).
2. Поддерживает мало форматов, правда все они популярные (свежие камеры Canon, Nikon, Olympus, Panasonic, Pentax, Samsung и DNG-файлы).

В то же время, RawSpeed распаковывает данные в буфер с очень похожим (но немного разным) форматом, поэтому использовать RawSpeed в качестве читалки файлов изнутри LibRaw (но иметь при этом единый API, единый постпроцессинг и т.п.) - было делом техники. И эта техника - применена в LibRaw 0.15-Alpha4.

Что получилось

• LibRaw::open_file()+LibRaw::unpack() /т.е. распаковка/ - в ~3 раза быстрее на CR2, в ~2-2.5 раза быстрее на NEF, в 1.5-2 раза быстрее на прочих поддерживаемых форматах. Реально это заметно на больших NEF и CR2 (выигрыш в 400-500 миллисекунд на моей i7-2600K @4.5Ghz), соньки и раньше распаковывались быстро, а у остальных форматов редко бывают совсем уж большие файлы.
• dcraw_emu -h ..список из 182 файлов.. - без RawSpeed было 150 секунд, стало 100 секунд. Разница "не в 2-3 раза" потому что постпроцессинг не изменился (хотя с -h он и так быстрый)

Граждане фотографы и примкнувшие к ним!

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

Вот он:

• RawDigger-0.9.12-TP1-Beta-RU-Setup.exe - Windows/32 бита.
• RawDigger-0.9.12-TP1-x64-Beta-RU-Setup.exe - Windows/x64
• RawDigger-0.9.12-TP1-Beta-RU.dmg - Mac OS X/Intel, 32/64 бита.

Мне интересны глюки, мешающие выпуску на широкую публику: падения, полностью неправильное поведение и т.п. Всякая мелочь, вроде разрешенного "Average green" для черно-белых RAW - не является шоу стоппером (в частности, по той причине, что монохромных камер у людей - примерно ноль).

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

Отдельная просьба: не надо эту версию более нигде анонсировать. Если она работает, то буквально завтра я ей поменяю название и номер билда - и выпущу. А если нет, то надо же доделывать. На неприслушавшихся к этой просьбе - затаю.

Что новенького

Несколько месяцев назад я задал вопрос на forum.rudtp.ru, по некоторым причинам (не имеющим отношения к цветовой науке) тема была спрятана и закрыта, но недоразумение разрешено и она теперь распрятана и открыта.

Вот она: "... лучше соответствует критерию Лютера-Айвса".

Если имеете что сказать по теме - я буду благодарен. Лучше - прямо там, если по каким-то причинам удобнее здесь, можно и здесь. Очень хочется разобраться.

Я уточнить хотел к предыдущему вопросу. В MF цифровых камерах согласно всяким там заявленным характеристикам вроде часто стоит 16 битный АЦП. Это якобы заметно повышает ДД камеры (настолько что как обсуждалось некоторыми товарищами в той ссылке оставляет все DSLR с ихними 14 битами далеко позади). Это действительно так? Какй нибудь сильный выигрыш в тенях от этого получается?

Какой вывод мы можем сделать? А такой, что АЦП - 14-битный, а в младших битах 16-битных значений до вычитания черного были такие вот кругленькие нолики.

В нежатом формате - не так, но нежатый формат я видел только на очень старых задниках, а все что видел нового - жатое. И на P45 и на P65+ и на IQ180 - везде в данных 14 реальных бит.

Справедливости ради, в материалах на сайте PhaseOne ничего про 16-битный АЦП не написано. Все гораздо более обтекаемо, "16-bit OptiColor"...

P.S. Написанное выше - конкретно про PhaseOne. Невозможность имения в этом формате 16-битных RAW-данных вытекает просто из процедуры распаковки. Для других форматов все не так прозрачно.

1. Всосана свежая версия dcraw со всеми ее изменениями в логике (распаковкой в отдельный буфер, изменениями в расчете уровня черного и проч.).
2. Поддержаны все форматы, поддерживаемые dcraw (+ немножко технических камер), в том числе:
   • DNG сжатый с потерями (и прочие упражнения с DNG, привнесенные 4-м Лайтрумом)
   • "Новые" Фовеоны. Ну, они условно новые т.к. формат поменялся еще в DP1, но вот начиная с DP1/SD15 и вплоть до самоновейшей SD1 Merill - все поддержаны.

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

   • Fuji X1-Pro. Как и в dcraw, для нее работают только две интерполяции, билинейная и VNG.
3. Достигнута побитовая совместимость с выдачей dcraw 9.16 для всех протестированных форматов (а тестами не покрыты только очень старые мыльницы и задники Sinar).
4. Все ускорения, сделанные в предыдущих версиях - временно припрятаны, но будут постепенно возвращены назад.

Формальный Changelog относительно версии 0.14.6:

Граждане читатели,

если у кого есть примеры sRAW с камеры Canon 5D Mark III, не откажите в любезности их куда-нибудь залить (Дропбокс и так далее) и прислать мне ссылку (можно прямо тут в комментариях).

Актуально до вечера - я знаю у кого таких файлов взять, но сейчас там ночь.

Update (т.к. в ЖЖ не видны коменты в блоге): предмет съемки, ISO, выдержка - неважны совсем. Мне декодер протестировать. А вот оба режима sRAW (если в 5D3 их тоже два) были бы полезны, для полноты тестирования.

Update2: Спасибо приславшим, больше уже не надо :)

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

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

Вопрос же у меня, собственно, такой: А экспозиция то какая?

Из общих соображений, казалось бы, ISO ставим в Unity Gain (т.е. 400 для 5D2), диафрагму пошире, а выдержку - такую, чтобы за время экспозиции звезда прошла бы 1-2 пикселя (зависит, соответственно, от снимаемого участка неба и поля зрения объектива). При более длинной выдержке - вроде бы будут дорожки, а не звезды, ну так дорожки я сам поклею потом из многих кадров.

Но что я не учел?

Update. Нашел у Рейхмана (спасибо за 600 rule, так проще искать):

For all the anal compulsives out there, here's the scientific formula for calculating star trail exposure times as quoted from Sky & Telescope...

The length l of a star's trail on the film in millimeters can be calculated from the formula

l = [tF cos (delta)]/13,750,

where t is the exposure time in seconds, F the focal length of the lens in millimeters, and delta is the north or south declination of the star.

Happy?

Краткое описание изменений:

• Медленные операции (RGB-рендеринг файла, нажатие Apply/OK в настройках при изменении процессинга) стали гораздо быстрее на многоядерных машинах.
• Исправлены некоторые ошибки, втч. приводившие к падениям.
• Табличные данные (EXIF, таблица замеров) копируются в Clipboard.
• Немножко мелких косметических изменений.

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

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

P.S. Вместо обещанного TBB многопоточность сделана через Qt Concurrent. Оказался примерно один фиг по объему дополнительного кода (ну вот список тасков надо самому сформировать, 5-6 строк лишних), один же фиг по производительности (в пределах точности измерений на 4-Core CPU), а дополнительной библиотеки с непонятным лицензированием не добавляется.