LibRaw 0.16.0 dynamic library - Problem?

Submitted by duxy on

Hi,

I have developed a program that links to the thread-safe dynamic library from LibRaw 0.15.4 on a Mac (with OS X 10.9). This has worked perfectly for several months, and the developers of LibRaw are to be congratulated on providing such useful functionality.

I recently upgraded to LibRaw 0.16.0, and dynamically linked my (modified) application to the new dynamic library (libraw_r.dylib, libraw_r.10.dylib). However, the LibRaw functionality no longer works (functionality is essentially just loading a raw image). The code hangs at the point at which the raw image is loaded using LibRaw. I have also compiled my application, and liked to the LibRaw 0.16.0 dll, on a windows machine, and everything works correctly there. I tried swapping out *just* the libraw_r.dylib and the libraw_r.10.dylib, and replacing them with the libraw_r.dylib and libraw_r.9.dylib from LibRaw 0.15.4, and my Mac application works correctly again.

I am just wondering if there is any known issue with the Mac version of the thread-safe dynamic library for LibRaw 0.16.0?

Thanks,

duxy

Forums: 

LibRaw *major* versions are

Submitted by lexa on

LibRaw *major* versions are not binary compatible (i.e. if you replace 0.15.xx to 0.16.xx you need to recompile your app). This is because internals are changed.

Correct versioning is implemented in configure and cmake scripts (and for Linux). I'm not sure, that configure/cmake scripts works well under Mac.

-- Alex Tutubalin @LibRaw LLC

Hi Alex, thanks for the quick

Submitted by duxy on

Hi Alex, thanks for the quick response.

Sorry I should have mentioned that I recompiled my app when linking to the 0.16.0 libs. However, after debugging further I have realised that the LibRaw lib functions actually appear to be working ok, and that my problem lies somewhere else. The problem now is that the 0.15.4 and 0.16.0 libs produce different results for the following code snippet:

myImg->unpack();
myImg->imgdata.params.output_bps=16;
myImg->dcraw_process();
myRawData = myImg->dcraw_make_mem_image();
bitDepth = myRawData->bits;

For the *same* image, linking to 0.15.4 libs gives bitDepth=16, whereas linking to 0.16.0 libs gives bitDepth=8. This is despite the output_bps parameter being set to 16.

Any insight as to why this would be the case?

Thanks,

duxy

You cannot replace Libraw 0

Submitted by lexa on

You cannot replace Libraw 0.15 binary (.so/.dylib) file with 0.16 (and vice versa).
The internal data structures are different.

-- Alex Tutubalin @LibRaw LLC

Hi Alex, I appreciate the

Submitted by duxy on

Hi Alex, I appreciate the quick response.

OK maybe I'm overlooking something obvious, and correct me if I'm wrong.... but if I re-compile my app each time, and re-compile the libs, then I can link to either the 0.15.4 or 0.16.0 libs? So this is what I have been doing each time that I test. I am aware that the API has changed between those two libs, but I do not know of any functions I'm calling directly from my code that need to be altered to use the two different libs (see code snippet in my previous post).

So my code base stays the same for either lib, yet I get different answers for the bit depth of the same image (after calling dcraw_make_mem_image()) depending on which lib I link to under Mac. Also the windows compile of my app gives the same bit depth for both libs. As I say, maybe I'm overlooking something obvious....

Thanks,
duxy

Yes, 0.15 and 0.16 (or 0.11

Submitted by lexa on

Yes, 0.15 and 0.16 (or 0.11 and 0.12) are binary incompatible due to internals change.
You can use 0.15.x (from 0.15.0 to 0.15.4) or 0.14.x (from 0.14.0 to 0.14.8) without recompile of your app.

But if you change 'major' (second, because first entry is always 0) version, you need to recompile your application.

You may create some wrapper (with getters/setters to access imgdata.* fields) to stabilize the API for your needs (if you need to set only output_bps, you need only one setter call).

-- Alex Tutubalin @LibRaw LLC

Hi Alex, thanks for that. I

Submitted by duxy on

Hi Alex, thanks for that. I eventually found the problem that I was encountering in relation to the 0.16.0 build - I was inadvertently including the libraw.h file from the 0.15.4 build.

All working now, thanks,
duxy