Sorry, know nothing about OpenCV

Look into unprocessed_raw.cpp sample

It is implemented in different way:

after unpack() call, decoded raw data are placed in
imgdata.rawdata.raw_image[] - for bayer image
imgdata.rawdata.color3_image[3][] - for 3-color images
imgdata.rawdata.color4_image[4][] - for 4-color images
(only one of these pointers is non-zero after unpack() call).

So, you may access unprocessed raw values directly.

Also, if you port code from dcraw.c (or old LibRaw versions), you may use LibRaw::raw2image() call to copy data from above-mentioned arrays to imgdata.image[4][] array

See samples/unprocessed_raw.cpp as a sample of raw_image[] array access.

libraw do not contain any color->BW conversion code.
So, you may choose from two options
* convert interpolated (by libraw) rgb data to BW using your preferred formula
* or implement own raw to BW postprocessing instead of LibRaw::dcraw_process()

If you're processing data from 'converted' camera (initially color, but CFA removed, such as maxmax.com conversion), you may try to set imgdata.idata.colors to 1 after unpack() phase

In first assumption, you're right: there is ADC with fixed bit count, so data range should fit into this range.
But things are more complicated:

1. Some cameras use full pixel capacity at base (lowest) ISO, so data maximum is lower.
See this article: http://www.rawdigger.com/howtouse/rawdigger-histograms-overexposure-shapes
and inspect Panasonic histograms at low iso
(You may also find RawDigger software very useable for your work, to see raw data 'as is')

2. Some cameras alter RAW data in some way (Sony lossy compression mentioned above and many other formats with highlights compression tone curve), so data range is not same as ADC range

2b. Some cameras may subtract 'black level' (bias) before raw values recording, thus resulting in lower maximum values.

2c. Some cameras may clip data below ADC maximum value to avoid ADC non-linearity (many Canon cameras).

Using wrong maximum value in processing will result into false colored highlights: http://blog.lexa.ru/2010/03/28/taina_rozovykh_oblakov.html (sorry, it is in russian, but google translate will do the trick).

When I run the program through command prompt (*.exe located in the bin folder) it seems to work fine, I can for example load my Raw file and get 4 seperate tiff files using 4channels.exe

I've added the breakpoint at the beginning of main() inside dcraw_emu.cpp but I get the same result as before.

The target .exe does exist, I had to change a few properties in the linker so Visual Studio was able to find it. Now when I debug the dcraw_emu.cpp a blank window briefly flashes and I get the following message:

"The program '[10976] dcraw_emu.exe' has exited with code 1 (0x1)."

Yes, that's what I've been trying to do previously but I receive an error that a specified file cannot be found, here's a 30s video showing the error:

https://youtu.be/_zGPEnCnJxc

I really appreciate your help

Yes I understand, but how would I go about running the examples (i.e. 4channels.exe) in Visual Studio after installing the library?

There is no such things as a 'bit depth':

Imagine Sony ARW2 format (described in details here: http://www.rawdigger.com/howtouse/sony-craw-arw2-posterization-detection ):
- local 7-bit lossy storage
- 11-bit non-linear after lossy (de)compression
- 0..17204 data range after linearization curve (so, 'more than 14bits'

Also, advertized as 14-bit ADC (Sony A7 series), but data gapped even in shadows).

So, what bitdepth?

LibRaw provides data range (maximum value) in imgdata.color.maximum

When calling dcraw_make_mem_image (or even copy_mem_image) the libraw_processed_image_t.data order is [R (0), G (0), B (0), R (1), G (1), B (1)] where (n) is the nth pixel, right? Does this change when the output is 16 bits since a char may only be 8 bits on some platforms? If so, what does the order look like?