You plugged an RGB-IR camera into a newer laptop, opened the camera's own GUI, and found image modes labeled IGGB, GBIG, GIBG, BGGI, GIRG, RGGI and GRIG with no explanation attached. Then an IR LED made a face glow in the color image, and the stream died with a USB timeout on the new machine while the old one ran the same camera all day. All three behaviors trace back to how an RGB-IR sensor is built. This explainer gives you the meaning of the mode names, a working method to split a raw buffer into RGB and IR, and a fix order for the timeout.
The mode names are color filter array patterns
IGGB and its six companions name the sensor's color filter array: the mosaic of dye filters physically printed over the pixel grid. Each word describes one 2 × 2 block of pixels, letter by letter in reading order — first letter top-left, second top-right, third bottom-left, fourth bottom-right. Infrared gets its own letter; red, green and blue keep R, G and B.
A standard color sensor repeats a Bayer quad of red, green, green, blue; telling that arrangement apart in a raw stream is covered in Bayer raw stream from an RGB camera. In all seven RGB-IR modes the two green pixels hold one diagonal of the quad, and infrared shares the other diagonal with a single red or blue pixel. Infrared takes over one chromatic slot; green never gives one up, because the green pair carries most of the luminance detail.
| Mode | Top-left | Top-right | Bottom-left | Bottom-right |
|---|---|---|---|---|
| IGGB | IR | Green | Green | Blue |
| GBIG | Green | Blue | IR | Green |
| GIBG | Green | IR | Blue | Green |
| BGGI | Blue | Green | Green | IR |
| GIRG | Green | IR | Red | Green |
| RGGI | Red | Green | Green | IR |
| GRIG | Green | Red | IR | Green |
Selecting a mode changes nothing on the sensor; it tells the decoding software where each pixel's value belongs. The wrong one loses no data, but infrared samples land in a color plane and colors smear into the IR plane — the checkerboard signature described in RGB IR mosaic decoding artifacts. The list exists because one GUI drives many sensor variants; the physical pattern is fixed when the sensor is made.
Counted from zero at the frame's top-left, that one line maps any raw sample to its plane. It is the whole trick behind the separation below.
What the infrared pixel costs in sampling
Each quad now delivers two green samples, one infrared sample and one sample of a single chromatic color. On the 5 megapixel class of USB RGB-IR camera, the per-frame counts are:
- 5,000,000 pixels ÷ 4 = 1,250,000 infrared samples
- 5,000,000 pixels ÷ 4 = 1,250,000 red-or-blue samples
- 5,000,000 pixels ÷ 2 = 2,500,000 green samples
Left as samples, the infrared image is quarter resolution: a 5 megapixel sensor hands you a 1.25 megapixel IR frame. Published RGB-IR algorithms take both routes — interpolated full-resolution RGB and IR, or a straight quarter-resolution IR image. The quieter cost sits in color: one chromatic sample per quad means red (or blue) reconstruction leans harder on neighboring quads than Bayer does, the same remosaic trade that governs Quad Bayer 4-cell sensors.
Because infrared samples sit at half the linear density of the grid, an inspection that needs a given pixel count in its IR image needs four times that count from the sensor. Size the task with the camera resolution calculator, then multiply by four.
Splitting the raw buffer into RGB and IR
- Assign each pixel to its plane. Apply the quad formula with your sensor's mode string and write every value into the IR, R, G or B sample plane.
- Keep the planes sparse at first. The green planes hold diagonal samples; the IR and chromatic planes hold checkerboard samples. The geometries differ, so do not reuse a Bayer kernel unchanged.
- Interpolate to full resolution. Bilinear interpolation is enough to start; upgrade once the images look right.
- Add color processing yourself. White balance, gain and any infrared compensation belong after separation, in your own code.
The reference implementation for this class of camera ships as a Python utility rather than a C++ demo, but the routine is pure indexing, so a port is direct. Two limits hold: the separation splits components and does nothing else — no color correction, no pixel shifting — and it cannot remove infrared from the color channels, because that light is already inside the color pixels' own response.
If a driver demosaics before your code sees the buffer, take the raw endpoint instead, the approach laid out for Bayer decode from raw image data when the driver demosaics anyway. On the LabVIEW side, plane extraction needs the right image type, explained in IMAQdx extract color planes.
Why the IR LED still brightens your RGB image
It is supposed to. The color pixels are silicon photodiodes under dye filters; the dyes attenuate near-infrared but do not block it, and silicon keeps responding out to about 1100 nm. Every conventional color camera solves this with an IR-cut filter ahead of the sensor. An RGB-IR camera cannot: its infrared channel lives on that transmitted near-IR, so the filter would blind the very channel the sensor exists to provide. The raw pipeline adds nothing back — no AWB, no ISP stage subtracts the infrared contribution.
Two clean responses:
- Color-only run: put a visible-passing IR-cut filter over the lens, with common cutoffs near 650 nm. The IR channel goes dark, which is fine for that capture.
- Simultaneous RGB and IR: filtering is out by construction. Calibrate instead — image a matte target under controlled visible and infrared illumination, measure how much IR each color channel picks up, and subtract it per channel, or use a published RGB-IR image-formation model that solves infrared removal and demosaicing in one pass.
Worked example: USB3 bandwidth for a 5 MP RGB-IR stream at 30 fps
Inputs: a 5 megapixel sensor, the class of camera in question; raw delivery as 16-bit words, 2 bytes per pixel, the common raw format for these cameras — a 10-bit packed stream halves every number below; 30 frames per second as the rate under test.
- 5,000,000 pixels × 2 B/pixel = 10 MB per frame
- 10 MB × 30 fps = 300 MB/s
- 300 MB/s × 8 bit/B = 2,400 Mbit/s ≈ 2.4 Gbit/s
The basis: USB 3.0 clocks 5 Gbit/s on the wire, and its 8b/10b encoding leaves 4 Gbit/s — about 500 MB/s — of payload; healthy ports sustain roughly 350–450 MB/s. At 300 MB/s the stream consumes 67–86 % of a working link. It survives alone on a good root port, and it dies when the controller is shared or aggressive with link power management — which is why one laptop streams all day and its newer sibling drops after a few seconds.
What moves the number: 10-bit packed data gives 5,000,000 × 1.25 B × 30 = 187.5 MB/s, and halving the rate to 15 fps gives 10 MB × 15 = 150 MB/s.
Decision: hold sustained demand under about 200 MB/s on any machine that has already thrown this timeout, and give the camera its own root port. At 5 MP in 16-bit raw that means 15 fps, not 30; keep 30 fps only on a dedicated controller you have streamed for hours without a fault.
The fix order when the stream dies after a few seconds
The support case behind this explainer had a twist worth keeping: an outdated configuration file with wrong image-format settings produced errors of its own and made the mode list meaningless. Work the fixes in order.
- Load the supplier's current configuration file for the sensor. A stale file mislabels formats before anything else applies.
- Cut the frame rate until the arithmetic above sits under 200 MB/s.
- Power the camera off and on from the GUI; a wedged endpoint after a timeout often clears only that way.
- Shorten the USB cable. The bench cable for this test can be a high-flex one rated for drag-chain use:
A machine that sustains the full rate all day proves the camera, its configuration and its cable — treat the failing machine as the fault domain. Move the camera off hubs onto its own controller using the budgeting method in USB hub drops camera frame rate, and switch off the host's USB power saving, the power-options setting that parks idle ports. Cable length against data rate is the subject of USB-C cable timeouts on a USB3 camera, and hunting a stable port is covered in diagnosing a USB camera timeout across host ports.
When one RGB-IR camera is the wrong answer
An RGB-IR sensor earns its keep when the two channels must be pixel-registered and simultaneous: face anti-spoofing, driver monitoring, gesture and eye tracking. One sensor gives perfect registration, one lens, one capture, one cable — exactly what a two-camera rig cannot promise without calibration.
It is the wrong answer for metric color. When color values must mean something — print checks, coating shades, food grading — under lighting you do not fully control, invisible infrared shifts the numbers, and you cannot filter it out without killing the IR channel. There, run a color camera behind an IR-cut filter and add a separate infrared camera when the IR channel still matters; both live among the infrared cameras and the wider area scan cameras. No CFA sensor images heat either: silicon stops responding near 1100 nm, so thermal work needs a thermal sensor.
A dedicated infrared camera removes the cross-talk by construction, because no color dye stands over its pixels:
- Sensor format
- 1/1.2"
- Lens mount
- C-mount
- Interface
- GigE
- Resolution
- Up to 3 MP
The LS-IRC-0029 is a 0.3 MP global-shutter short-wave infrared camera with 15 μm × 15 μm pixels behind a C-mount. Pair a sensor like it with a standard color camera — through a beamsplitter for simultaneous capture, or alternating exposures when the scene holds still.
Checklist before you build on an RGB-IR sensor
- Fix the mode before anything else: current configuration file first, then the dark-scene IR-remote test.
- Decide the IR resolution you ship: quarter-resolution samples or interpolation to full frame, with the processing budgeted.
- Plan color processing yourself: the camera supplies no AWB, no ISP and no infrared subtraction.
- Keep sustained USB demand under about 200 MB/s on shared machines, and give the camera its own root port.
- Choose the filter strategy per run: IR-cut for color-only work, calibration for simultaneous RGB and IR.
- Read any timeout seconds into a stream as a host-link fault: lower the rate, power-cycle, shorten the cable, in that order.
When the camera choice is still open, size it in the camera configurator or browse the camera finder; more sensor-level explainers sit on the cameras topic page. For a specific pairing of color and infrared cameras, send the task details through the contact page.
Questions
Which of the seven image modes should I select for my sensor?
The one matching the filter mosaic physically printed on your sensor, normally the mode named in the supplier's current configuration file for that model. Confirm it in one minute: darken the scene, aim a near-IR remote at the lens, and step through the seven modes; the correct one puts the remote's flashes in the IR plane and leaves the color planes flat. A wrong mode loses no data and harms nothing; it only mislabels pixels.
Why does an IR LED still brighten the RGB image after separation?
Because the color pixels themselves respond to near-infrared, the dye filters attenuate it but do not block it, and the camera cannot carry an IR-cut filter without blinding its own IR channel. No AWB or ISP stage exists to subtract it. The effect grows with IR intensity and with exposure time, so it is worst in dim rooms where exposures lengthen. Add an IR-cut filter for color-only runs; calibrate and subtract for simultaneous capture.
Does the RGB-IR separation routine also color-correct the RGB output?
No. It assigns each pixel to the RGB or IR plane and stops there: no white balance, no color correction, no pixel shifting. The reference implementation ships as a Python utility rather than a C++ demo, but it is pure indexing, so a port is direct. Run your own gains and white balance after separation, and your own infrared compensation when the color channels need it.
Why does the camera stream for a few seconds and then report a USB timeout?
That signature points at link bandwidth or stability on that machine's USB controller, not at image formats: transfers succeed until a bulk transfer misses its service window and the host gives up. Lower the frame rate until the byte rate fits, power-cycle the camera from the GUI, then try a shorter cable and a dedicated root port. A second machine streaming the full rate all day proves the camera, configuration and cable.
Can one RGB-IR camera replace a color camera plus a separate infrared camera?
Yes when the channels must be pixel-registered and simultaneous, such as anti-spoofing, driver monitoring or gesture tracking, since one sensor gives perfect registration with one lens and one cable. No when color must be metric: the color channels carry IR you cannot filter out, and the single chromatic sample per quad halves color sampling density. There, run a color camera behind an IR-cut filter plus a dedicated infrared camera, and calibrate the two viewpoints.

