LibRaw 0.15.0-Alpha4

Submitted by lexa on

LibRaw 0.15-Alpha4 introduces a lot of changes:
  • Alpha-quality (i.e. untested) RawSpeed library support (http://rawstudio.org/blog/?p=800) Decoding (LibRaw::unpack()) of supported formats is 1.5-3x times faster.
  • OpenMP speedup for linear interpolation
  • Disabled decoding JPEG (lossy DNG) data from memory buffer for libjpeg version less than 8. Use -DUSE_JPEG8 if your jpeg is v8+
  • hotspots moved to virtual functions
  • is_phaseone_compressed() call
  • PhaseOne RAWs: for user-specified black level(s) black subtraction works as expected.
  • ABI and API changed, all programs using 0.15-Alpha1-3 should be recompiled!

More on RawSpeed support:

  • API changes:
    • imgdata.params.use_rawspeed run-time configuration option (default to Yes!)
    • LibRaw::set_rawspeed_camerafile(char *path_to_cameras_xml) - call to set camera information on runtime (cameras.xml from latest release is compiled in). If you do not use this call, compile-time cameras.xml will be used.
    • New call Libraw*datastream::size() returns full size of data file (needed for RawSpeed support). Implemented for all datastreams provided with LibRaw.
    • imgdata.sizes.raw_pitch - row pitch in imgdata.rawdata.raw_image Use raw_image[row*raw_pitch+col] instead of [row*raw_width+col] if your code accesses raw_image[] array.
  • Other changes:
    • dcraw_emu: command line switch -disars disables RawSpeed use
    • postprocessing_benchmark: use -c to disable RawSpeed use
  • RawSpeed support uses buffer for full RAW file, so memory usage is higher.
  • Compilation:
    • Use -DUSE_RAWSPEED define to turn RawSpeed support on. You'll need to compile and install RawSpeed on your system. See README.RawSpeed.txt for details
    • set -DNOSONY_RAWSPEED to disable Sony files decoding by RawSpeed
    • ./configure do not supported yet, use Makefile.dist on Unix/Mac and Makefile.msvc on Win32
    • (Unix only) Set RAWSPEED_XMLDATA=../path/to/cameras.xml to re-build internal copy of RawSpeed's cameras.xml file
  • TODO:
    • RawSpeed decode support for non-bayer images
    • Remove double-buffering if LibRaw_buffer_datstream is used
    • Documentation and samples Update

Comments

Lossy DNG Not working

Submitted by tbrown on

Lossy DNG files exported by LightRoom 4 seem to crash.

The call stack is:

#0 0x0000000116801719 in LibRaw_file_datastream::jpeg_src(void*) at /Users/tbrown/Documents/ProjectsOnOne/Suite6/LibRaw/src/libraw_datastream.cpp:280
#1 0x0000000116793de9 in LibRaw::lossy_dng_load_raw() ()
#2 0x00000001167c0751 in LibRaw::unpack() ()
#3 0x00000001167bc9de in libraw_unpack ()

when calling this line of code

jas_file = fopen(fname(),"rb");

The fname() returns a garbage string so that the fopen fails and then crashes soon after.

I am using the USE_JPEG8 flag when compiling. I have upgraded to the latest version of the jpeglib. Is there something else I need to do to get this working

Thanks for any help you can give.

Thanks for feedback. Could

Submitted by lexa on

Thanks for feedback.

Could you please specify your working environment:
- what test-code do you use, dcraw_emu (or something else from LibRaw's samples)
- or your own code

Possibly, the source of error is:
1) LibRaw_file_datastream() constructor saves the pointer to filename you pass to LibRaw::open_file()
Note, the pointer is stored, not string copied!

2) the buffer with filename (passed to open_file) is destroyed before LibRaw::unpack() called

-- Alex Tutubalin @LibRaw LLC

Thanks and Feature Request

Submitted by tbrown on

I did not realize the pointer to the path was not being copied. Once I made that change, it worked. We are using the c api and I was wondering if you were going to add a wchar_t version for the libraw_open_file call on windows? Currently I am doing that myself.

OK, I'll change

Submitted by lexa on

OK, I'll change LibRaw_(big)file_datastream internals to save std::string instead of just pointer. It is safer way.
0.15 still in pre-Beta state, so I may change ABI/internals without saving compatibility :)

Also, I'll add open_wfile() call (under #ifdef WIN32) in next Alpha.

-- Alex Tutubalin @LibRaw LLC

Thanks and receiving a few warnings

Submitted by tbrown on

In the file wf_filtering.cpp we are getting a few warnings. Not sure if they are critical or not. This is using xcode 4.3 on the mac using the apple llvm 3.1 compiler. Below is the warning with the associated line numbers.

Control may reach end of non-void function
686

& has lower precedence than ==; == will be evaluated first
1169
1332
1623
1682
1703
1720
1759
1798
1857
1895
1934

wf_debanding code is

Submitted by lexa on

wf_debanding code is '3rd-party', contributed to LibRaw.

I'll ask author about these warnings.

-- Alex Tutubalin @LibRaw LLC