Hi folks,
This is my first rodeo using libraw to read RAW files and so apologies in advance if these questions are very trivial.
I am trying to determine the Bayer layout of the RAW images in some sample images I have. It appears that using the filter field in conjunction with cdesc is the way to go. Please correct me if I am mistaken.
I also tried to call COLOR function to confirm my understanding. But, the results I am getting do not appear to be consistent.
My workflow is below:
LibRaw rp;
rp.open_file(fileName);
rp.unpack();
% Inspect rp.imgdata.idata
rp.raw2image();
int c = rawProcessor.COLOR(0, 0);
c = rawProcessor.COLOR(0, 1);
c = rawProcessor.COLOR(0, 2);
c = rawProcessor.COLOR(0, 3);
c = rawProcessor.COLOR(1, 0);
c = rawProcessor.COLOR(1, 1);
c = rawProcessor.COLOR(1, 2);
c = rawProcessor.COLOR(1, 3);
For a sample DNG file, I got
cdesc = "RGBG" and filters = 3789677025. This translates to a G2 B R G1 pattern. I derived this by examining the 32-bit value 2 bits at a time. The COLOR outputs based on the code above are in the order 1, 0, 1, 0, 2, 3, 2, 3 which dont appear to match the pattern derived from filters and cdesc.
Similarly for a NEF file, I got
cdesc = RGBG" and filters = 3031741620. This translates to B G2 G1 R pattern. The COLOR outputs based on the code above are in the order 0 1 0 1 3 2 3 2 which dont appear to match the pattern derived from filters and cdesc.
Is cdesc and filters the correct way to derive the CFA Pattern?
Appreciate any help.
Dinesh
cdesc is not a pattern, it is
cdesc is not a pattern, it is just indication (RGB or CMYK or CMYG, etc), so for all four R-G-B-G2 orders possible cdesc will be set to RGBG
-- Alex Tutubalin @LibRaw LLC
Followup:
Followup:
if you need to know *color* for given pixel, not 'color index', use value returned by COLOR() as index in cdesc.
-- Alex Tutubalin @LibRaw LLC
Thanks!
Alex,
Thanks for your reply. I will use the COLOR function to serve as an index into the cdesc.
I actually figured out what I was doing wrong. I got the bit order of the filters field wrong. It says that filters represents an 8x2 area with 2 bits per pixel. I assumed that bits 31-30 and 29-28 corresponds to the top two pixels in this 8x2 area. But it turns out that bits 0-1 and 2-3 correspond to the top two pixels in this 8x2 area. I tested this hypothesis for a bunch of files and it seems to hold. Hope my understanding this correct.
Also, what does the colors field in the libraw_iparams_t represent?
colors is color (component)
colors is color (component) count really :). It may be 3 or 4 even for RGB(G) files if two greens are different.
For 2x2 bayer images, color (index) is:
(imgdata.idata.filters >> (((row << 1 & 14) | (col & 1)) << 1) & 3);
-- Alex Tutubalin @LibRaw LLC
Sounds good
Alex,
Thanks for the clarification. Does it mean that if colors == 3, then the cam_xyz is effectively 3x3 matrix?
Dinesh
Yes.
Yes.
And many (not all) color matrices in adobe_coeff() are 9-items (3x3), not 12 (4x3).
Also, for 3-color images 4th component is moved to image[][2] before interpolation step.
-- Alex Tutubalin @LibRaw LLC