Loading (unpacking), processing, but no interpolation

I've been using LibRaw for many years to grab the raw Bayer matrix out of files. It's worked like a charm and I love it. In some places, I'll have it not only load the raw data, but run its own debayers, but in other places, I need to be able to debayer on my own. Hence, the grabbing the raw Bayer matrix out.

As I understand it, though, if I set:
RawProcessor.imgdata.params.use_camera_wb = 1;
RawProcessor.imgdata.params.no_iterpolation = 1;
libraw_processed_image_t *image = RawProcessor.dcraw_make_mem_image(&rval);

I should have an image in memory that has not been demosaic'ed. Yet, image->colors is 3, not 1.

Is what I'm doing impossible here or can I get a processed file still in CFA format, having scaled the color channels appropriately to deal with the white balance?



no_interpolation=1 will skip

no_interpolation=1 will skip bayer interpolation pass, but all other processing to be done (data scaling, white balance, convert to output color space /useless and even wrong step for not interpolated data).

If you want to do your own data processing and use LibRaw only as data decoder (the way we use it in, for example, FastRawViewer) it may be better to access bayer data directly:

rawdata.raw_image contains pointer to bayer data array 'as decoded' (so, no black level subtracted, but unpacked and linearization curve applied).

If you prefer to use imgdata.image[][4] for demosaic you may use
raw2image() to copy raw_image in image[][4] components
subtract_black() to subtract black level

instead of dcraw_process()

-- Alex Tutubalin


dcraw_make_mem_image() will skip 4'th component from image[][4] array, so if you need to access full data for de-bayer you need to work with either raw_image or image[][4]

-- Alex Tutubalin

And second followup (several

And second followup (several notes):

'real picture' is more complex than single raw_image array.
For non-bayer images, raw_image is NULL after unpack(), but color3_image or color4_image is not null (color4 image's 4'th component usually zero, but for 4-shot files from Leaf or Pentax it is not zero).

For floating point (DNGs) float_image, float3_image, float4_image pointers are not zero (bayer, 3-component, 4-component data).

Please note, that row pitch may be greater than raw_with*(element size). real pitch is stored in imgdata.rawdata.sizes.raw_pitch and it is always in bytes (divide by 2 for raw_image to get items, divide by 16 for float4_image, etc).

Also, rawdata.*image arrays contains 'black frame' pixels, so use rawdata.sizes: raw_width/height, top_/left_margin and width/height to access image part containing real image data.

the raw2image() call handles all specifics, so look into source for details :)

-- Alex Tutubalin



Thank you for all the details! I've been using:
CFA data then from RawProcessor.imgdata.image[r*RAW_S.iwidth+c][RawProcessor.FC(r,c)]

in my code since ... well, a long time ago... to extract the unprocessed data for Bayer-matrix data. (The idea being, I do my own hot pixel / bad pixel mapping -- this is astrophotography work). When non-Bayer, I run:
red data then from RawProcessor.imgdata.image[r*RAW_S.iwidth+c][0]
green from[1], blue from [2]

I poked around in the debugger and docs last night but still couldn't see the effect of use_camera_wb. The docs (http://www.libraw.org/docs/API-notes.html#imgdata_params) say that unpack() is affected by this but no matter what the setting, the output of raw2image() seems the same.

For Bayer matrices, is there a spot where I can pull off the still-CFA encoded data but having run say black level and color scaling? Or, should I just:
and find CFA data then from RawProcessor.imgdata.image[r*RAW_S.iwidth+c][RawProcessor.FC(r,c)]


unpack() is affected by

unpack() is affected by camera_wb only in some (very rare) cases (I can not remember the details, it affects very small set of cameras, may be old Kodaks and/or foveon /old ones, before Sigma Merill).
For modern cameras unpack is not affected by color setting (but default for 'use_camera_matrix' for some cameras depends on wb settings)

subtract_black and scale_colors works with image[][4] array, so you need to call raw2image() before subtract_black().

Also, there is single call for raw2image and subtract_black:

int LibRaw::raw2image_ex(int do_subtract_black);


will put black-subtracted and white-balanced image in image[][4]

-- Alex Tutubalin

Nice and thanks! I think the

Nice and thanks! I think the only issue for having this be a general solution (and not just having me rework the source a touch - fine for me, but...) is that scale_colors is protected rather than public.

We assume that someone who

We assume that someone who uses 'parts' of dcraw_process() will subclass LibRaw :)

-- Alex Tutubalin