Bayer layout


I'm trying to do my own processing: as far as my tests are correct, calling dcraw_process() do the whole job and produces a 8bit image.

I want to get the full bits, so I guess I have to stay with raw2image().
It seems that calling raw2image() gives us a non demozaised image, r, b, and twice g, and that just after a call to raw2image(), the second g cannot be ignored.

Can you confirm that?

Also, is there any way to know the layout of this r, g, b, g2 values? Which one is top-left, which one top-right, and so on? I guess this may change from camera to camera...


dcraw_process() is 16 bit

dcraw_process() is 16 bit internally. Processing result is scaled to 8 bit (if asked) on output routines.

raw2image converts from bayer data (flat, 1 value per pixel) to 4-component image[][4]. Only one component of image is non-zero after raw2image. This is NOT demosaiced image, but data prepared for demosaic (this format is back-compatible to old LibRaw versions, that's why raw2image call is provided).

To get color index (index of non-zero element in 4-component pixel) use COLOR(row,col) call.

-- Alex Tutubalin

Thanks again, and sorry about

Thanks again, and sorry about the false assumption that dcraw_process() was 8 bits...

I noticed the "only one of rgbg is not null for each pixel" thing... Why is that so?
Could it be that my 16MPixels camera would in fact be a camera with 4M realPixels (16M subPixels, each of them being either r, g or b), and not a 16*4M subPixels camera?

Yes, in bayer cameras each

Yes, in bayer cameras each pixel is monochrome (R, G, or B). Also, in 2x2 bayer pattern (two green pixels, one R and B), two greens are usually on different ADC channels, so it is safer to treat them as separate channels (G and G2) with different black levels.

-- Alex Tutubalin

Thank you.

Thank you.

There seem to be quite a few tricks behin all that. So I think I'll stick with using dcraw processing first... ;)

I've seen in this comment

I've seen in this comment that half_size is lossless for bayer cameras.

Does that mean that the default demosaicing algorithm (LGPL licenced) in libRaw is as simple as what half_size does (regrouping pixels by groups of 4)?
Or does dcraw_process() use a more evolved algorithm? If yes, what is this algorithm? DCB?

Thanks... :)