How to count number of car passing through virtual line when centroid is already calculated

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.

[Daniel Hamilton]

If you got this working in the end is there anyway you could share the code?

[Mr.Alb]

I'd really appreciate if you shared the code, please

Answer 1

[Walter Roberson]

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.

[Jawad Ahmad]

Thanks for your answer. However, Its a bit tricky answer. Could you please tell me in a psudo code.

[Walter Roberson]

old_centroids = zeros(0,2);
old_has_been_counted = false(0);

max_believable_movement_per_frame = .... something;

Then a loop

current_centroids = detect_object_centroids();
num_current_centroids = size(current_centroids,1);
current_has_been_counted = false(1, num_current_centroids);

for cent_num = 1 : num_current_centroids
   this_centroid = current_centroids(cent_num,:)
   dist_to_old = pdist2( this_centroid, old_centroids);
   [best_match_dist, best_match_idx] = min(dist_to_old);
   that_centroid = old_centroids(best_match_idx, :);
   if best_match_dist <= max_believable_movement_per_frame
      if old_has_been_counted(best_match_idx)
        current_has_been_counted(cent_num) = true;
      elseif did_it_cross_the_line(this_centroid, that_centroid)
        increment global crossing count
        current_has_been_counted(cent_num) = true;
        old_has_been_counted(best_match_idx) = true;
      else
        current_has_been_counted(cent_num) = false;
      end
   else
     current_has_been_counted(cent_num) = false;
   end
 end
 old_centroids = current_centroids;
 old_has_been_counted = current_has_been_counted;

[Jawad Ahmad]

Thanks for your detail code. elseif did_it_cross_the_line(this_centroid, that_centroid). How to implement this? For example, If it crosses Y = 192 then count it. max_believable_movement_per_frame is frame rate?

[Jawad Ahmad]

OK. I got it. Thanks very much.

[Walter Roberson]

Note that my code does not assume a direction of motion, so both the old and new centroids are needed to determine crossing the line, since it could be approaching the line from either direction; the test would be whether the line is between the old and the new centroids.

[Jawad Ahmad]

How to code them between lines? If i know the line staring and end positions (x1,y1) and (x2,y2). Let say using MATLAB line.

Line_Insert_frame = insertShape(frame,'line',[210 192 640 192],'LineWidth',2);

Now I defined start and end point.

[Walter Roberson]

See https://www.mathworks.com/matlabcentral/fileexchange/27205-fast-line-segment-intersection

[Jawad Ahmad]

I am still a bit confused about max_believable_movement_per_frame. Is it the frame rate?

[Walter Roberson]

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.

[Jawad Ahmad]

Thanks very much for this explanation.