Blue tint on a board camera: fix a missing ISP calibration

A board camera that frames sharply and exposes correctly but saves every frame with a heavy blue cast is not a broken sensor, and there is no film to peel off the glass. The pattern — uniform tint, crisp focus, correct brightness, present from the very first boot — points at the platform's image-signal processor converting raw Bayer data without calibration for your sensor module. This guide is for engineers bringing a board camera into an embedded system. You will prove the fault with one gray-card capture, locate the ISP tuning file, obtain one you are legitimately allowed to install, and choose a working route when no file exists. The worked example uses sample channel means of 2100, 1300 and 2900 counts so you can check every line of the arithmetic yourself.

Why does a sharp, well-exposed board camera image come out blue?

The host image-signal processor is scaling raw Bayer channels with default gains because no calibration file for your sensor module is loaded; every channel gets the same treatment, so an uncorrected sensor response can leave blue about 2x above green on a neutral target.

The sensor is telling the truth: its raw counts are honest measurements of light through the red, green and blue micro-filters. The wrong part is the conversion stage, which guesses how to rebalance those counts. When the driver has no tuning data to register, the ISP proceeds on unity gains, and whatever imbalance the module's spectral response leaves in the raw numbers rides straight into the finished frame.

Four symptoms confirm the class:

• Uniform. The same ratio holds corner to corner; there are no bands, blotches or gradients.
• Sharp. Focus and distortion are untouched, because the optics never took part in color balance.
• Correctly exposed. The histogram sits where you set it; gains are ratios, not brightness.
• Permanent. It is there on the very first frame after the first boot and never varies with exposure or gain settings.

Is it the protective film, a bad sensor, or calibration?

It is calibration in nearly every fresh bring-up with this symptom: a film or stray filter softens edges and drops contrast before it shifts color, and a defective sensor produces columns, bands or noise, never one uniform hue rotation applied to every pixel equally.

Each failure has a signature you can tell apart in a minute. A film, fingerprint or adhesive residue on the cover glass diffuses light: text edges go soft first, overall contrast drops, and a small bright source blooms. A damaged sensor announces itself spatially — dead columns, hot pixels, banding or blotches that hold the same position frame after frame. A calibration fault is the only one of the three that applies one clean, uniform color transform to a perfectly sharp image. If your peeling checks find nothing and the frame is crisp, stop suspecting the glass and go measure the channels.

A cast that flips rather than tints — red parts reading blue, blue parts reading red — is a different bug: a channel-order mistake in the pipeline, covered step by step in red and blue channels swapped: why RGB images look wrong.

What is the ISP doing between raw Bayer and a color frame?

It runs a fixed chain — black-level subtraction, per-channel white-balance gains, a 3x3 color-correction matrix, then gamma — and those gains and matrix coefficients must be measured on your sensor module, which is why an uncalibrated platform falls back to unity gains and an identity matrix.

Each photosite sits under one red, green or blue micro-filter, so the sensor hands the processor a mosaic — the Bayer pattern — with two of the three colors missing at every pixel. The ISP demosaics it, then corrects color in two steps: per-channel gains that make a neutral gray card read neutral, and a 3x3 color-correction matrix that undoes the filters' spectral overlap. Both steps need coefficients measured on the actual module, because filter dyes, cover glass and lens coatings all shift them. The camera stack normally registers those coefficients from a tuning file when the sensor driver loads. When it finds none for your module, it proceeds with unity gains and an identity matrix, and the imbalance survives to the display.

Two checks come before any tuning: confirm the stream really is raw — how to know you have a Bayer raw stream from an RGB camera — and confirm whether a processor touches the frames at all, which is what CSI camera output with no ISP explains. More color-pipeline material is collected on the cameras topic page.

How do I prove the gains are the fault with one capture?

Photograph a neutral gray card, read each channel's mean and divide by green: a calibrated ISP lands all three ratios within about 5% of 1.00, while a default-gain pipeline leaves blue far above green — 2.23x in the worked example below.

Save the frame losslessly as PNG, because JPEG chroma subsampling shifts channel means. OpenCV's documented cv2.mean call returns them in one pass:

import cv2

frame = cv2.imread('gray_card.png')           # numpy uint8 array, 3 channels, BGR order
b_mean, g_mean, r_mean, _ = cv2.mean(frame)   # per-channel means, BGR order
print(f'B/G = {b_mean / g_mean:.2f}   R/G = {r_mean / g_mean:.2f}')

On the faulted pipeline this prints B/G = 2.23 R/G = 1.62; after a correct fix it prints values within 0.05 of 1.00. The gains that neutralize any cast follow from the same three numbers, with green as the reference channel:

A ratio near 1.00 on all three channels is the pass mark for every future capture, including the check after you install the file.

Where does the ISP calibration file live and what is it called?

The override is a text file named camera_overrides.isp; the original driver package reads it from /data/nvcam/settings/camera_overrides.isp, later releases move ISP tuning into a vendor-prefixed settings directory, and a one-line search by file name settles which path your build uses.

The file carries the measured per-channel gains, the color-correction coefficients and usually lens-shading tables, all gathered at the module maker's bench. The camera stack loads it by name when the sensor driver starts, so the name stays fixed even when the directory moves between releases. If the search below returns nothing, that is the diagnosis in itself: no override is loaded and the ISP is running on defaults.

