I do not understand your question.

If dcraw_make_mem_image() fails, it will return NULL.
Also, if you pass NULL to dcraw_clear_mem, it will do nothing.

So, what is the *real* problem?

Thank you for the report. Flash data is parsed only for old Canon (CRW) files. To be added to EXIF parser section on the next update.

Canon CR2 files are lossless JPEG (Huffman) compressed. If raw data is damaged, you'll unable to correctly decompress data up to nex (L)JPEG sync tag.

Test:
(v. 0.16)
dcraw -4 -T filename.nef
dcraw_emu -4 -T filename.nef

produces different results, as does the '-W' option (which is also enabled when using -4 option).
Could it be that there is still some kind of auto scaling enabled within dcraw_emu, because it brightens consequtive images differently some times, while dcraw does not.

Thanks a lot for quick answer.

Latest versions of dcraw have changed much in document mode, LibRaw sample may be not up-to-date.

Please specify what kind of output do you want to receive and I'll provide you imgdata.params you need to set to get this mode from LibRaw.

This is already fixed in development branch (available at https://github.com/LibRaw/LibRaw ) in two ways
1) Internal LibRaw color profile is copied to imgdata.color.cam_xyz[] ever for DNG files.
2) For DNG files full DNG color data preserved in imgdata.color.dng_color[2] (if DNG contains two color matrices, then both matrices are preserved)

Thank you so much!
It is now clear for the NEF file. I need however to test if the problem comes from my IIQ picture...

I've check one more time and I still get a maximum value of 11040 for the 16bits data from the PhaseOne IQ180 (even if there's some white zones in the photograph).
Thanks to Alex, I'm now confident with the piece of code used, and I will investigate the problem in the settings of the digital back.

Another question:
is it a normal behavior to have different values for imgdata.color.maximum and max (the latter being computed by looping over the raw pixels)? Here is what I obtain:

max = 11040
iProcessor.imgdata.color.maximum = 64508

Thank you again.

I can confirm his finding, it is in RGBA. This does not only impact dcraw_make_mem_image(), but it also breaks dcraw_ppm_tiff_writer! I am working on Linux 13.04 (libraw v 0.15-0Beta4)
I can also confirm this is *NOT* a problem in OSx 10.9 (libraw v 0.16.0).

I can now confirm this is an issue with <0.16 versions. Update to 0.16 and you are okay.

T

the emulator works fine for me too. But my code is simple and still fails for half size and raw color. Maybe the dcraw make mem image function?

(...)
iProcessor.unpack();
// call for postprocessing utility
iProcessor.dcraw_process();
int check_makemem;
image = iProcessor.dcraw_make_mem_image(&check_makemem);
Mat image_rawRGB(cv::Size(image->width, image->height), rawBitDepthCV, image->data, cv::Mat::AUTO_STEP);

This gives out a mangled image if half size is on and raw colors..

1) half-size interpolation is a special (very fast) mode: each 4 bayer pixels (r-g-b-g) are joined into one RGB pixel with two greens averaged.
2) There is no way to do partial RAW decoding (LibRaw::unpack()), all RAW data always decoded.
3) For partial processing you may set imgdata.params.cropbox (to x1,y1,x2,y2) and LibRaw::dcraw_process() will return you part of image. This is not thread safe, so cannot be used in parallel.
4) LibRaw can use OpenMP for parts of processing (e.g. AHD interpolation), just compile it with OpenMP