LibRaw

RawDigger: индикация пересветов (и челубеев)

lexa - 06/Ноя/2012 13:37

Индикация выбитых светов (и недодержаных теней) - сделана.

Пока - в виде беты, нужно тестировать, смотреть что удобно, что неудобно, что не работает и так далее. Ну и оптимизировать скорость отрисовки. Но пробовать уже можно.

Выглядит это так:

В окошке Display появились пимпы OvExp и UnExp, если их включить, то отрисовываются выбитые пикселы (красным, как в ACR) и недодержаные (синим).

В окошке OvExp/UnExp Stats - показывается статистика по пикселам по всему изображению. Сколько выбито в штуках и в процентах (от общего количества пикселов данного цвета).

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

Естественно, уровни отсечки сверху и снизу - настраиваются. Мануал пока не правился, поэтому опишу настройки прямо тут.

LibRaw 0.15.0-Beta1

lexa - 13/Окт/2012 18:45
Зарелизилась LibRaw 0.15 Beta1.

Изменения:

  • Правильная установка размеров видимой области для Nikon D800E
  • Поддержка DNG-файлов сделанных из RAW Fuji X-Pro1
  • Встроенные описания камер для RawSpeed обновлены до версии r479
  • Win32/C-API: добавлены вызовы libraw_open_wfile/libraw_open_wfile_ex()
  • Новый бит в поле process_warning LIBRAW_WARN_RAWSPEED_UNSUPPORTED, устанавливается (вместе с LIBRAW_WARN_RAWSPEED_PROBLEM) если RawSpeed сообщила, что камера не поддерживается.
  • Запрещена распаковка библиотекой RawSpeed для некоторых форматов (которые распаковываются несовместимо с дальнейшей обработкой LibRaw.

В даунлоадах выложены и бинарники (Win32/Mac), но без поддержки RawSpeed (дабы не гемороиться с лицензией), нужен RawSpeed - собирайте с ним сами.

RawDigger + RawSpeed, вторая попытка

lexa - 22/Сен/2012 21:19

Если репортить об ошибках, то они будут исправлены. Качаем-тестируем RawDigger+RawSpeed, вторую попытку:

Исправлена "ошибка строчной развертки" для форматов, где использовался RawSpeed, а длина строки RAW была некратна 8. Таких, на удивление, немного.

Пишу новым сообщением для тех, кто через RSS читает.

Mac: RawDigger+RawSpeed

lexa - 22/Сен/2012 18:47
Граждане фотографы-маководы!

Помимо виндовой версии, RawDigger с встроенным RawSpeed теперь доступен и для Mac:

Качаем: по ссылке из этого поста

Это альфа-версия: тестировано на нескольких маках, теперь хочется на живых тестерах.

Что изменилось:

  • Открытие файлов .CR2, .NEF, compressed-.DNG - должно стать заметно быстрее. Файлов .ARW, .PEF, .SRW, .ORF, .RW2 - несколько быстрее (незаметно).
  • Для файлов с камер Sony (не всех) - значения пикселов и уровня черного умножатся на 4.
Других видимых изменений быть не должно, все остальное должно быть как в версии 0.9.12. Если у вас изменилось что-то еще, особенно в худшую сторону - пишите.

Второе невидимое (я надеюсь) изменение - это переход с Qt 4.8.1 на Qt 4.8.3.

Update: достоверно известно о глюках со старыми .CR2 (30D, 5D), репортить уже не надо.

RawDigger + RawSpeed = RawDigger

lexa - 19/Сен/2012 21:01

Можно попробовать: качаем по ссылкам из этого поста.

В чем фишка:

Большие файлы CR2, NEF, жатые DNG - открываются на 300-500мс быстрее на быстрой машине (i7-2600k@4.5Ghz), на медленных разница должна быть еще заметнее. На других поддерживаемых RawSpeed форматах (Sony, Panasonic, Olympus, Pentax, Samsung) - разница тоже есть, но не такая большая. Все неподдерживаемые форматы открываются, как и ранее, LibRaw.

Больше (кроме файлов Sony о которых ниже) - фишки не должно быть (еще чуть больше памяти используется). Собственно, это и хочется проверить.

Сравнить можно открыв закладку Preferences, менять положение галки и жать Apply. Если при этом не меняются статистики, гистограммы и т.п. - то все отлично.

Что мне интересно:

  • Есть ли какие-то форматы кроме Sony, где данные и/или результаты рендеринга заметно отличаются. Тестовые файлы пока не нужны, достаточно марки камеры.
  • Может оно вообще глючит и не работает, тоже интересно.
Про Sony:

RawSpeed возвращает значения пикселов для Sony в 4 раза бОльшие, чем LibRaw. Это ни на что не влияет в реальной жизни. При этом, конечно, на такое плавание уровня черного машинка не рассчитана и при нажатии Apply и стоящей галке 'Reset Black Level on file load' - ничего не поресетится в диалоге.

Это нормально и надо забить т.к. в следующих версиях поддержка Sony RawSpeed-ом будет отключена: разница в скорости для этого формата копеечная (не сотни миллисекунд как для CR2, а десятки), изменение значений в 4 раза рвет башню, а всякие полезные вещи вроде 'ARW2 Hack' и отключения тоновой кривой - не работают т.к. RawSpeed ничего такого не умеет.

Update: достоверно известно о глюках со старыми .CR2 (30D, 5D), репортить уже не надо.

LibRaw+RawSpeed=LibRaw :)

