ISP override file not taking effect: name, permissions, endings

You renamed the tuning file to camera_overrides.isp, copied it into the settings directory, restarted — and the image did not change. No error, no log line, just the same default image. That silence is normal: when the loader cannot find, read or parse the file, it falls back to built-in ISP parameters and carries on as if the file did not exist. Three checks decide whether an override file loads: the exact name and directory, permissions the capture service can read, and Unix line endings. Each takes one command to test and one command to fix. Work through them in order, restart between tests, and finish with one extreme setting that proves the file is applied.

What "not taking effect" actually means

The symptom is a still image: you deploy the file, restart, and every frame looks the same as before. There is no error because none is defined — a missing, unreadable or unparsable file is treated the same way as no file at all.

Start by establishing the baseline. Retire the file and compare frames with and without it:

mv /var/nvidia/nvcam/settings/camera_overrides.isp \
   /var/nvidia/nvcam/settings/camera_overrides.isp.bak

Restart the capture application and save a frame. If the image with your file and the image without it are the same, the loader never read your file — work through the checks below. If they differ, the file loads and the problem is the values inside it, not the delivery; go straight to tuning with larger deltas.

One exclusion first: if the wrong sensor driver is bound to the camera, no override file can help. Check the capture stack with camera loads the wrong sensor driver: read dmesg, fix the overlay before touching tuning files.

The four checks at a glance

Four checks, four commands; the sections below give each one its test and its fix.

Check 1: the exact name in the exact directory

The loader reads one global override name: camera_overrides.isp, all lowercase, in /var/nvidia/nvcam/settings/. A module-specific file in the style of camera_sensor.isp — the name your camera kit ships with — is not the global override, so leaving it in place under its own name does nothing. Linux filesystems are case-sensitive: Camera_overrides.isp and camera_overrides.ISP both miss.

ls -l /var/nvidia/nvcam/settings/

Read the listing for exact spelling and case. If the file sits there under another name, move it into place:

mv /var/nvidia/nvcam/settings/camera_sensor.isp \
   /var/nvidia/nvcam/settings/camera_overrides.isp

camera_sensor.isp above stands in for whatever name your kit uses. Restart and compare frames again before moving to the next check — a fix confirmed is worth more than three fixes assumed.

Check 2: permissions the capture service can read

The capture application runs as an ordinary user, not as root. A file you copied with sudo can land readable by root alone; the loader opens it, gets permission denied, and uses defaults without a message. The permission sets that work are 664 or 644 — both end in world-read, so the service user can read the file either way.

chmod 664 /var/nvidia/nvcam/settings/camera_overrides.isp

Prove it from the account that runs capture: switch to that user and read the file back — the first five lines are enough. If that account cannot read the file, the loader cannot either, whatever root's own view says.

Check 3: Unix line endings

A file edited on Windows ends every line with carriage return plus line feed (CRLF: bytes 0x0D 0x0A). The parser on the board expects Unix endings — a single line feed, 0x0A — and content it cannot parse is content it ignores, with the same silence as every other failure.

Dump the first bytes on the board and look at the line ends:

od -c /var/nvidia/nvcam/settings/camera_overrides.isp | head

Every line should end with \n alone; a \r before it is the Windows ending. The fix belongs at the source: set your editor to save with Unix (LF) line endings and keep the file in your repository that way. For a file already on the board, convert it in place (dos2unix handles it), then restart and compare again.

Restart before you judge any fix

The override is read when the capture session starts, not while frames stream. Edit, restart, compare — in that order, every time. A correct fix can look like a failure when nothing re-read the file, and one restart of the capture application is usually enough.

If the file still seems ignored after a clean restart, restart the camera service itself or reboot the board. A cached copy keeps steering the pipeline otherwise, and you will chase permissions that were already right.

Prove delivery with the extreme-value test

Values near the defaults produce an image you cannot tell apart from the default image — which reads exactly like a file that never loaded. Prove delivery instead of guessing: set one parameter to an extreme, save, restart and compare frames. Minimum saturation or a gamma far from 1.0 makes the change impossible to miss. Then set your real values; if the image with them matches the retired baseline, your values are close to the defaults, not ignored.

Make the deploy itself checkable: hash the file in your repository, hash the file on the board, and compare. A copy that differs is a copy that failed.

Tuning quality — which parameters move image quality and by how much — is its own subject; embedded ISP tuning: why sensor plus software sets image quality starts there. Defaults mislead in other ways too: ISP default settings that look like compression artifacts is the same lesson one layer up.

One global file steers every camera on the board

camera_overrides.isp is global: every sensor the host ISP processes receives those parameters, shadowing any per-camera tuning the driver would otherwise apply. On a single-camera bench that is what you want. On a rig with two or more cameras, one file steers them all — and a leftover test file keeps steering every camera you plug in later. Keep exactly one intentional file in the settings directory and write down in your deploy notes which one it is.

That global behavior is also the fastest confirmation available: plug in a second camera of a different type. If its image changes too, the file is live.

Deploy the file instead of hand-copying it

Hand-copying is where the three failures come from: the wrong name typed once, a sudo copy with tight permissions, an editor that slips CRLF back in. Put the fix in provisioning so it cannot drift. One deploy step should copy the file from the repository, set chmod 664, print its checksum into the build log, and restart the capture application. Store the file with LF endings in the repository and re-check after every round trip through a Windows machine, since archive tools and some editors reintroduce CRLF.

The failure shape — a value written somewhere its consumer never re-reads — runs across automation, not just camera files; the root causes and checks for PLC data-block values that do not take effect follow the same pattern: who wrote it, who can read it, and whether the consumer was restarted.

The decision: fix the host ISP or move tuning into the camera

The override-file route is worth repairing when you keep a raw CSI module on an embedded board: the sensor ships no ISP of its own, so the host does the processing — see CSI camera with no ISP: what raw sensor output means. The checks above close that path completely: exact name, 664 permissions, Unix endings, restart, proven with one extreme setting.

If you are still choosing hardware, the quieter route keeps tuning in the camera. Set exposure, gain and white balance in the camera's own settings and save them to a user set — save and load camera settings to a user set — so settings survive reboots without any filesystem work. If you would rather process raw frames in your own code, weigh where that work runs with embedded ISP versus GPU for raw image processing on an SoC. For the module choice itself, the board camera evaluation checklist lists what to measure before you commit.

Three catalog parts make up that kind of node:

• The MV-CB016-10GM-M-W is a 1.6 MP mono board camera with an IMX296 sensor, global shutter and M12 mount on GigE.
• The LS-BCM-0003 is a 3.1 MP USB3 board camera on a 1/1.8" IMX252 global-shutter sensor running 120 fps.
• The MV-VC2140-128G40-1T hosts the capture stack with 8 GB of RAM, a 128 GB SSD plus a 1 TB hard drive, two USB 3 ports and four built-in light channels.

The decision by case:

• File never loaded: exact name camera_overrides.isp in /var/nvidia/nvcam/settings/, chmod 664, Unix line endings, restart, then prove with the extreme-value test.
• File loads but nothing visibly moves: your values sit near defaults — re-tune with large, measured deltas against the camera_overrides.isp.bak baseline.
• No override file and no tuning tool: keep exposure, gain and white balance in the camera's settings and the user set; do the remaining color work in your own image-processing code.
• Multi-camera rig: one global file per board; retire it to camera_overrides.isp.bak for any camera that should run defaults.

If you are speccing that node now, start from vision controllers and board-level cameras, or go straight into the camera configurator. Neighboring bring-up faults — drivers, capture sessions, vanishing settings — are collected on the systems topic page.