Lap Timer

랩 분할을 측정하려면 휴대폰 카메라를 사용하십시오.

The app uses one of your phone cameras to measure lap splits. After initialisation of about 1 s, the video stream is monitored for changes, and the duration between substantial changes in the feed is shown on the screen.

FEATURES

- Select which camera, resolution, and frame rate to use

- Shows last 10 splits on the screen

- Shows image processing time in milliseconds on the screen (so that you can select a slower resolution to enable real-time operation. Processing time needs to be less than 1 divided by the chosen frame rate, e.g. frame rate 30 -> processing time needs to be less than 33 ms).

USE

Set up your camera to point on a restricted area that the lap will pass through with no movement in view (e.g. position camera high, point to ground or point the camera at a wall and have the track pass between the camera and the wall).

I use the app to time radio controllable car lap times, and stream the phone view onto my TV with google home to have good view of the lap times in real time.

NOTE

Changes in light, shadows, moving the phone etc will trigger splits due to the change detection algorithm.

TECHNICAL DETAILS

Split detection from the video is based on background subtraction by using a simplified version of the technique I developed for https://doi.org/10.1016/j.jneumeth.2011.02.010 study. The background model is built by starting from a frame with all 0, and updating the background pixel values with 1/frame rate from the current frame (and 1-1/frame rate from the background model). The simplification from the study is that only a single background candidate is maintained (as opposed to five). Pixels that are more than 20 values away from the background are flagged as non-background (i.e. a change). The number of non-background pixels is counted for each frame and a baseline value is maintained using the same learning process as is used for the background model (i.e. 1/frame rate from the current number of changed pixels), and a split is flagged if the current count is more than twice the baseline count value.

Only luminosity values are considered (luminosity [Y], blue [U], and red [V] with YUV422_8888 is requested from the camera) and only every 4th pixel both in columns and rows is considered.This results in only one of every 16 pixels being considered (15 out of 16 pixels, and all U and V componenets are simply ignored). With this downsampling of the video feed my phone (Honor 20 Lite [HRY-LX1T]) was able to process around 30 (1536 x 864 pixel) frames per second, i.e. it consistently maintained real-time operation. Processing every pixel slowed the processing down to about 12 frames per second, and every fourth pixel to 25 frames per second. To achieve this frame rate I wrote renderscript kernels to pre-calculate pixel indices for background detection, and all background detection, and pixel counting is executed with renderscript kernels. This resulted in between 4 to 10 fold improvements in computation time compared to using the CPU for the same calculations.