Capstone: A Parking-Occupancy Prototype
Let us build a practical parking-occupancy prototype.
Capstone: A Parking-Occupancy Prototype explained visually
Let us build a practical parking-occupancy prototype. English captions are optional and start off. The complete transcript follows the written lesson.
What you will learn
Let us build a practical parking-occupancy prototype.
Define the decision
Let us build a practical parking-occupancy prototype. The output is a state for each parking space: occupied, empty, or requiring review. Start by annotating the parking regions in a fixed camera view. Define which vehicle position counts as occupying a space and how to handle vehicles between spaces. Those rules determine what the system is supposed to predict.
Connect geometry and detections
Next, detect vehicles and connect each detection to the parking geometry. A ground-contact approximation can be more useful than the box center. Tracking may reduce brief fluctuations, but temporal smoothing also delays genuine changes. Measure that delay. If the camera moves, the parking regions may no longer align, so the system needs a way to detect or review that condition.
Evaluate the full system
Evaluate complete recording sessions that were not used for development. Include empty spaces, arrivals, departures, occlusion, shadows, and difficult lighting. Report per-space errors and transition timing, not only detector accuracy. Keep a small set of reviewed examples for every important failure type. This project brings together camera geometry, annotations, detection, tracking, and honest evaluation while leaving a clear path for future improvement.
A worked example
If a car leaves at ten:zero:zero but smoothing keeps the space marked occupied until ten:zero:five, the system has a five-second transition delay. That may be acceptable for some applications and unacceptable for others. The requirement should be decided before declaring the system successful.
Worked example
If a car leaves at 10:00:00 but smoothing keeps the space marked occupied until 10:00:05, the system has a five-second transition delay. That may be acceptable for some applications and unacceptable for others. The requirement should be decided before declaring the system successful.
Quick check: test your understanding
Try it yourself: Write a one-page prototype specification with inputs, outputs, occupancy rules, test sessions, error measures, and known limitations.
Check the reasoning
Include a review state and camera-movement handling. Separate detector errors from geometry errors and timing errors so improvements target the actual cause.
Why is detector accuracy alone insufficient for this project?
The final occupancy decision also depends on region geometry, association rules, temporal behavior, and camera stability.
How would you solve the practice case?
Include a review state and camera-movement handling. Separate detector errors from geometry errors and timing errors so improvements target the actual cause.
What does the worked example show?
If a car leaves at 10:00:00 but smoothing keeps the space marked occupied until 10:00:05, the system has a five-second transition delay. That may be acceptable for some applications and unacceptable for others. The requirement should be decided before declaring the system successful.
Further reading
Programming Computer Vision with Python — Jan Erik Solem.
Original ToolsInVision teaching examples. Editorial approach · Suggest a correction
Accessible referenceLesson 16 transcript223 words · Video transcript · Matches the published narration and captionsOpen transcript
Let us build a practical parking-occupancy prototype. The output is a state for each parking space: occupied, empty, or requiring review. Start by annotating the parking regions in a fixed camera view. Define which vehicle position counts as occupying a space and how to handle vehicles between spaces. Those rules determine what the system is supposed to predict.
Next, detect vehicles and connect each detection to the parking geometry. A ground-contact approximation can be more useful than the box center. Tracking may reduce brief fluctuations, but temporal smoothing also delays genuine changes. Measure that delay. If the camera moves, the parking regions may no longer align, so the system needs a way to detect or review that condition.
Evaluate complete recording sessions that were not used for development. Include empty spaces, arrivals, departures, occlusion, shadows, and difficult lighting. Report per-space errors and transition timing, not only detector accuracy. Keep a small set of reviewed examples for every important failure type. This project brings together camera geometry, annotations, detection, tracking, and honest evaluation while leaving a clear path for future improvement.
If a car leaves at ten:zero:zero but smoothing keeps the space marked occupied until ten:zero:five, the system has a five-second transition delay. That may be acceptable for some applications and unacceptable for others. The requirement should be decided before declaring the system successful.