Add new comment

Theoretical part:

Theoretical part:
1) Many (not all) digital cameras have 'masked' (opaque) pixel areas (or black frame), so image area is less than full sensor area. These black pixels may be used for black level calibration, banding suppression, etc (the area that may be used is specific for camera model, so we do not discuss it now).

2) imgdata.rawdata.raw_image[] array contains full sensor area decoded from RAW files. It need to be cropped on processing to exclude black frame.
There are several variables in imgdata.sizes that describes sensor area:
- raw_width, raw_height - full sensor size.
- raw_pitch - row pitch (in bytes! so divide it by 2 for raw_image, by 6 for color3_image) in rawdata.* pointers. Usually raw_pitch is just raw_width *2, but this not always so (eg. if file decoded via DNG SDK).
- top_margin, left_maring - pixel coordinates for top-left image visible area
- width, height - size of visible area (there is some special case for Fuji Super-CCD sensors used on very old cameras; let's drop it).

So, there are two ways to use:

A. Continue to use imgdata.rawdata.raw_image array w/o copying it into imgdata.image.
You'll need to change your all-pixel loops to something like (i'll skip some imgdata.sizes prefixes to shorten statements...)
// srow - source row, drow - dest row, same for col

for(srow = imgdata.sizes.top_margin, drow=0; srow <= top_margin + height; srow++, drow++)
for(scol = imgdata.sizes.left_margin, dcol=0; scol <= left_margin+width....
buffer[srow * width + scol] = imgdata.rawdata.raw_image[drow*raw_pitch/2 + dcol];

B. Use LibRaw::raw2image() call:
This call will allocate imdata.image[..][4] array with 4-components per pixel.
After this call, 3 out of 4 components are zero, and only image[row*width+col][COLOR(row,col)] is not.

If you perform debayering in your own code, raw2image may be not optimal choice because of extra memory use. You may consider de-bayering in place (directly in imgdata.image[][4] array) to save memory.

Feel free to ask if you need additional explanations

-- Alex Tutubalin @LibRaw LLC