Parking occupancy from a camera: synthetics test the idea, real footage delivers accuracy

The most expensive part of computer vision comes before the model

For a camera to tell an occupied parking space from a free one, it needs thousands of examples: empty and full lots, different angles, daylight and night, rain, fog. Every frame has to be labeled, marking where the car is.

Collecting such a dataset at a real site is expensive even before you answer the main question: will the chosen approach work at all. You end up waiting months for the right weather and occupancy, then shooting, filtering and labeling material for an idea you might have to throw away.

We took parking as our own research testbed and split the risk into two stages. First we cheaply tested the idea itself on synthetic scenes. Only after that did we spend on selecting and labeling the real footage needed for working accuracy.

This is not a client deployment, and there is no operating parking site behind the project. The goal was to test the engineering process: how fast you can get a first model, understand the limit of synthetics, and move to real data without months of working blind.

A three-dimensional scene already knows where the car stands

We did not model the parking lots and cars from scratch. Ready-made 3D objects were taken from paid asset packs, assembled in Blender and driven by a Python script. The generator placed the cars, changed the conditions and rendered frame after frame.

The main advantage of such a scene is not only the shooting speed. Blender already knows the coordinates of every car and can produce the correct labeling together with the image. At the start you do not need a person who opens thousands of frames and traces the cars by hand.

In a single run the generator went through combinations that a real parking lot would make you wait a long time for. On this data we trained the first model and got a sufficient answer for the next step: the chosen detection scheme works in principle.

The synthetic dataset could be produced in a day and sent straight to training. If the first version of the scene turned out poorly, the parameters were changed and the frames were regenerated with no new shooting and no manual re-labeling. That speed let us test the design of the experiment rather than guard every early dataset as an irreplaceable asset.

The first model proved the idea, but did not replace a real camera

A synthetic frame is still an image from a 3D editor. Real video brings in asphalt texture, glare, camera noise, unexpected shadows, partially occluded cars and countless small details that the generator does not reproduce precisely.

So after validating the idea we gathered real images from open datasets. They were shot and published by other people; we did not invent a non-existent site of our own for the article. From a large collection we selected representative frames and prepared the labeling in about five working days.

Selection was part of the work, not a technical copy of the whole archive. We needed frames that add real-world conditions to the model and do not repeat one another across thousands of near-identical images. After that the cars were labeled by hand: an open photo does not carry knowledge of an object's position the way a Blender scene does.

On the real images the model was fine-tuned. Over several months of experiments it was brought to a working state. After fine-tuning, cars in real footage were recognized noticeably more accurately than by a general-purpose model with no adaptation to the task.

Here synthetics saved not all of the future work, but the riskiest first investment. Real data was still needed, but we moved to labeling it only after the approach was confirmed.

The result was a sensible trade of costs. Automatic labeling quickly answers whether the idea is viable. Manual preparation is then aimed at improving a model that already works, rather than at a blind attempt to assemble the largest possible dataset before the first experiment.

One frame turns into space statuses and traffic flow

The working loop uses YOLO - an object detector that finds the cars in a frame. The system receives a video stream, tracks the detected cars between frames and matches them to parking spaces labeled in advance.

YOLO's general capabilities are broader. On top of it you can estimate speed, build trajectories and activity heat maps. In this project those features were not implemented: the task is limited to detecting cars, space occupancy, traffic flow and parking duration.

This boundary matters, because the description of a ready-made library is easy to mistake for the features of a specific system. Here we list only what was built and tested in the project.

A new camera starts with a still frame

The parking camera is fixed, so the geometry of the spaces does not have to be worked out again for every frame. The user provides a link to the video stream, the system grabs a still frame, and the parking zones are marked on it with the mouse.

The main part of the lot is convenient to describe as a grid of rows and columns. Individual spaces set off to the side or at an unusual angle are numbered one by one. The labeling is saved and then used for all the following frames from this camera.

Connecting a new viewpoint requires two starting things: an available video stream and a one-time labeling of the spaces. After that the detector updates their states automatically. The saved layout can be reused, and for another camera you repeat the same procedure on its still frame.

The project's working tool is therefore nothing like a guard's console. Its job is to connect a camera, describe the geometry of the lot and then show the result of automatic processing.

We versioned the experiments and decided to regenerate the synthetics

Model training easily turns into a process where no one remembers which parameters produced the current result. For the experiments we used MLflow: every run, its settings and the resulting model version are recorded. Versions can be compared and a successful configuration repeated.

With datasets we tried the same level of discipline, but dropped it at the early stage. While there is no working model yet, a synthetic dataset is faster to regenerate from a script than to maintain heavy versioning of every intermediate frame. The overhead turned out higher than the benefit.

This is not a general rule against versioning data. Once you have a valuable working model and several real datasets, the ability to precisely reconstruct training becomes more important. And even in the research phase reproducibility did not go anywhere: the generation script remained the source of the synthetics, and MLflow stored the parameters and the training result. We removed the layer that did not pay off, not the ability to understand how the model was produced.

The line runs where the real camera begins

Synthetics alone would not have given working accuracy, and collecting the largest possible real dataset from day one would have been an expensive blind test. What proved useful was the order: synthetics answer whether it is worth continuing, real footage adapts the model to the world it will have to work in.

Both sides required fine-tuning. The scene generator in Blender has to be calibrated so that the variety of conditions stays meaningful. Fine-tuning on real data is not a one-button job either: you have to choose the dataset and the parameters and compare experiments.

After training, accuracy is still limited by what the camera sees, image quality and the available compute resources. The system does not use sensors at each space and draws its conclusion from the picture alone. If an object is blocked, has dropped out of frame or the image is too poor, the model gets no hidden information by any other means.

Parking shows the approach, not the limit of application

The "camera, detector, zones" combination also fits other tasks where an object can be seen and counted. In logistics that is equipment and occupied areas, on the road it is traffic on a street or at an intersection, in a production setting it is the number of objects in a zone or actions performed.

The transferability of the mechanics does not mean a promise that "the camera will count everything." Before a new task you still check the viewpoint, image quality, the set of real data and the acceptable margin of error.

This in-house project is not presented as a client deployment. Its value is in the process that was gone through: cheap synthetic validation, the move to real data, tuning the detector, tracking experiments and understanding the limit of the image. The same decisions about data and hypothesis testing come up in commercial computer-vision projects, even when the object in the frame is already a different one.