Skip to Content

← All functionalities

Visual inspection (machine vision)Raspberry Pi + USB cameraFicherosInfrastructure

Persistent JSON configuration and golden reference management

Every tuned parameter a vision station forgets at reboot is a phone call from the line. This vision system configuration pattern, from a real production line visual inspection deployment, keeps camera settings (focus, brightness, contrast, saturation) and the six processing parameters in a plain config.json, and stores each golden reference as an already-preprocessed PNG in a references/ folder. After a power cut, the Raspberry Pi boots straight back into a working, calibrated inspection station.

One JSON file as the single source of truth

Camera, processing and matching parameters live in one human-readable file that the GUI sliders write and the pipeline reads. The loader fills in any missing keys with factory defaults, so adding a parameter in a software update never breaks an installed station. Plain JSON also means you can diff configurations between two stations or back one up by copying a single file.

Lock the camera down through V4L2

Consumer USB cameras love to autofocus and auto-expose, which silently changes the image between two consecutive parts and ruins fixed thresholds. At startup the stored values are pushed through cv2.VideoCapture.set: autofocus off first, then manual focus, brightness, contrast and saturation. From that point the camera behaves like a fixed industrial sensor, and every part is captured under the same optical conditions — the precondition for stable thresholds downstream.

Store references preprocessed, not raw

Golden references are saved as PNGs after the full preprocessing pipeline has already run, one file per product variant. That work happens exactly once at capture time instead of on every inspection cycle, and it guarantees the template matcher always compares like with like: same crop, same CLAHE, same binarization. Switching product is just selecting a different file from references/ — no recalibration, no downtime.

A snippet from the implementation

Straight from the example as deployed on the Raspberry Pi + USB camera — copy it freely:

def load_config(path=CONFIG_PATH):
    """Loads config.json; if it does not exist, creates it with the defaults."""
    if os.path.exists(path):
        with open(path, "r", encoding="utf-8") as f:
            cfg = json.load(f)
        # Fills in new keys that did not exist in older versions
        for section, values in DEFAULT_CONFIG.items():
            cfg.setdefault(section, {})
            for k, v in values.items():
                cfg[section].setdefault(k, v)
        return cfg
    save_config(DEFAULT_CONFIG, path)
    return dict(DEFAULT_CONFIG)
View the full working example Get the full project pack

The full example is a complete program — wiring header, setup and main loop — ready to adapt to your application.

Frequently asked questions

Why JSON instead of a database or INI file?

One station, a few dozen parameters, edited by one process. JSON is built into Python, human-readable for remote support, and trivially diffed and backed up. A database adds operations work with no benefit at this scale.

What happens if config.json is missing or corrupted?

The loader recreates it from factory defaults so the station always starts. Tuned values are lost in that case, which is why the deployment keeps a copy of the file with each product changeover.

Should reference images be version controlled?

It helps. PNGs in references/ plus config.json fully define the station's behaviour, so committing both gives you a complete, restorable snapshot of any validated setup.

Related functionalities