Tracking of vehicles and pedestrians in outdoor or indoor sequences Abstract: A tracking algorithm is presented for monitoring pedestrians, cars or other moving objects in an outdoor or indoor image scene from a fixed camera. Two different models are used to represents moving objects, one for appearance and one for motion. Rudimentary algorithms are implemented into these two models. So, we need to use additional algorithms to resolve errors made by the tracker; these algorithms are interpreter of object status –on process, too old, inconsistent or occulted- and object trajectories –with pieces of quadratic equations-. Some results are shown on a road cross sequence.
Objective: The aim of this paper is to explain a method for tracking moving objects in an indoor or outdoor color video sequence (8-bit color). This is done by drawing the trace of each object in ordrer to see, on this sequence, which position each object has and at which frame. The first step in the tracking of moving objects in a scene (movie) is to detect these moving objects. A first program extracts these moving objects with a background modeling algorithm. This program has three kinds of output data. The first one is set of original images (all frames of the movie). The second one is a set of segmented image – all pixels are black except moving pixels, which have the original colors (a set of related pixels is a blob). The third one is a list of bounding boxes of all moving blobs for each frame. The program explained in this paper use these 3 inputs.
1/19
Table of Contents 1. 2.
General diagram ................................................................................................................ 3 Object modeling ................................................................................................................ 4 2.1. 2.2. 2.2.1. 2.2.2. 2.2.3. 2.2.4.
3. 4.
Tracker : Object tracking................................................................................................... 8 General method.............................................................................................................................8 General algorithm .........................................................................................................................9 Dynamic matching.........................................................................................................................9 Appearance matching.................................................................................................................. 10
Interpreter ........................................................................................................................ 10 5.1. 5.2. 5.2.1. 5.2.2.
6.
Data of Entity ‘s history..................................................................................................................................................4 Dynamic Model...............................................................................................................................................................5 Appearance Model ..........................................................................................................................................................5 Status................................................................................................................................................................................6
Conflict representation ...................................................................................................... 7 4.1. 4.2. 4.3. 4.4.
5.
Blob representation .......................................................................................................................4 Object model .................................................................................................................................4
Coherence................................................................................................................................... 10 Interpretation .............................................................................................................................. 11 Conflicts created by segmentation errors ....................................................................................................................11 Other Conflicts ..............................................................................................................................................................12
Occlusion detector ........................................................................................................... 15 6.1. 6.2.
Obstacle detection ....................................................................................................................... 15 Occlusion computation ................................................................................................................16
7.
Results ............................................................................................................................. 17
8.
Conclusion....................................................................................................................... 19
2/19
1. General diagram To do basic tracking of moving objects, we only need information of several precedent frames. But, the tracking process generates many errors, because of the difficulty to correctly model object motion. We know that this tracker is rudimentary. But, to extract right trace of objects from this tracker results, we need a powerful trace interpreter. A contrario, this tracker need a long historic data to interpret trajectories. That’s why the tracker is executed at each frame, but not the interpreter, we execute it only once every N frames. We track objects on a dynamic environment; so, it is possible to have some obstacles between the camera and objects to track (static obstacles like lights at a road crossroads, trees or dynamic obstacles (an object that is hidden by another object). To integrate these occlusion times, we compute an image of occlusion area, to improve the interpreter.
Tracker
Conflict detection
No
Interpretation Yes
Interpreter
Obstacle Detector
General diagram - Fig 2
3/19
2. Object modeling 2.1. Blob representation Each foreground blob detected by the segmentation program is represented with a bounding box with 2 coordinates – x and y coordinates from the bottom left corner, the width and the height of this box-. The origin of all images is the bottom left corner. 2.2. Object model Each tracked object is recorded on an entity database and ideally corresponds with a blob in the new frame. An entity is characterized by a: Data of Entity ‘s history Dynamic Model Appearance Model Status Dynamic and appearance models describe the motion and the appearance of the object at the current frame; it uses also data from last frames. Actually, an object can only undergo small variations. But, even if we compute very precisely each parameters, because of acquisition process, there is some noise in addition of the object. This noise and sampling process influence the color and the size, especially with the small object, so the motion parameters too (velocities). Another problem appears when objects disappear temporarily of the scene. During this occlusion time, all parameters can change significantly; it is depending of the time of occlusion. It is the same problems when objects appear for the first time into the scene (i.e. when there is no history). Actually, the main problems are due to the background segmentation. So, we have to integrate these problems into models. That’s why some tolerance parameters are added. Note that all entities are generally not detected at each frame. So, the number of frame since the first time this entity was seen, and, the number of valid positions are not equal, in general. 2.2.1.
Data of Entity‘s history
- First reference frame number: first frame in which entity appeared - Last reference frame number: last frame in which entity appeared - List of all previous bounding box. If, on a frame, this entity is not detected, the bounding box is set to 0,0,0,0.
4/19
2.2.2.
Dynamic Model
This model contains parameters of linear equations to represents the movement of the centroid of the bounding box, the reference frame number of these line equations (frame0) and the current position. There is also a velocity tolerance and a window tolerance to not to be too restrictive during position predictions. - Current position: it is the last bounding box in which the entity was seen, in the last frames. - X and Y linear equations: these equations are referenced to the time -here, the time is the Current_frame_number – frame0, it is not an absolute time-:
x(t ) = x0 + v x .t
y (t ) = y 0 + v y .t
x0 , y 0 , v x , v y are computed by a least-squares method. Example: we use the 5 last positions to compute these parameters. But there is some holes in the list of entity last positions (we only know its position at frame f, f-1, f-2, f-4, f-7; so our reference frame number is frame0 = f-8).
x f −1
1 8
1 7
x f −2 = 1 ⋅ 6 *
x f −4
x f −7
x
xf
1 4
x0
v x
1 1
Fig 2
v0 x0
t f-8
f-7
f-4
f-2
- Velocity and Window Tolerance: see matching part, Dynamic section 2.2.3.
f-1
f : current Frame
Appearance Model
This model describes the appearance of the object at the current frame; it uses also data from last frames. The model contains area parameter, RGB parameters, a black percentage, a white percentage, a color tolerance parameter and a black and white thresholds. -Area parameter: this parameter is a median on the N last area of the entity. If this entity has less than N positions –i.e. this entity was detected in less than N frames since it was seen for the first time-, the last area becomes the area parameter.
5/19
-Black and white percentage: These two parameters appeared after a particular observation. If the color or the luminance is too high or too low, it is impossible to compare the blob’s color with entities’ color (not enough or too much brightness). We choose to characterize this point with the luminance: L = 0.299 * red + 0.587 * green + 0.114 * blue . - The black percentage is the number of pixel whose intensity is lower than a black threshold. This parameter is normalized by the area parameter. - The white percentage is the number of pixel whose intensity is higher than a white threshold. This parameter is normalized by the area parameter (in general, black threshold = 255 - white threshold). -RGB parameters: this is the red, green and blue mean color of pixels which are not lower than the black threshold or higher than the white threshold. RGB are not normalized. -Color tolerance and black & white thresholds: see matching part, Appearance section Black percentage
0
Mean R, G, B color computation
Black threshold
White threshold
White percentage
255
Color axe and color parameters - Fig 3 2.2.4.
Status
The status parameter represents the state of the entity, at the current frame. It is updated at every frame. Three different statuses have been extracted: o o o
ONPROCESS: this entity is into the database and is currently used by the tracker. (O) TERMINATED: means that this entity was a ‘good’ entity but it is too old to be on the process now. (I) DELETED: this entity is inconsistent (D)
A ‘good’ entity is an entity which represent indeed a real object. Another status parameter is used, an occulted parameter to represent if entity is occulted by a static obstacle between the camera and the object. It is a Boolean.
O
D
T
State Diagram- Fig 4
Ideally, an object corresponds to only one entity. But, because of segmentation errors and because several object are visible into the scene at the same time, wrong entities are generated. Segmentation errors generate small and/or inconsistent entities; they are easy to detect. But, interactions between several entities on the same zone generate abusive entities. To represent this, we introduce the concept of conflict.
6/19
3. Conflict representation Two different kinds of conflicts have been found: Merge-conflict and Split-conflict. Merge-conflict: at a frame f-1, 2 different entities are distinct; there isn’t common blob into their history. At frame f, the same blob is identified to be the new current position of these 2 entities. (cf. Fig 4, b & e) Split-conflict: at a frame f-1, only one entity is necessary to represents a trace; but, at the frame f, two blob can be identified to become the new current position -the trace is splitted into 2(or more trace)-. (cf. Fig 4, c & e) In our case, a conflict is representing by a frame number -the frame number where the conflict appears-, and a list of 2 entities. Example: Traces go from the left to the right. List of conflicts: frame f1 : 0; 1 frame f2 : 0; 2 frame f2 : 1; 2
1 2
0 f1
f2
with 0, 1, 2 : entity number
Merge conflict - Fig 5
7/19
4. Tracker : Object tracking 4.1. General method
a
1
a
1
2
a 1
1
4
b
b
6
b e
2
2
4
2
4
6 3
3
5
c
c
3
3
7
5
c 3
5
5
6
Copy of c list
7
Fig 6 st
1 step
: blob
nd
2 step
: last position list
: entity
3rd step
: blob is matched with the entity
legend Example: 1st step: Three blobs appear (1, 2, 3), we create three entities (a, b, c) and we update them with the three blobs: put 1, 2, 3 onto the last position list of a, b, c and copy 1, 2, 3 into the current position parameter. 2nd step: Two new blobs (4, 5). Blob 4 matches with entity b, blob 5 and entity c. We update current position parameters with 4 and 5, and push 4 and 5 onto last position lists. Entity a is not matched with 4 or 5, we push an empty blob onto its last position list. 3rd step: Two new blobs (6, 7). Blob 6 matches with entity b, we update it and push it onto b-last position list. Entity a is not matched with 6 or 7. we push an empty blob onto its last position list. But, blob 6 and 7 match with entity c, so we create a copy of entity c, entity e. we update c with 7 and e with 6. Creation of a Split-Conflict between c and e. With this Split-conflict, a Merge-conflict was born between b and e.
8/19
4.2. General algorithm The tracking processing is done on 2 ways. First, we try to match all new blobs to one entity. There are different cases: - any blob can be matched with this entity. The current position is not updated; the last position history list is updated with an empty position. - only one blob can be matched with this entity. It is updated with this blob (last position list and current position parameter). - several blobs can be matched with this entity (N blobs). We copy the entity before updating it, N-1 time. And, the current entity and the N-1 other are updated with the N blobs. we generated N Splitconflicts. Second, we try to match all entities to one blob, for all new blobs. Only one case is different. - Several entities (M entities) can have the same blob as next blob. We update all entities with this blob. We generate M Merge-Conflict if any of entity in conflicts is under an occlusion area (occlusion areas are described on §7). If it is under an occlusion area, we don’t generate conflict for this entity. 4.3. Dynamic matching When an entity is created, there is of course no history. Its corresponding blob in the next frame generally moves. But the entity has its velocity parameters equal to zero (we can’t privilege any direction). So, to have a area prediction, we can only use the data available at this stage, the size of the bounding box. As the entity has only small variations on size and position, we decide to use the width and height of the bounding box to predict the position. These parameters are balanced with a window tolerance: We predict the position of the centroid of the next blob: Velocity (s)!= 0:
Velocity = 0: width * windowTol
width * windowTol height * windowTol
s.t*(1+ speedTol) s.t*(1- speedTol)
Predicted position of the centroid of next blob
height * windowTol
Dynamic matching -Fig 7
Predicted position of the centroid of next blob
To compile the velocity, we use M last positions of entity. But between the current frame and the next frame, the object can change its direction or can go slower or speeder. That’s why we need a speed Tolerance. Another case, if the object is not occulted at frame f but becomes more and more occulted on next frames, until being totally occulted at frame f+5, and even if the true velocity is constant, for us, the centroid is slowing down. After the occlusion, the predicted position is nearer to the last position than the true position, the 9/19
tracking is cut. So, if we only use the speed Tolerance, it is impossible to track this object after the occlusion (computed velocity is too small). So we keep the window tolerance when the velocity is not equal to zero, to have a larger area of prediction. If we remove the window tolerance when velocity is not zero, we can increase the velocity tolerance, but it doesn’t solve the occlusion situation To have a good tracker, these two parameters must be adjusted simultaneously. In general, window tolerance is close to 1 and speed tolerance is close to 0.8. 4.4. Appearance matching As mentioned before, if there is too much or not enough luminance, it is impossible to use the color to do the matching. So, when the blob has too much (white percentage nearly 1) or not enough luminance (black percentage nearly 1), the color information is not used for the matching. But, if the luminance is good, we compute the normalized distance between the blob’s RGB mean color and the entity’s RGB mean color. If this distance is small, the color matching is done. The appearance matching also needs the area matching to be complete: If the blob area is compatible with the entity median, the area matching is done. To sum up, the algorithm is as follows: if( blob’s_area = entity’s_area_median* (1.0 ± areaTolerance) AND [ blackPercentage + whitePercentage > B&W_Threshold) OR ( | Rb - Re | + | Gb - Ge | +| Bb - Be | ) / (Re+Ge+Be) < colorTolerance ) ] ) appearance matching is OK where b means blob and e entity. In general, B&W_Threshold is close to 0.7, colorTolerance is close to 0.2 and areaTolerance is close to 1.
5. Interpreter The interpreter is executed only once every P frames (we set P=20). The interpreter is the only part of the program allowed to change entities’ status. There are 2 stages for coherence, 2 stages for interpretation. All these stages are described with rules. Into the following 2 parts, I’ll describe the rules we use. 5.1. Coherence First, we remove old and too short entities to keep a coherent database. It means that, if entities are detected on M frames or less and if they are too old (not detected for N frames), we decide to remove them from the database (i.e. their status become DELETED)(M=2, N=6). This step is done every N frames. But all the other rules are executed every P frames (P=20). The reason to not have the same rhythm is to remove short entities which match with many other objects after a too long time. I.e. its length is too small, so there is an inaccurate speed, the expression s*(1±speedTolerance)*t diverges; after P frames, it is possible to have s*(1-speedTolerance)*P = 0 and s*(1±speedTolerance)*P=width of original image, -t is the number of frame between the last reference frame and the current frame number-. Now, all rules are executed every P frames.
10/19
If ONPROCESS entities are too old (not detected for P frames), their status become TERMINATED. Second, we remove stagnant entity: for all entities which are moved less than x pixels per frame since the first reference, we interpret them as not coherent entities (i.e. their status become DELETED). (x between 2 and 10). Actually, the not moving entities are not dangerous for the tracking, just after their appearance. But, I observed the same problem than I explained before (for too short entities), but the rhythm is different. 5.2. Interpretation 5.2.1.
Conflicts created by segmentation errors
Firstly, we look at Split-Conflict list and Merge-Conflict list. We check if conflicts were created with a segmentation error or not: Examples: p4 a p1
p2
b
p3 p’4 p5
b
a p6
p1
p2
p4
p3 p’4 p5
p6
Splitting p1;p2;p3;p5;p6 : entity a p1;p2;p3;p4 : entity b
Merging p1;p2;p3;p5;p6 : entity a p4;p5;p6 : entity b
Conflict creation -Fig 8 Let see up from p1 to p4, in theses 2 examples. After p3, we would expect p’4 but instead we have p4. At this step, p4 is not detected as the next position of p3. Therefore, the tracker creates a new entity, b, with only a blob on the left scheme. During the next step, p5 is detected as the new position of entity a, and b, on the left scheme; a merge-conflict is generated. On the right, p5 is detected as the next position of a only, a split-conflict is generated. To determine if b is an abusive entity –i.e. b is generated by a segmentation error-, we compute the length of a and b, before the conflict on the left, and after on the right: L1 = length( p1; p2; p3; p5) L1 = length(p3; p5; p6 …) L2 = length( p4; p5) L2 = length( p3; p4) If L2 < L1 AND L2 < L0 where L0 is an adjustment parameter, we remove b from the database. For the split-conflict, either b is removed or if is not, we erase this conflict and update the other conflict lists (if b is mentioned in another conflict, we have to erase this other conflict, b is not any more on process). We consider this case as the only case of abusive splitting. But, for the merge-conflict, if b is removed, we update the conflicts lists. If not, we keep the conflict and we do the second interpretation. Secondly, we interpret only the merge-conflict not resolved by the first interpretation.
11/19
5.2.2.
Other Conflicts
This following part is the heart of the interpreter. Although, we can say that both entities in conflict have a common part, after the conflict appears. But, it is possible that the trace is not common until the disappearance of each entity. Example:
b
merge position
a Since the conflict, entities a & b have merged and have a common trace Case 1
b end of b
a Entities a & b have merged and have a common trace, but entity b is terminated before a because of a non-dynamic matching Case 2
When we do the interpretation, to distinguish these 2 cases, we check if current positions of entities are equal or not. If there are equal, it is case 1, if not, it is case 2. Before each case is explaining, let's explain which parameters we compute to distinguish them. Each trace -each entity- are described with pieces of quadratic equations y = Y0 + v.x +
1 a.x 2 . 2
After the computation of these equations, we compute the number of change of direction of each entity. Computation of quadratic equations: There are 3 parameters to calculate for each piece of quadratic equations. - If there are enough positions (more than 3), we compute a first equation with the N first positions (position P1 to position P1+N). After this, we calculate the distance between the quadratic curve and the N real positions. If the distance is, on average, less than a threshold dMin, we continue to check if, on average, the distance between the curve and the real position is less than dMin –for position P1+N+1 to P1+N+…-. If at the end of the real trace, the distance is less than dMin on average, we keep this curve –we keep Y0 , v, a describing entity trace-. Therefore, this entity needs only one quadratic equation to be well represented. Although, if the distance is higher than dMin on average at the position P1+N-n0 or P1+N+n1 (n0>0 and n1>0), we keep this quadratic equation and we then restart this stage with P1= P1+N-n0+1 or P1+N+n1+1. - If there are not enough positions (less than 4; P1 to Px, x ∈ [1;3] ), we compute only a linear equation
y = Y0 + v.x between P1 and Px ( a = 0 ). Quadratic equations are computed with a least-square method, based on centroid of bounding boxes. Result:
12/19
y0=-1310 v=16.8 a=-0.09
y0=367 v=-1.574 a=0.005
y0=282 v=-2.28 a=0.015
y0=161 v=-0.93 a=0.0074
10 .
This trace represents a car. To describe it, we need 4 quadratic curves, with dMin= Computation of change of direction number:
We calculate how many times the trace change its directions on Y direction, i.e. how many times the trace change its direction from downwards to upwards, or from upwards to downwards. For this example, the number of direction change is equal to 1 ( 1 change between the end of curve 1 and curve 2). Creation of new entity: We create 2 new entities from the 2 entities in conflict. We then create an entity with positions of entity a before the conflict and positions of entity b after the conflict, and vice-versa. Example: merge conflict b a
new entities =>
d c
With this creation, we check norms and signs of a and b tangents, at the end of their trace. Conflict resolution algorithm: Reminder, a conflict is a frame number and 2 entity number, a and b Let directionChangeA be the number of change of direction of entity a, directionChangeB for entity b. Let nbCurvesA be the number of quadratic equations necessary to represents entity a, nbCurvesB the number of quadratic equations necessary to represents entity b. directionChangeA < directionChangeB means ‘a is straighter than b’ nbCurvesA < nbCurvesB means ‘a is smoother than b’
13/19
Case 1: if( directionChangeA < directionChangeB ) b is erased else if( directionChangeA > directionChangeB ) a is erased else if(nbCurvesA < nbCurvesB) b is erased else if(nbCurvesA > nbCurvesB) a is erased else if there are similar b is erased (arbitrarily) else do nothing
Case 2: if( tangent(a) # tangent(b) ) creation of c and d if directionChangeC min( directionChangeA, directionChangeB) replace b by c and erase a else if directionChangeD min( directionChangeA, directionChangeB) replace a by d and erase b else goto next else else if( b is too short –not enough position to decide- and not a) b is erased else if( a is too short and not b) a is erased else if( a and b are too short) don’t interpreter this conflict at this step, we wait the next interpretation stage else do nothing Obviously, if an entity is erased, the current conflict is erased. We update all other conflicts -erase conflicts in which the entity is present-. Th first if of case 2 is not often executed because this case is rare: although, it allows to paste some traces which have been cut and not well tracked after the cut.
14/19
6. Occlusion detector The occlusion detector is executed only once every P frames, at the same rythm than the interpreter. We have three kinds of entities: ONPROCESS, TERMINATED and DELETED entities. We detect an occlusion area only with the first 2 kinds because the other is considered as non-coherent. 6.1. Obstacle detection We begin by checking, on the trace of each entity. If there are some holes between the first and the last reference, it means this entity is not detected during one or more frames. To do this obstacle detection, we create a new image: an occlusion image. Example: We have a trace, in which one position is missing. We compute a rectangle to represent the place of a potential obstacle –occlusion rectangle-, each pixel of the occlusion image under this occlusion rectangle is incremented by 1.
Occlusion rectangle : detected position : non-detected position hole on the trace
Occlusion rectangle computation -Fig 9 Firstly, we do this operation for all the ONPROCESS and TERMINATED entity (good entities). We then calculate how many times each pixel is under an occlusion rectangle into the occlusion image. Secondly, we estimate that if an entity appears, it was occulted before its appearance, and if it disappears, it is occulted after its disappearance. But we estimate that the edge of the image is a natural occlusion area. Therefore, the edge area is considered as an occlusion area. If the centroid of the first or last position is on the edge, we don’t use this entity to obstacle computation. Although, if this centroid is not on the edge, we create a rectangle centered on this centroid with width’s rectangle = c*width of the original image and height’s rectangle = c * height of the original image (c = 0.05). See Fig 9.
15/19
b a
edge area
a
a
a = 0.06 b = 0.25
image
a
Edge occlusion area -Fig 10 b is different because, if the camera has vision field that is too long, entities in the top of the image are too small to have good interpretations. Actually, if b is equal or nearly equal to a, traces of objects, which go from the bottom to the top of the image, are merged on the top. This occurs because their velocity, area and color are close. Therefore, we forget many traces. 6.2. Occlusion computation Each pixel under an obstacle is increased by one into the occlusion image, as many times it is under an obstacle. After, we compute the maximum of the occlusion image (max_obstacle), which corresponds to the maximum number of obstacles in front of a pixel. We then decide to keep only pixels which are detected max_obstacle*correction_coefficient with correction_coefficient ∈ [0,1] . We compute blobs on the occlusion image with a connex component labelling to obtain homogenous blobs. We keep, as describes on §6.1, obstacles detected max_obstacle*correction_coefficient; good obstacles homogenous blobs on occlusion image- are grouped on 1 occlusion area, represents by a grey square. The other white blobs are non-consistent obstacles. Occlusion area -grey square on the left image- corresponds to the blue area on the original image (on the right).
Occlusion image
Fig 11
16/19
Original Image
(The Lights on the bottom are not detected as occlusion area because, during this sequence, not enough cars drive from the bottom to the left, so there are not enough traces to detect lights as occlusion area) The last step is to push coordinates of grey rectangle on a list to use this occlusion area on the tracking processing. Under obstacle parameter: an entity is under an occlusion area if one or more pixel of its current position’s rectangle is under an occlusion area.
7. Results The Left part of following images represents traces without interpretation, only tracking results. Altough, on the right, we see traces after the interpretation. There is 5 frames to show you conflicts computation and resolution. frame 1
b
c
a
frame 2
On frame 1, cars a, b and c are not yet on conflicts; but, at frame 2, the segmentation detects car a and b as only 1 blob, that’s why there is only 1 rectangle for car a and b. After this, this blob is splitted and we obtain again 2 new blobs which correspond to car a and b.
17/19
frame 3
On frame 3, each car is detected as possible next objects of car b on frame 2. So, the last trace 65 is splitted into 3 entities, trace 65 (for car b), trace 60 (for car c) and trace 63 (for car a). But traces 63 & 56 are merged and traces 63 & 64 (look at frame 4). We obtain 4 conflicts: - 2 split conflicts: - 2 merged conflicts: - frame 3; 60, 65 - frame 3; 63, 64 - frame 3; 63, 65 - frame 3; 56, 63 frame 4
frame 5
On frame 4 and 5, we see all the entity numbers I have mentioned above. On the right part of frame 5, we see only 3 traces, rather than 5; each one corresponds to 1 car.
18/19
This original sequence shows 100 moving objects detectable by the tracker (cars, trucks and pedestrians). The system detects 210 traces, but all are consistent traces; there is no “wrong” detected as “good” traces. On e hundred and twenty other entities are detected as inconsistent. On this 100 objects, the system detects only 95 objects and it misses 5 objects (3 cars & 2 pedestrians). This can be explained on this way: as we are rather restrictive on tolerances and conflicts resolution, some good traces are erased because they are understood as inconsistent. We choose to be a little bit too restrictive rather than too tolerant. The sequence is originally a 30 fps sequence with 6700 frames. The system takes 1 frame per 6 frames. It works at 5fps. The average time to compute these 6700 frames is 70ms with a PIII 450MHz. It needs 30Mb.
8. Conclusion With this system, we can track moving objects with a good performance. The combination of dynamic model and appearance model permits us to use all information we have –information into the current frame and on last frames-. The tracker is rudimentary but it is enough to detect and match moving objects. But we can’t exploit these results without more computation. The interpreter and the occlusion detector allow us to keep only consistent traces and removes too short, too old or inconsistent traces between 2 objects. The next step can be the detection of the objects’ gravity center and smoothing of traces.
19/19
