Hi all, I’m OpenCV & image processing newbie.
I know that OpenCV has COLOR_BayerRGGB2BGR/COLOR_BayerRG2BGR, but does it has bayer 2 bayer like BGGR 2 RGGB?
Or what’s the opencv-way to do this if it doesn’t provide builtin support.
Hi all, I’m OpenCV & image processing newbie.
I know that OpenCV has COLOR_BayerRGGB2BGR/COLOR_BayerRG2BGR, but does it has bayer 2 bayer like BGGR 2 RGGB?
Or what’s the opencv-way to do this if it doesn’t provide builtin support.
gentle ping for this question.
you’ll have to take the step through a full-res RGB/BGR image.
BGGR <> RGGB isn’t just swapping values in a 4-tuple of colors. it actually has to recalculate colors for pixels that don’t have that color already.
+-----+-----+ +-----+-----+
| R__ | _G_ | | __B | _G_ |
+-----+-----+ => +-----+-----+
| _G_ | __B | | _G_ | R__ |
+-----+-----+ +-----+-----+
that maintains the green values of those respective pixels, but the Blue in the top left one has to be interpolated from the grid, same as the Red in the bottom right. can’t just swap them. if you swapped them, you’d destroy picture content worse than mislabeled interlaced video.
Just wondering, why do you need to have conversion between BGGR <–> RGGB?
A reference if you want to know mode about demosaicing:
This is several years late, but I just stumbled onto this and I don’t think it was made clear that there is no real benefit to this transform. If you require it, it’s likely a hack.
You could demosaic and then resample to a Bayer encoded image, but both transforms will be destructive.
Alternatively, as the difference between RGGB and BGGR is a diagonal translation of the CFA, you can crop (or pad) your buffer by one pixel vertically and horizontally. That will shift the principle point and create edge artifacts where you’ve added pixels, but I think that is probably preferable to the RGGB → BGR → BGGR transform