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

This is Nikon's 'White balance preconditioning' feature (no way to turn it off, AFAIK).
The data from Red and Green channels are multiplied by some small coefficient and rounded to integer after that.

I do not know WHY Nikon is doing this, but it happens on ALL recent Nikon cameras (have not tested very old ones like D2).

The nikon data is 'lossless JPEG' (huffman compression) compressed. Decompressor code is same for many camera types (Canon, Nikon, Lossless DNG, several others). The missing values occur only on Nikon files. So, this is definitely not decompression artifact, but source data artifact.

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

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

Нет, я не согласен, что так надо делать