Bayer layout

Submitted by Sylvain on

Hi.

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...

Forums: 

dcraw_process() is 16 bit

Submitted by lexa on

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 @LibRaw LLC

Thanks again, and sorry about

Submitted by Sylvain on

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

Submitted by lexa on

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 @LibRaw LLC

Thank you.

Submitted by Sylvain on

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

Submitted by Sylvain on

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... :)
Sylvain.