How to count number of car passing through virtual line when centroid is already calculated
7 次查看(过去 30 天)
显示 更早的评论
I have found some solution from MATLAB answer. Where Image analyst has already answer this question.
if ~isempty([centroid])
S =size(centroid)
for i = 1: S(1)
ynew = centroid(i,2)
if sign(ynew-192) ~= sign(yold(i)-192)
counter = counter +1
end
yold(i)=ynew;
end
However, when a new car is detected after some frames. It count car once again as per using the yold and ynew information.
2 个评论
Daniel Hamilton
2018-2-19
If you got this working in the end is there anyway you could share the code?
采纳的回答
Walter Roberson
2017-5-17
Keep a matrix of centroids of currently known objects, together with a flag indicating whether the object had been counted.
In each step, detect current objects. For each detected object, go through and match it to the closest old object (that is, a prediction that objects move sufficiently alike in speed that any given object probably moved there from the closest known previous object.) Copy the old "has been counted" status to the new information array. Then, if the object is not marked as already counted, then see if the old location and new location together cross the virtual line; if so update the global count and marked the object as counted in the new data. For new objects that had no close-enough previous match, leave them marked as uncounted in the new array. Then, having processed all current objects, throw away the previous information and make the current information the "old" information.
10 个评论
Walter Roberson
2017-6-5
max_believable_movement_per_frame has nothing directly to do with the frame rate.
Suppose you have one car in a frame, and in the next frame that car has exited to the left and another car has appeared on the right. The total number of objects is still one, so when the matching of centroids is done, it would appear that the car had quite quickly driven (backwards) to the other side of the frame. The computer doesn't know the difference, but we know that is not realistic -- that it is not believable.
max_believable_movement_per_frame is the distance cutoff for how far a car could believably move between frames, after which we say "No, that's not realistic, we must be talking about two different cars instead."
By the way, the code could be improved by making predictions from velocity. The first time (first frame) we see a car we do not know how fast it is going (though the speed limit in the area might give some guideance as to what is likely), so we might have difficulty predicting where it will be in the second frame. But once we have seen the same car in two frames, we can use the distance traveled to estimate where it will be in the third frame, and we can use that to improve our matching.
Consider for example the case
p ---------> P
Q <------ q
Here p and q are centroid positions in frame 2, and P and Q are centroid positions in frame 3.
The code I suggested earlier matches each centroid to the closest new centroid, so it would tend to match p to Q and q to P. Every time two cars pass each other going in opposite directions, the code I showed has the risk that the cars will swap roles. But if velocity information was available, data from the earlier frame 1, then we would have a better chance of matching the centroids to their updated positions. Lane constraints can also help with that: cars can perhaps change lanes that are traveling in the same direction, but they do not change into lanes that are traveling in the opposite direction (well, except when they are passing...) Additional information such as car color can help.
I said earlier that "max_believable_movement_per_frame has nothing directly to do with the frame rate." There is an indirect relationship, though: the frame rate tells you the change in time, and by knowing the speed limit (and taking into account that cars might speed), you can calculate the maximum realistic distance that can be traveled in one frame, and then you can convert that into pixels for max_believable_movement_per_frame . The higher the frame rate, the lower the maximum physically believable movement between frames.
更多回答(0 个)
另请参阅
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!