lexa - 18/Сен/2012 14:43
RawSpeed - это такая библиотека раскодирования RAW, которая:
  1. Очень быстрая (к примеру, 21-мегапиксельный файл от Canon 5D2 распаковывается на моей машине за 230мс, а код на основе dcraw делает это за 750мс. Притом, это сильно улучшенный мной код, до улучшений было больше секунды, насколько я помню).
  2. Поддерживает мало форматов, правда все они популярные (свежие камеры Canon, Nikon, Olympus, Panasonic, Pentax, Samsung и DNG-файлы).
Авторы darktable давно просекли эту фишку и используют LibRaw как fallback на неизвестных камерах, а как основную библиотеку для открытия RAW - используют RawSpeed.

В то же время, 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 0.9.12

lexa - 14/Сен/2012 08:38

Я был уверен, что написал анонс и сюда, однако его не вижу. Аберрации сознания, значит.

RawDigger 0.9.12 (Beta) вышел (позавчера вечером):

Относительно technical preview есть только одно изменение: на Винде 64-битная версия ставится в "Program Files", а не в "Program Files (x86)", это я документацию по InnoSetup дочитал до этого места.

Анонсы в подходящих сообществах, форумах и т.п. - приветствуются.

RawDigger 0.9.12 (technical preview 1)

lexa - 11/Сен/2012 18:00

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

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

Вот он:

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

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

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

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

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.

LibRaw 0.15. Alpha2

lexa - 24/Авг/2012 17:20
По сложившейся традиции, анонсирую LibRaw 0.15 Alpha2.

Изменения относительно альфы-1:

  • Кроппинг и отдельный вызов LibRaw::subtract_black() полностью работоспособны (в альфе-1 это было не так).
  • Исправлена генерация тоновой кривой для lossy DNG, теперь она полностью совпадает с таковой у dcraw (в альфе-1 временами было расхождение в младшем бите).
  • Вместо поканальных максимумов данных (color_data.channel_maximum) сейчас рассчитывается общий максимум (color_data.data_maximum). Для коррекции розовых облаков этого достаточно.
  • Компрессированные файлы PhaseOne распаковываются в raw-буфер полностью "как есть", коррекция по метаданным из файла (замазывание плохих пикселов, вычитание черного) идет на этапе постобработки или в raw2image(). Если вдруг кому нужны полностью неизмененные данные с этих задников - вот они, пользуйтесь.
  • Импортирована свежая dcraw, поддержка Samsung NX-1000 и Sony DSC-RX100.

Спешу сообщить, что ветка 0.14 развиваться далее не будет, если нужна поддержка новых камер, то используйте 0.15. "Альфа" в названии означает на сегодня только нестабильность ABI (и в меньшей степени - API), а в смысле реальной жизни - все (вроде бы) довольно стабильно.

LibRaw 0.15.0-Alpha1

lexa - 03/Июл/2012 22:22
По традиции, кроме формального анонса LibRaw 0.15 Alpha1 (Changelog под катом) еще и небольшой описание своими словами, что же именно сделано.
  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:

Не корысти ради...