Match the driver release as well as the path: a file written for an older tuning format can load yet still misbehave, and the symptom is identical to having no file at all.

Where do you get a calibration file you are allowed to install?

From the module manufacturer's own driver and tuning package for your platform: the gains and matrix are measured on that module design at the vendor's bench, so the vendor's support or download channel is the legitimate source, and a code-search copy is not.

Ask the module maker — or the distributor you bought from — for the ISP tuning package matching your exact module and driver release, and store the file beside the driver so the pair never separates. This is not paperwork for its own sake: the coefficients encode that module's filter dyes and cover glass, so a file from a neighboring module variant can be worse than none, and a file of unknown provenance cannot be traced when color drifts six months later.

If your module-plus-platform pairing is unusual and the maker publishes nothing for it, treat that as a purchase decision rather than a debugging problem — the alternatives below all work — or contact us with the pairing and we will help you pick a combination whose tuning exists before it reaches your bench.

How do I install the override and confirm the tint is gone?

Back up any existing file, copy the vendor's camera_overrides.isp into the documented settings path, reboot so the ISP reloads tuning, then repeat the gray-card capture and expect all three ratios within about 5% of 1.00.

1. Record the fault first: gray card, PNG, and the B/G and R/G ratios from the test above.
2. Fetch the vendor's tuning package for your module and driver release, and note the path it documents.
3. Back up whatever currently sits at that path with a .bak copy, in case you need the original format back.
4. Copy the vendor file into place under the exact name camera_overrides.isp, readable by the camera service account.
5. Reboot, so the sensor driver reloads and the ISP picks up the tuning at start-up.
6. Repeat the gray-card capture. All three ratios within 0.05 of 1.00 means calibrated; log the numbers with the date and driver version.

If the camera fails to appear at all after a reconfiguration, rather than appearing tinted, that is driver selection — the walk-through of a camera loading the wrong sensor driver covers that adjacent fault.

No tuning file exists for your platform: what are the working alternatives?

Three routes work — capture raw and apply your own measured gains and color matrix, buy a camera whose maker publishes tuning for your platform, or go mono, because a monochrome sensor needs no white balance and this failure class cannot occur.

Route 1: capture raw and calibrate yourself

Save the sensor's raw frames — the walk-through of ISP driver setup and capturing raw sensor frames on a single-board computer shows the capture end to end — then apply your own gains and matrix in the debayer step. A gray card fixes the gains in one capture; a 24-patch color chart fixes the 3x3 matrix. That is a solid answer for one fixed station. Across a fleet it becomes calibration management: run the gray-card test on every unit at commissioning and track the gains, exactly as the multi-camera white-balance consistency test lays it out.

Route 2: buy a module whose maker publishes tuning for your platform

Makers list which platform releases their tuning packages cover; make that list a purchase criterion and the file question answers itself at the ordering stage. Weigh interface, shutter type and resolution in the board camera finder or the camera step of the configurator, check what to verify when a camera module's interface must fit before committing a module to a carrier board, and read the wider trade-offs in board-level camera selection for embedded vision machines.

Route 3: drop color and go mono

An inspection that never judges hue needs no color pipeline at all. The MV-CB016-10GM-M-W is a 1.6 MP mono GigE board camera with a global shutter and an M12 lens mount, and the MV-CB060-10UM-B is a 6 MP mono USB3 model, IMX178, rolling shutter, bare board on a 1/1.8" sensor. Neither has a color filter array, so there is nothing to white-balance and this fault cannot occur. Browse the board-level cameras for mono parts at other resolutions.

When the station must stay color, carry the same rule into the part choice: pick a module whose maker documents tuning for your platform before you design it in. LS-BCM-0056 is a 12 MP GigE board camera with 1.6 μm x 1.6 μm pixels, a C-mount on a 1/2" sensor and a rolling shutter — a color-capable module for stations that must keep hue in the measurement.

When is a blue cast genuinely hardware or lighting?

When it fails the uniformity test: a blue-dominant light tints the gray card you can also see with your own eye, filter-mosaic damage shows as blotches, and a dying sensor shows columns or noise — one capture under a known-neutral lamp separates scene color from pipeline color.

The gray card is the arbiter because it is the one object in the scene whose correct appearance you know. If the card itself looks blue under the station's lights, the illumination is blue-dominant — colored LED fixtures and daylight through glass both do it — and no calibration file should compensate; fix the light spectrum instead, or add a compensating stage only where the light is fixed permanently. If your pipeline also runs host-side white balance, pin down what it applies with the method in programmatic camera white balance control, or it will mask the ISP numbers.

Spatial faults point at hardware: blotches that hold still frame after frame suggest damage to the color-filter mosaic, and dead columns or rising noise make the module a warranty case rather than a tuning project. Two neighboring faults merely look similar and have their own fixes: a color camera that outputs gray at all is usually a pixel-format default, covered in why a GigE camera shows no color image, and a blank preview from an unrecognized Bayer format is the subject of the unsupported Bayer pixel format guide.

The decision, case by case: uniform ratios on a gray card — install the vendor tuning file. No file published for your pairing — self-calibrate a fixed station, buy a tuned pairing, or go mono. Card blue to the eye — fix the lighting. Blotches or columns — replace the module. To move from diagnosis to parts, take the camera route through the configurator linked above, or send us your module-plus-platform pairing and we will help you choose hardware whose tuning already exists.