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.

Hello,

I am having some issues opening images I took on my Canon 5D Mark IV on my Arch Linux machine with software such as Rawtherapee and UFRaw (not with darktable), which leads me to conclude that the issues are with libraw.
Im using libraw version 0.18.7-1.

The issue I'm having is that the images get messed up upon opening. I seems as if the image is beeing divided into some slices and then put back together in the wrong order. I attached an example image to this post.

Can anyone help me with this? Do you need any further information about my machine?