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-конверторов я рекомендую начинать потихоньку переход к новому интерактивному миру. Потому что интерактивность - это хорошо.