When I use DCRAW to extract the RAW pixel values from a NEF file made by my D5300 I notice that there seems to be a minimum value clamp = 588 applied to the pixel values. I am an astrophotographer so generating master BIAS and DARK frames is part of my image calibration method. Both BIAS and DARK frames are images with the lens cap in place so that no light enters the camera. I believe that Nikon uses a Darkness value of 600 in their NEF files. The 588 minimum value clamp causes a huge number of pixel values in my individual DARK frames to be clamped at 588.

use of auto_ptr is deprecated and generates warnings in the mingw build. Enclosed is a patch to replace auto_ptr with unique_ptr, which eliminates these warnings with mingw (and hopefully future-proof).

If I compile under mingw with the supplied configure, I get warnings from the mingw C++ compiler stating that winsock2.h should be included before windows.h. The following patch moves up the definition of winsock2.h in libraw_datastream.h, and then the warnings go away.

On a Mac Mini quad core i7 running High Sierra with 0.19.0-Beta1:

$ time /opt/local/x86_64-apple-darwin/bin/dcraw_emu -h -w ~/Downloads/fujifilm_x_t2_01.raf

real 0m0.988s
user 0m2.885s
sys 0m0.183s

$ time /opt/local/x86_64-apple-darwin/bin/dcraw_emu -w ~/Downloads/fujifilm_x_t2_01.raf

real 1m13.437s
user 1m14.630s
sys 0m0.543s

I notice the full raw decode is not using any threads. Even so, I was surprised to see the full version taking 25x more user computing time.

I'm trying to get some clarity around exactly which color-spaces are used in libraw's output, as I haven't yet been able to get my colors to look "right". I see in internal/dcraw_common.cpp, there is an xyzd50_srgb matrix. Given the name, and the numbers that are listed, this looks to be using a D50 whitepoint. However, the Wikipedia article on sRGB lists a different matrix which seems to assume a D65 whitepoint.