Clarification on calibration

[bartek]

Hi!

Great piece of software and I've enjoyed tinkering with it thus far. I've been recording traffic speeds on my local street over the past week and have what I believe is a fairly accurate measurement on vehicle speeds (determined through using my own vehicle as reference and observing others)

I am aiming to get measurements which are only marginally incorrect, ideally, and I wanted to clarify my understanding of this section in the documentation:

Record cal_obj_mm_L2R and cal_obj_mm_R2L lengths of the object above images in millimeters by measurement or lookup value. You should use several images to confirm and average results in both directions. You may want to test using your own vehicle and logging actual speed and time for each run.

These instructions reference your own vehicle, but goes without saying that vehicles come in many shapes and sizes. When I fine tune this based on my vehicle (a sedan), how do I understand that this tuning will be applicable to a larger vehicle, like a pickup truck?

I've included a sample calibration image (cropped to maintain privacy). There are roughly 150px on the left and 200px on the right of this image that are cropped out. I've only shown the capture rectangle (is this rectangle the calibration object referenced in docs/config?). When aiming for accuracy, should this capture rectangle be shorter in length? Am I aiming for a length that is typical of a large vehicle (ie pickup truck), or is a larger area more beneficial for accuracy?

I feel as if I am misinterpreting these instructions and I want to make sure I fully understand before expanding my experiment.

Thank you!

[rplankenhorn]

@pageauc I am also interested in this and figured I would piggy back on this issue instead of creating a new one.

Since we adjust these four values:

CAL_OBJ_PX_L2R = 80      # L2R Moving Objects, Length of a calibration object in pixels
CAL_OBJ_MM_L2R = 4700    # L2R Moving Objects, Length of the calibration object in millimetres
CAL_OBJ_PX_R2L = 85      # R2L Moving Objects, Length of a calibration object in pixels
CAL_OBJ_MM_R2L = 4700    # R2L Moving Objects, Length of the calibration object in millimetres

Am I right in just assuming that the CAL_OBJ_PX value is just an arbitrary distance in pixels and CAL_OBJ_MM is just that same distance in millimeters? So we are just creating a ratio for converting any pixel width to millimeters?

For my case, I have two very convenient trees. I was thinking about just measuring the distance they are apart in pixels and then physically measuring how far apart they are in millimeters and then just using that as my input values. Or am I missing something?

[kempokempo]

A bit late, i know - but this confused me for a minute too and I thought I'd share my findings.

The idea of calibration is to account for how far away the moving object (i.e. a car) is from the camera - the further away from the camera, the more distance/area is covered by one pixel. So using those two trees wouldn't work, as they are closer to the camera than the car. Equally, a parked car won't work as it might also be further away than a moving car. The calibration object is a moving car, not the capture box, which only shows the area of the image in which the system is looking for motion.

To calibrate, i drove past in my car, which I have precise measurements for, and measured the number of pixels my car took up as i drove past in each direction. So I have the same CAL_OBJ_MM value for both L2R and R2L, but different pixel counts.

[pageauc]

Explanation is correct. Count length in pixels of actual vehicle bumper to bumper works best. Then take a tape measure and measure the same vehicle from bumper to bumper and convert to millimeters. repeat for other roadway since it will be a differnt distance away. You now have pixel and mm distance. Put these numbers in calibration settings in config.py. A mm per pixel will be calculated. speed can be calculated by timing pixels traveled and is then converted to mph or kph.

[bartek]

@kempokempo @pageauc Awesome, thank you for the explanation! Apologies for not responding sooner.