LibRaw 0.14.0 (Release)

After three months of testing the LibRaw 0.14 is considered stable. This version is recommeded to use instead of LibRaw 0.13.

The most significant change of this version is multiple rendering (via LibRaw::dcraw_process() calls) of same RAW data without re-opening RAW file through the sequence of open()/unpack() calls. You should be able to change any processing parameters (except shot_select parameter) between dcraw_process() calls.

So, it is possible to implement near-realtime preview of entire image in half-resolution mode and realtime preview of selected area (e.g. around mouse pointer position) in full-resolution mode.


  • Multiple rendering:
    • New sample in samples/multirender_test.cpp: renders data 4 times: in half and full modes with different white balance settings.
    • Unprocessed RAW data is stored in separate data buffer: (2 bytes per pixel for all Bayer-pattern images, 8 bytes per pixel for Foveon, sRAW, and other full-color raw formats), so now LibRaw uses 25% more memory for full processing of most common Bayer images; while for just unpack memory is reduced 4 times.
    • New call LibRaw::raw2image() fills imgdata.image array with fresh copy of data. There is no need to call raw2image() separately if you use dcraw_process() or dcraw_document_mode_processing() calls.
    • New call LibRaw::get_decoder_info() to determine raw data storage layout. See samples/unprocessed_raw.cpp for an example of how to use it.
    • New call LibRaw::free_image(), deallocates imgdata.image buffer. Use this call if current postprocessing results are not needed, but it is to early to call recycle() because dcraw_process() may be called later.
    • New C-API calls libraw_raw2image() - C API for LibRaw::raw2image() libraw_free_image() - C API for LibRaw::free_image() libraw_get_decoder_info() - C API for LibRaw::get_decoder_info()

    If your code uses usual open()/unpack()/dcraw_process() call sequence, then NOTHING CHANGED: your program should produce same results. For interactive programs you may skip open()/unpack() calls after adjusting processing parameters, so user should see image refreshed much faster.

    If your code uses raw data (open+unpack calls), you need to call LibRaw::raw2image(), and imgdata.image will contain same bitmap as in LibRaw 0.13.x

    If you code uses access to masked borders data, you need to rewrite it. See samples/unprocessed_raw.cpp as a sample.

  • Other changes:
    • No separate imgdata.masked_pixels buffers, Bayer raw formats are read to buffer with borders. So, no ugly add_masked_border_to_bitmap() call.
    • No filtering_mode parameter. Raw tone curve is applied at unpack() stage; zero pixels removed on postprocesing stage.
    • unprocessed_raw and 4colors samples are adjusted to use new RAW data storage layout.
    • OpenMP speedup of postprocessing steps (up to 50% for half mode and 4-core machine)
    • Most of LibRaw_datastream function bodies are moved to separate source file
    • LibRaw_windows_datastream is merged to main source tree
    • Imported dcraw 9.10 (1.444), support for new cameras added: ARRIRAW format, Canon SX30 IS, Leica D-LUX 5 and V-LUX2, Olympus E-P3, Panasonic G3 and GF3, Sony NEX-C3 and SLT-A35
    • Support for RedOne digital movie cameras (R3D format). To enable this support you need to:
      • install libjasper JPEG2000 support library
      • compile LibRaw with -DUSE_JASPER compiler switch (./configure will do it for you)
      • If you use own LibRaw_datastream implementation, you should implement make_jas_stream() call for your datastream. See bottom of src/libraw_cxx.cpp for implementations in datafile and mem-buffer LibRaw streams.
    • Bugfix: green matching is turned off if output image is shrinked due to wavelet filtering or aberration correction.
    • Removed imgdata.sizes.bottom_margin and right_margin data fields use imgdata.sizes.raw_width - width - left_margin to get right one, the same with bottom_margin.
    • Minor ./configure cleanup
    • Qmake files and Visual Studio Project files are updated.
    • New version check macroses.
    • Documentation changed to reflect 0.14 changes.
    • Removed LibRaw::rotate_fuji_raw() call and corresponding C-API call.
    • The LibRaw::adjust_sizes_info_only() call may be called repeated and mixed with dcraw_process() calls.
    • Postprocessing speedup and optimization, especially if cropping set.
    • Cropping works for FujiCCD raws. For the technical reasons, the position of top-left corner of crop area will be rounded to the nearest multiple of 4 (the corner is shifted top-left).
    • New sample samples/postprocessing_benchmark.cpp This sample measures postprocessing speed. All demosaic methods, averaged white balance, median filtering, wavelet filtration, highlight recovery, and cropping are supported.
  • all client code should be recompiled due to internals change.


В darktable собранном с

В darktable собранном с 0.14.0 (в gentoo есть патч с которым можно собрать dt с системным libraw) на многих снимках вылазят цветные точки. Не знаю проблема это со стороны darktable или libraw.

В darktable же полностью свой

В darktable же полностью свой постпроцессинг, от libraw берут только RAW-данные (потому и может работать с rawspeed)?

-- Alex Tutubalin @LibRaw LLC

Я собираю darktable без

Я собираю darktable без rawspeed. Так как с моим Pentax K-x последний не умеет работать, вернее тот что встроен в 0.9.2 не умеет. Так вот с libraw 0.13.8 всё отлично, а c libraw 0.14.0 цветные точки появляются.

Вообще-то, в libraw 0.14

Вообще-то, в libraw 0.14 довольно много всего поменялось. В частности, доступ к RAW-данным.

Вместе с тем, если вы выложите куда-то исходник (RAW-файл) то я на него, как минимум, посмотрю...

-- Alex Tutubalin @LibRaw LLC

Это на 99% похоже на

Это на 99% похоже на переполнение целого (или short, уж не знаю что там используется в dt).

LibRaw 0.14/dcraw_emu -T такого эффекта не дает.
Возможно какой-то постпроцессинг LibRaw такой эффект и даст, но мне за несколько попыток не удалось подобрать варианты и я бросил. Тем более, что я не знаю как именно dt использует LibRaw.

Не менее возможно, что это такое вычитание черного, без проверки выхода ниже нуля, но это точно не LibRaw так поступает, по сведениям LibRaw черный уже вычтен.

-- Alex Tutubalin @LibRaw LLC

Да, жалко что мы на

Да, жалко что мы на .org-сайте эту дискуссию развели, при наличии русскоязычного.
Иностранцев распугаем.

-- Alex Tutubalin @LibRaw LLC