Camera settings saved but not applied at open: fix the locale

You set the video mode, exposure and gain in the camera driver's settings utility, saved the profile, and the utility shows your values every time. Then your program opens the camera and the first frame arrives at full resolution with default exposure. That is a silent profile-load failure, and on a PC with a comma-decimal regional format the usual cause is a decimal-separator mismatch between the settings file and the code that reads it. Here you get the two tests that confirm the cause in minutes, the arithmetic that separates it from the other reasons a saved profile does not load, and the fix that makes camera start-up independent of the OS regional format.

The symptom: the file is right and the camera ignores it

A profile that fails to load has a precise signature. The settings utility shows your saved values. The settings file on disk contains them. The open call in your program raises no error. And the first grabbed frame comes out at the camera's defaults: in one real case, a USB camera profile configured for 352 × 288 pixels at 30.00 fps delivered 1280 × 1024 frames in 32-bit RGB. Setting the same values through a property node at runtime works normally, which narrows the fault further: the interface, the cable and the camera are fine, and only the stored profile is skipped at load time. Values read back during the session are live and correct; it is the file on disk that never reaches the camera.

The cause: two decimal conventions in one text file

The settings file is plain text, and its numbers carry a hidden locale. The writer, which is the settings utility, stores decimal values in US form with a point: 30.00, 0.5, 20.00. The reader, which is the open and attribute-load code in the driver, parses the file with the OS regional format. On a German-format system the decimal mark is a comma and the point marks thousands, so "30.00" parses as 3000 or fails outright. The reader skips the value it cannot make sense of and carries on, which is why nothing raises an error.

The damage is selective. Every value stored with a decimal point dies; plain integers survive, which is why a gain of 6 can stick while a frame rate of 30.00 does not. Drivers that switch to a neutral locale for these files avoid the problem on most PCs, and the failure survives on particular combinations of OS language, regional format, driver version and the runtime's own locale settings. The file itself is intact, so reinstalling the driver changes nothing.

Confirm it with two tests

1. Read the file against the format. Open the settings file in a text editor and confirm the values are stored with points, 30.00 rather than 30,00. Then check the OS regional format in the system settings. A dot-decimal file on a comma-decimal PC is the mismatch, visible before you run anything.
2. Flip the format once. Set the regional format to English (United States), restart your program and open the camera. If the saved profile now applies, the locale parse was the cause. Restore the original format afterwards; the permanent fix belongs in your code.

Worked example: a 352 × 288 profile that opens at 1280 × 1024

Inputs, each with its source:

• Configured video mode: 352 × 288 pixels, I420 colour, 30.00 fps — from the saved profile shown in the settings utility.
• First captured frame: 1280 × 1024 pixels, 32-bit RGB — from the running application after the open call.
• Stored mode text: 30.00 fps, written with a decimal point — read from the settings file in the text editor.
• OS regional format: German, decimal mark ",", thousands mark "." — from the system's region settings.

The rule in words: a profile that loads leaves the camera in the configured mode; a camera that opens at its default, the largest mode the sensor offers, means the profile failed before the first attribute reached it. The pixel-count ratio separates the two cases.

The arithmetic:

• Configured pixels: 352 × 288 = 101,376 px.
• Opened pixels: 1280 × 1024 = 1,310,720 px.
• Ratio: 1,310,720 ÷ 101,376 ≈ 12.9.
• Bandwidth check at the configured mode: I420 stores 1.5 bytes per pixel, so 101,376 × 1.5 = 152,064 bytes per frame, and 152,064 × 30 = 4,561,920 bytes per second, about 4.6 MB/s.

Result: the camera opened 12.9× the configured pixel count, and the opened mode is the sensor's default maximum. Not one attribute from the profile reached the camera, and the stored 30.00 fps field is exactly the kind of value a comma-format reader cannot parse.

Decision: a ratio near 1 means the profile loaded, so if a value still looks wrong, suspect units or sensor limits rather than the file. A ratio an order of magnitude high, with the opened mode equal to the sensor's largest, means the profile never applied. With dot-decimal floats in the file and a comma-decimal OS, treat it as the locale mismatch and go to the fix below.

The fix that lasts: write the settings in code after open

Make the program own its start-up values instead of trusting a file on disk. The sequence is the same whether you write it with a property node in a graphical environment or as attribute writes against a GenICam-based SDK:

1. Open the camera, then clear values left over from a previous session before writing your own.
2. Write the video mode or pixel format first, while acquisition is still stopped.
3. Write exposure, then gain, then trigger and timing values, all of it in one place in the code.
4. Read every value back in the same session and compare it with the target after converting units. Exposure in microseconds against a target in milliseconds is the classic false mismatch; the guide to interpreting raw exposure and gain values shows how raw numbers map to time and factor.
5. Fail loudly on any difference. Confirm the achieved frame rate against the mode — the startup frame-rate check with readback covers that check — and only then start acquisition.

Three traps sit around this sequence. Values left over from a previous run need clearing before you write your own. Attributes written while streaming are rejected or stall the pipeline; the guide to applying settings while streaming without stalling capture shows the safe way. And auto functions can overwrite manual values set at start-up, which is the subject of the auto-exposure upper limit that never applies.

Keep your own settings files locale-neutral

The same bug waits in any settings file your own code writes. Format numbers with a fixed decimal point and no thousands grouping, 30.00 rather than 30,00, and parse them with a locale-independent routine: float() in Python always accepts a point, and C# can parse with a culture-invariant setting to the same effect. Store the master profile in your repository rather than as a per-PC driver file, and every machine starts identically no matter its regional format. The failure class is bigger than cameras: a regional-format mismatch will also stop an industrial project from opening at all in engineering software, for the same writer-versus-reader reason.

Other reasons a saved profile does not apply

Check in this order:

1. Decimal-separator mismatch. Dot-decimal file, comma-decimal regional format; both tests above.
2. The file your session reads is not the file you saved. The profile was saved under a different user account, your program runs elevated, or permission virtualization redirected the save into a compatibility folder. Save from the account that runs the application and compare file timestamps.
3. Exclusive session. The settings utility or another program still holds the camera, so the second open fails or starts fresh at defaults; the exclusive-control diagnosis for a second open that fails walks this through. Close every other client first.
4. Write order. Values applied after streaming started are rejected or arrive too late. HMI software hides the same trap as screen settings that never apply on the first open.
5. Limits and units. The readback differs from the write because the SDK expects microseconds or the sensor caps the value; convert, clamp to the sensor range, then re-check the frame rate.

Decision by symptom

Four of the five rows end in the same place: settings written in code with readback proof beat a file on disk, on every regional format.

Prevention checklist

Run this once per machine, and again after any driver, PC or regional-format change:

• Start-up writes video mode, exposure and gain in code, reads them back and compares, on every open rather than once at commissioning.
• The master profile lives in the repository: dot decimals, invariant parse, no per-PC driver files.
• The first frame is checked against the profile: mode and frame rate match, and the result is logged.
• The settings utility is closed before the application opens the camera.
• One text-editor pass on any new PC: a dot-decimal file plus a comma-decimal format means this machine gets the apply-in-code treatment.

Where to go next

Nothing in this failure is specific to one camera model; any GigE or USB3 area scan camera and any board-level camera depends on the same kind of start-up sequence. Shortlist hardware with the camera finder, build the chain in the camera configurator, or ask the applications team to review your open-and-apply sequence before it reaches the floor. The remaining start-up traps live on the systems topic page.