20210616-软件杯A2选题思路(源代码暂不放出,可能哪天丢上GitHub后编辑放出)

今天主要是操作系统的考试。此外，进行了软件杯选题的收尾。最后通过取巧的方式实现了画面内(有框选选区时为选区内)拥挤判断。

行人追踪的步骤为：

1.获取视频,循环获得视频的每一帧(若读到结束则跳出)，记录当前读取帧数。

1.使用PaddleDetection的相应算法对每帧进行行人检测,得到检测框数组。

2.转换得到的检测框数据格式(PaddleDetection输出的格式和Deep SORT的部分稍有不同)，并根据从GUI中的"置信度"框实时读取的置信度参数滤去置信度不满足要求的检测框。该框取值范围0.1-0.9，只能通过上下按钮调节，无法直接修改，防止由于用户删除后未填写导致该栏缺失数据报错，绘制检测白框到帧中。

3.转换后的数据传入Deep SORT进行重识别，得到重识别数组。

4.遍历得到的重识别数组，将其坐标、追踪ID、此时帧数按追踪ID(track_id)存入存储数组。存储数组存储每个追踪ID30帧内的最近信息。

5.对检测结果按选区过滤(若无选区则不过滤)，将(track_id,坐标)存入展示数组(仅存在于循环的本次执行中，下次执行将被清空)。上一条的追踪(统计)信息(即存入存储数组的信息)由于逻辑麻烦不进行过滤，只是不在屏幕上绘制。

6.对展示数组进行拥挤判断(参见下文)。

7.若存在选区，将选区绘制到帧中。绘制展示数组内记录的彩色追踪框及轨迹到帧中，其中轨迹从存储数组读取，并根据轨迹分别累加每个人的横向、纵向移动情况，若该行人移动记录不存在上一帧(如上一次记录在10帧前，或他是第一次被重识别)则不计算。根据最后的累加情况得出人群总体移动趋势，得出移动倾向(拥挤判断的第二阶段判断也采用了类似方案)，并根据拥挤flag给出是否拥挤。

8.将绘制完毕的帧展示到GUI的自定义Label。

9.返回第1步

#选区通过全局变量传递选区顶点坐标，若该顶点不存在则坐标为(-1,-1)，(-1,-1)。

拥挤判断时，真的计算"有大量追踪点交错"难以计算且会造成巨大运算量，故采用计算人群密集处的人群总体移动速度X人数，并与该人群人数进行比较达成类似效果。考虑到一般的人行路口发生人群均速度缓慢只有"人群整体没怎么动"或者"人群移动方向混乱"的情况，而这两种情况都显然是发生了拥挤才可能出现，因而采用该判断方法较为可行。

拥挤判断的步骤为：

1.读取展示数组内的点，读取拥挤判断参数。若展示数组空，直接结束拥挤判断。

　　其中参数有范围权，密度权，倾向权(都是我编的名字)。

　　范围权为进行判断的范围，表现为计算人群密度中的方圆XX像素内有XX人中的“方圆XX像素”，但计算具体像素时是通过视频宽度X范围权的方式算出，取值范围为0.95-0.05。

　　密度权为划出范围内的人数，表现为上述例子中的“有XX人”。考虑到与其设置得过高不如直接将判断范围缩小，取值范围为1-20(取1纯粹是测试需要)。

　　倾向权为根据行人移动速度判断是否拥挤时的门槛，通俗来讲是"疑似拥挤的人群整体移动速度低于多少时认为发生了拥挤"，考虑到实际应用情况可能千奇百怪(离得太近或太远)，取值范围为0.05-1.95。

2.检查每个有效行人(未框选选区时全画面内的检测行人都为有效行人,若框选了选区则中心处于选区)方圆(范围权X视频宽度)像素内人数是否超出(密度权)，并记录进缓存数组(仅存在于循环的本次执行中)。若超出，置拥挤flag为True，并继续记录知道记完，交给下一步继续判断。

3.若拥挤flag为False，直接回到第1步。若拥挤flag为True，读取疑似拥挤的行人的移动记录，并采用和上面一样的方案累加移动情况。

4.对累加速度计算速度绝对值，将速度绝对值X倾向权，并与人数比较。若速度绝对值X倾向权低于人数，则认为发生拥挤，并结束拥挤判断。乘以倾向直接比较人数，和计算人平均速度的效果一样，而减少了一次除运算。若速度绝对值X倾向权高于人数，认为行人虽然密集但移动有致，只是单纯的密集，不构成拥挤，并将拥挤flag置为False，回到步骤1