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 задников могут и пару гигабайт памяти докупить.

Смотрим дальше: современные мониторы - это 2, максимум 4 мегапикселя. Современные камеры - меньше 10Mpix осталось только в камерафонах. Следовательно, задачи показать картинку целиком в масштабе 1:1 просто нет, не влезает.

Что предлагается (разработчикам Raw-конверторов и прочих тулов обработки RAW):

  1. Для показа всего изображения используем "половинный" размер (half_size в терминах LibRaw). Уже текущая альфа делает в этом режиме постпроцессинг 16-мегапиксельной картинки за 220 миллисекунд (на быстром десктопе, да) и это уже почти приемлемо. Там еще есть куда расти разика в два, а может и три без программирования на ассемблере.
  2. Показ 1:1 делаем в отдельном окошке, размером скажем 200x300 и уже со всеми понтами: полноценная интерполяция, highlight recovery и тому подобное. Для указанного размера полноценную интерполяцию получается сделать за 11msec, а вместе с highlight recovery - за 13, то есть обновлять данное окошко при пользовательском помавении мышью со скоростью кадров 25-30 в секунду - вполне возможно.
  3. Ну а финальный рендеринг делается, скажем, в фоне в отдельном потоке. Будет он занимать 3 секунды или 15 - без разницы (для HL-recovery скорее 3, для всяких Wavelet-denoise - скорее 15).

С пользовательской же точки зрения, если вы используете не LibRaw, а прилагаемые к ней утилиты (dcraw_emu) разницы никакой нет. Ну местами стало побыстрее (но на фоне распаковки - незаметно), ну починился crop для FujiCCD.

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

Авторам же RAW-конверторов я рекомендую начинать потихоньку переход к новому интерактивному миру. Потому что интерактивность - это хорошо.

Comments

>> Авторам же RAW-конверторов я рекомендую начинать потихоньку переход к новому интерактивному миру. Потому что интерактивность - это хорошо.

Ну, какбэ, давно пора :) Так скоро, глядишь, и до 1:2, 1:4, 1:8 временных размеров доберутся, и скорость кручения ползунков будет как в лайтруме.

Да там и без уменьшения размера можно получить еще полпорядка точно, а порядок - не знаю, но думаю что да.

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

В LR конвертация не интерактивная. Интерактивная там работа с полноцветным битмэпом с гаммой 1.0

Whatever.

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

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

А народ и не знал :)

Остается понять, куда девать тех, кому для 95% фото достаточно тех ползунков, что есть в LR, при этом нет желания лезть в фотошоп по причине выигрыша в скорости работы, потоковой обработке и месте на диске.

Это не совсем так. Некоторые ползунки в ACR (и, следовательно, в LR) работают даже до де-баера, не говоря про гамму. Теоретически в PS это повторить можно, но гораздо более трудоёмко.

А есть к LibRAW какой-то фронтенд под Win?

Есть digiKam, есть еще забыл фамилие, грек какой-то делает.

Но вы этого не хотите, честное слово!

Этого - да, уже видел :(

А что же я хочу, если маки я не люблю (да и для остальной работы не подходят), а в darktable, если я правильно понял их анонсы, либрав использоваться перестал?

А зачем вам постпроцессинг от LibRaw? Ничего в нем нет хорошего, если уж совсем честно. Его используют там, где нет желания (или возможности) сделать свое, а вообще задача библиотеки - не постпроцессинг, а просто распаковка RAW в байеровские данные. Постпроцессинг "достался на халяву" от dcraw (+ волонтеры, конечно), но я не считаю что там все сколько-нибудь хорошо с точки зрения фотографа.

Другой вопрос, что более-менее весь опенсорс такой, диковатый. Оговорюсь сразу - по состоянию на полгода назад; в darktable, rawstudio и rawtherapee большие подвижки с точки зрения программирования (но, увы, не фотографии).

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

Я так подозреваю надеюсь, что распаковка должна везде давать одинаковый результат.

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

Э.. Если я правильно помню ченджлоги, то есть большая разница с точкой черного, у каждой софтины потом накладываются разные тоновые кривые и т.д. И все это каждый раз неправильно. А еще демозаика везде разная, это ведь относится к распаковке?

ну и мой любимый баг - проявка солнца - http://knutov.livejournal.com/1467900.html

Все что вы перечислили, кроме, быть может, точки черного, это в моей/LibRaw терминологии - именно постпроцессинг.

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

С пересветами плохо везде.

Я делаю dcraw -H 1 -o 0, потом обработку пересвета в фотошопе руками, путём накладывания слоя с нужным цветом.

ну почему равшутер то делает все хорошо из коробки? И исходя из того что он делает - нет там пересветов и данных достаточно.

А почему бы не встрять в darktable один из проектов?

Порезались псевдотэги. Очень злой движок. (Я darktable обрамлял типа-тэгами imho )

Движок злой, он знает список разрешенных тегов, а больше - нини.

Тут такое дело - RAW-конвертор это не только код и алгоритмы, но еще и данные (например, профили камер). Я такими данными не владею/не распоряжаюсь и привнести их в открытый проект не могу. А значит и смысла нет.

Это одна из причин, но важная.

Я вот, кстати, всё давно хотел спросить. То есть, я сам пробовал, но у меня никак не получилось, то-ли я тупой, то ли это какой-то фокус.

Как можно из кода dcraw взять XYZ координаты primaries камеры? Чтобы их потом засунуть в icc файл.

В icc файле можно задавать точку белого, координаты для R, G и B точек, и точку черного. Черное на 0, белое, допустим, 100-100-100 будет.

Ну, вот у меня никак не выходит получить такой результат, что с параметрами "-o 0", а потом применением icc файла получалось бы тоже, что с цветами по-умолчанию.

Насколько я помню, это imgdata.color.cam_xyz

Во всяком случае, что-то такое оттуда изымает DNGConvertor (который KDE-шный), кладет в DNG-шный color matrix и получается счастье. Для большинства камер - это из builtin-таблицы в dcraw, за исключением тех камер, которые цветовые данные кладут прямо в Raw.

За давностию лет я мог перепутать название поля по памяти, но смысл именно такой, лучше посмотреть в исходники dngconverter.

Штатной утилиты, которая бы доставала ЭТО оттуда нет.

Я имею ввиду, сам код dcraw

Ну так там таблица в функции adobe_coeff() или как-то так. Туда передается maker/model и, собственно, внутри заполняется cam_xyz[]

Это я понял.

Я не понял, какими значениями можно заполнить .icc файл.

То есть, то-ли я чего-то не понимаю, то-ли какая-то ерунда, но когда я тупо из этой матрицы переношу цифры в поля .icc файла, получается какая-то ерунда. В смысле, этот файл даёт дикие ужасные цвета, совсем не похожие на нормальные.

Raw Therapee не использует LibRaw?

Насколько я знаю, нет.

Они патчат dcraw сами, где-то зимой хотели переходить на LibRaw, но вроде забили.

На сколько въедливо libraw распаковывает DNG?

У меня тут есть подозрение, что часть файлов побилась. Но отсмотреть все 10K+ сил нет, конечно.

У DNG 1.2+ есть MD5 от контента, но у меня только 1.1, с его невнятным RawDataUniqueID который в моём случае не MD5 и не SHA1 (хотя и 16 байтов).

Какие шансы, что libraw заметит ошибки?

Не встречалось ли тебе описания (ВДРУГ!) что может быть в RawDataUniqueID?

Там lossless jpeg в данных, проверки целостности в данных нет.

Т.е. только выгнать в tiff и глазами.

Add new comment