So calling dcraw_process() with just the settings written above will create a RGB image without any further kind of processing? Thanks!

thanks

I know this is old, but 17barski, do you know what specifically you changed or set things to? I'm having the same basic problem where I set dcraw_emu to "Set as Startup Project", compiled everything, saw that dcraw_emu.exe and libraw.dll are in the debug folder, and still get errors saying that the files don't exist. Thanks

Yeah. I've also did your test (same image), it produces a 16bit ppm.
I guess I need to clean up my code and see where this behaviour comes from.

Sure! Thanks

Thanks!

what if a manual WB is chosen and a -magenta is entered (i don't think most of calibrated in CC)? will this give a similar result?

for example, Sony will allow such a compensation. i have already, through my raw processing, set this as my standard, as i shot at one temperature with -magenta, and then adjust the proper temperature during raw processing.
At a first glance, presuming the filter blocks only the green channel, this means that the red and the blue channels should be exposed one stop better. However, the blue and red channels are sensitive to a pretty wide range of spectrum. That's why the actual per channel exposures were changed less than that, as it is obvious when looking at the white balance coefficients.

Not so. It looks like you've divided data by 256 (than recover it back?). This step is missing
In your code:

unsigned int luminosity = ((unsigned int)iProcessor.imgdata.image[i][0] * 2 + (unsigned int)iProcessor.imgdata.image[i][1] * 3 + (unsigned int)iProcessor.imgdata.image[i][2])/6;
		data[i] = luminosity;

data should be in 16bit (64k) range.
Next step:

jpegData[i] = unsigned char((data[i]*255)/iProcessor.imgdata.color.maximum);

Data is upscaled to 24 bit?

imgdata.image is indeed scaled in LibRaw::scale_colors() call

For your test: what contained in data array?

color.maximum is 'maximum data value permitted by data format'.
In some cases, real maximum is smaller.
There is color.data_maximum field, but it is filled /based on real data/ on raw2image (or dcraw_process) stage, so not available just after unpack().

In your example you compare raw data maximum (so, data range of raw data) with processed values.
This is not correct, because output data are scaled to use full data range (16 bit).

1st:

With LibRaw 0.18 (currently in Beta1, Beta2 to be published soon),
in-camera WB multipliers are extracted into
imgdata.color.WB_Coeffs[256][4];
and
imgdata.colr.WBCT_Coeffs[64][5];

This extraction is made for all RAWs with embedded color presets, not only Canons.

1st array (WB_Coeffs) is indexed with EXIF Colorsource, so to get, for example, D65 preset, you need to inspect WB_Coeffs[21] for non-zero values.
2nd array (WBCT_Coeffs) is filled from 0 to 63:
WBCT_Coeffs[i][0] is color temperature (from camera settings)
and
WBCT_Coeffs[i][1..4] are WB coeffs.

There is no automated procedure to copy these values into processing, so one needs to examine array data (or, simply, fill WB drop-down with these values), than copy needed WB Coeffs into
imgdata.params.user_mul[] to use on dcraw_process() stage.
So, processing sequence is
LibRaw::open_file();
LibRaw::unpack();
... examine WB_Coeffs/WBCT_Coeffs
.. copy needed into user_mul
LibRaw::dcraw_process();

(and, sure, you may call dcraw_process() multiple times without unpack() of same file)

2nd:
WB Coeffs to CCT and back is not very complex (look into Adobe DNG SDK sources for sample code), but results of this procedure depends on color profile and camera calibration data used.
So, calculated CCT/Tint will, most likely, not compatible with other programs (or, even, with in-camera WB setting by CCT).