LibRaw 0.15.0-Alpha3

lexa - 04/Сен/2012 22:49
В LibRaw 0.15.0 Alpha3 возвернуты те улучшения, которые были/есть в 0.14, но которые были временно удалены из девелоперской 0.15-Альфа1-2:
  • Быстрый декодер LJPEG
  • OpenMP-ускорение в AHD/PPG-интерполяторах и в Wavelet Denoise
  • OpenMP-ускорение в вызове raw2image_ex()
  • Патчи для совместимости с LCMS1
В результате на 4-ядерной виртуальной машине dcraw_emu примерно в 1.5 раза быстрее dcraw на обработке моего обычного тестового набора из 339 RAW.

Несмотря на 'alpha' в названии версии, она может считаться стабильной в смысле качества работы. Вот ABI/API пока не устоялось, "есть еще пара идей", оттого и альфа.

А предыдущая альфа-2 сегодня попала в девелоперскую KDE 4.10, можно пользовать оттуда.

Upd: alpha-3 уже тоже в девелоперской KDE.

Comments

maratyszcza (not verified) - 05/Сен/2012 04:34

В LibRaw есть SIMD-код?

lexa - 05/Сен/2012 09:12

Нет. Ее же тянут во всякие странные места: iOS, андроид. Голый C++, без наворотов.

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

maratyszcza (not verified) - 05/Сен/2012 10:13

А если будет доступна бесплатная библиотека функций с SIMD-оптимизацией под x86/x64/ARM, будете использовать в libraw?

lexa - 05/Сен/2012 10:24

Зависит от лицензии. GPL - нет, LGPL и свободнее - да.

Ну и от функциональности - тоже зависит, естественно. Что она делает то :) ?

maratyszcza (not verified) - 05/Сен/2012 11:01

Лицензия BSD или zlib. Но только на C++/ассемблерный код + Makefiles.

Пока что она допиливается, и состоит из нескольких слабоинтегрированных частей. Умеет всякие операции над массивами во всех возможных вариантах (т.е. c[i] = a[i] + b[i], c[i] = a[i] + b, a[i] += b[i], a[i] += b, с разными типами: 8/16/32/64-битные знаковые/бесзнаковые целые, 32/64-битные с плавающей запятов), умеет быстро и точно считать мат. функции от массивов (немного быстрее, чем интеловские библиотеки, намного быстрее, чем амдэшные), умеет кросс-платформенно определять характеристики процессора (x86/x64/IA64/ARM/MIPS, эта часть библиотеки выдрана и запакована в программку для Андроида), имеет биндинги для JNI.

lexa - 05/Сен/2012 11:23

У libraw есть архитектурная беда следующего вида
- хранение пикселов в uint16
- многие части обработки - в float (ну а как иначе матричный профиль то накладывать), с последующим преобразованием обратно в uint16 и

А переделывать конкретно этот процессинг по человечески - не хочется (в частности по той причине, что куча contributed-кода уже завязана на это представление)

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

Ну вот к примеру масштабирование каналов (баланс белого) - каждый компонент в четверке нужно домножить на свой коэффициент, просто a[i]*=const не подойдет, размножать коэффициенты в какой-то длинный вектор тоже скучно немножко.

Алексей (not verified) - 11/Окт/2012 12:37

А какая судьба у этой фичи? В комментариях к Альфа1 говорилось, что работала не корректно? Правда ли что при корректной работе 4 бита в тенях действительно можно восстановить? Игрался с фичей в версии RawDigger-а, но эффекта на гистограмме не увидел - дырки потерянных бит по всему диапазону :(

lexa - 11/Окт/2012 12:50

Фича - работает.

Возможно, ей можно восстановить один бит, но никак не 4.

Вот стандартный код:
RAW(row,col) = curve[pix[i]<<1] >> 2;
Т.е. умножаем распакованое на два, смотрим в кривой (которая в тенях - вроде бы линейная), получаем из кривой, соответственно, четные значения, делим на 4 (теряем два младших бита)

Вот код для ARW hack:
RAW(row,col) = curve[pix[i]<<1];

Так как в кривую мы ходим только четными значениями (pix << 1 - это pix*2), то младший бит на линейном участке кривой (которая curve[i] = i) всегда будет нулевым, соответственно деление на 4 теряет один бит максимум.

Но вообще, спасибо что напомнили, надо посмотреть в этом место чуть внимательнее.

lexa - 11/Окт/2012 12:55

Да, можно взять RawDigger, который "с RawSpeed", отключить RawSpeed - и посмотреть на младшие биты.
Брать - лучше всего - по ссылкам отсюда: http://blog.lexa.ru/2012/09/19/rawdigger_rawspeed_rawdigger.html#comment...

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

Алексей (not verified) - 11/Окт/2012 13:18

Спасибо за быстрый ответ!

То есть реально эффект такой, что восстанавливаем 1 бит и ещё на один бит масштабируем до дианазона 12-битных форматов? То есть реально при сжатии в ARW2 уже потерян 1 младший бит из заявленного 12-битного разрешения АЦП даже в тенях?

lexa - 11/Окт/2012 13:33

Ну вот кривая: http://blog.lexa.ru/2011/10/28/o_lineinosti_raw_i_ettr.html
У нее вход - 12-битный (0-4095), но перед лукапом в кривой - умножили на 2.

Получается, что реально используются 11 бит, иначе не влезть в диапазон.

В процедуре распаковки нигде обрезания младшего бита нет - выходит что в самих RAW лежат 11 бит.