lexa - 27/Июн/2012 12:33

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

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

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

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

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

Картинка дня

lexa - 28/Мар/2012 18:08
Кто не понял про что это - смотрите теги :)

Qt - рулит. Ну то есть я не разобрался (пока?) с динамическими библиотеками, Frameworks и прочими страшными словами, поэтому с LibRaw слинковался статикой.

Ну, естественно, повылезало всякого, но умеренно:

Об исключениях (C++)

lexa - 28/Дек/2011 13:37

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

Возник вопрос, как правильно поступать. Вот есть такой примерно код:

int some_class::some_function(std::filebuf& buf)
 
  try {
      ....
      buf.sgetn(....);
      .....
      return 0; // OK
  }
  catch (my_own_exception_type t) {
        аккуратно_склеить_ласты();
        return errorcode;
   }
}
Вопрос: должен ли я в подобном коде ловить исключения, порожденные std::filebuf? Ну там не смог он ничего прочесть? А вообще все исключения? Как требуют понятия хорошего тона?

Должны ли быть эти правила хорошего тона разными в таких двух случаях

  • Этот самый std::filebuf - на самом деле хранится внутри класса, где-то раньше был создан/открыт и все такое. То есть это наш сукин сын.
  • Этот самый IO-хэндл (std::filebuf) передан нам снаружи т.е. это чужой сукин сын.
?

P.S. Нашелся йузер у которого для файлов с SD-читалки не работает std::filebuf IO. Linux, холст, масло....

О языке ++C

lexa - 16/Сен/2011 23:47

Нашелся тут чудесный баг в KDE-шном DNG-конвертере. Вдруг, внезапно, перестал конвертировать, получаются совершенно ЧОРНЫЕ DNG.

Понятно, пишут в багрепорты digiKam-у, а дальше стрелки переводятся по кругу, ко мне (но LibRaw не менялась, в KDE все еще 0.13), к автору DNG Converter, все отпираются т.к. test cases работают.

И наконец виновник найден

Было:

  *output = ...some value...;
  *output++;
стало
  *output = ... some value...;
  ++(*output);
И комментарий к коммиту: use prefix operator

А я подозреваю, что исходно там было и вовсе:

  *output++ = ... some value...;
Проверять не стал, но предсказываю это.

Потом один доброжелатель разбил операцию на две, как умел, а второй, из ненависти к суффиксным инкрементам (или из желания подавить compiler warning), поменял на префиксный. Тоже, как умел.

Всех люблю: опенсорс, коллаборативную разработку по схеме "у семи нянек....", язык C/C++ тоже люблю.

О legacy и форматах данных

lexa - 27/Авг/2011 09:49

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

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

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

  • от малейшего чиха переполняется или превращается в тыкву обнуляется, нужно постоянно следить за диапазоном;
  • векторные (SSE,AVX) операции с этим типом - очень ограничены, да и не векторные - тоже.
В результате, сплошные мучения компилятору, а результат - медленно работает. Скажем, вот такой вот код (из dcraw), который делает преобразование по матричному профилю для 3-4 входных каналов (цветов) и трех выходных:
out[0] = out[1] = out[2] = 0;
for (сc=0;сc<colors;сc++) {
  out[0] += out_cam[0][сc] * img[сc];
  out[1] += out_cam[1][сc] * img[сc];
  out[2] += out_cam[2][сc] * img[сc];
}
for(cс=0;сc<3;сc++) img[сc] = CLIP((int) out[cс]);
img[] - unsigned short, out[] - int, out_cam[] - float.

Смотрю на код, который порождает интеловский компилятор. Ну код, да. (три-)четыре load по 2 байта (количество loads зависит от colors /количества цветов/), дальше "вручную" выписанный dot product (нормальный, насколько это возможно), ну и обрезание до диапазона 0-65к и store.

Скорость работы этого кода - 100 мегапикселей в секунду на Sandy Bridge 4.5Ghz (в один поток, понятно что параллелится это на ура). Как-то не очень....

Да, считаем в мегапикселях т.к. в unsigned short у нас 8 байт на (4-компонентный) пиксель, а для float/int - 16 байт.

Visual Studio .sln/.vcproj generator?

lexa - 21/Июл/2011 13:10

