And it is now in 0.15-Beta2: return type of subtract_black() is changed to int, returns according to LibRaw convention (0 on success, error code on error)

LibRaw::raw2image() allocates imgdata.image[] array and copies data from internal storage (different for Bayer and non-bayer images) to this array.
No demosaic, no black subtration, this is for developers who want to do processing by hand.

So, three ways exists:
- unpack() + raw2image() - this produce internal data compatible with old LibRaw (0.9-0.13)
- unpack + dcraw_process() - for full processing
- only unpack() but you need to know LibRaw internals, because different data types (bayer vs non-bayer) are stored in different way.

Sure, internals may change in future LibRaw releases, so it is safer to use unpack() + raw2image, although it requires extra RAM.

It looks like wchar_t strings are not supported in MinGW's libstdc++. I'll try to reproduce before next beta wiil be released.

1) Black should be subtracted before demosaic
2) Look into convert_to_rgb code:
to get output matrix, the rgb_cam matrix is multiplied to color space matrix. The rgb_cam is produced by cam_xyz_coeff() call

Do you called raw2image() before calling subtract_black() ?

libraw_open_wfile/open_wfile_ex added in 0.15-Beta1

Could you please check this file with dcraw_emu sample?

Btw, I'm running on 64-bit Windows 7 and doing openBuffer, unpack, dcraw_process, and dcraw_make_mem_image and checking the return codes for each call.

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

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.

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.

Finally I have found a solution:

I added an alignment before some structures:

__declspec(align(8)) typedef struct
{
float iso_speed;
float shutter;
float aperture;
float focal_len;
time_t timestamp;
unsigned shot_order;
unsigned gpsdata[32];
char desc[512],
artist[64];
} libraw_imgother_t;

__declspec(align(8)) typedef struct
{
unsigned int progress_flags;
unsigned int process_warnings;
libraw_iparams_t idata;
libraw_image_sizes_t sizes;
libraw_colordata_t color;
libraw_imgother_t other;
libraw_thumbnail_t thumbnail;
libraw_rawdata_t rawdata;
ushort (*image)[4] ;
libraw_output_params_t params;
void *parent_class;
} libraw_data_t;

Everything works fine now and I am getting all correct metadata values (ISO...).

I guess, the default structure fields alignment on VS2010 is 8 bytes and not 4 bytes.

Thanks for your help :-)