По многочисленным просьбам трудящихся, я поставляю вместе с LibRaw еще и .sln/.vcproj файлы для MS Visual Studio.

Генерирую я их с помощью Qmake и все более-менее работает, но:

  • Иногда (когда Юпитер в Рыбах?) в sln-файле вместо относительных путей оказываются полные, приходится ручками чистить.
  • Проекты содержат AdditionalIncludeDirectories указывающие (абсолютным путем) на mkspecs от моего Qmake.
  • Можно сгенерировать проект для 32-бит, вроде бы можно (хотя не пробовал) для 64 бит, а вот под две платформы сразу - не умеет.
  • Была еще проблема с зависимостями (exe - dll), ибо зависимости ловятся искуственным интеллектом, но вроде я научился добиваться от него счастья.
  • Достали win32:/unix: конструкции в .pro-файлах, блин.
Короче, неаккуратненько, неровно висят.

Попробовал CMake и счастья еще меньше, проекты ALL_BUILD и ZERO_CHECK раздражают мое эстетическое чувство. При этом проблема абсолютных путей не решена, а дальше я копать не стал и CMake снес.

Что я упустил? Какой еще есть варез, который нагенерирует мне sln/vcproj из простых текстовых файлов?

LibRaw 0.14 Alpha

lexa - 19/Июл/2011 19:24

По сложившейся традиции, анонсирую тут новую 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 задников могут и пару гигабайт памяти докупить.

О консистентности

lexa - 04/Июл/2011 20:10
Чтобы на времени компиляции убедиться в том, что у нас MS Visual C++ 2008 SP1+, нужно забабахать вот такое вот:
#if defined(_MSC_VER) && _MSC_VER == 1500 && _MSC_FULL_VER >= 150030729

Ну ладно, ну вот лично я бы две старших цифры в _MSC_VER занял бы под major версию, а две младших - под minor (сервис-паки, то-се), ну ладно, пусть будет два макроса.

Опять-таки, ладно, что MS Visual C++ 2008 это на самом деле Visual C++ 9.0, а _MSC_VER у него 1500. Ну логично же, да?

Но покажите мне пожалуйста табличку в официальной документации (на MSDN, например), где были бы перечислены версии компиляторов и против каждой версии было бы написано значение _MSC_VER и прочих макросов, важных для определения версии компилятора. blogs.msdn и social.msdn не принимаются, я хочу именно что документацию

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

P.S. Нет, я не привередничаю. OpenMP в нужном мне виде правильно работает в VC++ 2010 и в 2008SP1, я и хочу чтобы оно собиралось бы с OpenMP на вышеуказанных версиях, а на более старых - и не думало бы. Аналогичный случай имеется с C++ TR1, который, вроде бы, человеческим тоже стал в 2008SP1.

P.P.S. В blogs.msdn.com, в каментах, сотрудник MS пишет что надо делать вот так:

#if defined(_MSC_VER) && (_MSC_FULL_VER > 150021022 || _MSC_FULL_VER == 150021022 && _MSC_BUILD >= 8)
       cout << "This is VC9 RTM or above." << endl;
#endif

#if defined(_MSC_VER) && (_MSC_FULL_VER > 150030729 || _MSC_FULL_VER == 150030729 && _MSC_BUILD >= 1)
cout << "This is VC9 SP1 or above." << endl;
#endif
У меня нет слов. Еще и _MSC_BUILD (которого нету в VC8/2005 и более старых).

LibRaw 0.13

lexa - 07/Фев/2011 11:12
По традиции, анонсируем LibRaw 0.13-Release.

В сравнении с бетой-1 (анонсированной ранее), случились некоторые изменения к лучшему:

  • Обновились распаковщики данных (на dcraw 9.06), отчего добавилась поддержка шести новых камер, включая Панасоники GH2 и GF2 и Sony A-580. Еще для девяти камер обновились цветовые данные.
  • Экспокоррекция со сжатием светов теперь работает просто по такой тоновой кривой, линейной внизу и корнекубичной вверху. Без всяких заумных контекстных расчетов яркости (изначально заимствованных из RawTherapee), которые подглюкивают на изображениях, сильно окрашенных в синие тона (и красные тоже, но в меньшей степени).
  • Ну и много всяких правок по мелочи.
Прошу любить и жаловаться.

Pages

Subscribe to LibRaw