Repository navigation
Stamp and geotag the samples of a timelapse by its GPS timestamps - #852
Merged
Merged
Conversation
This was referenced Oct 20, 2026
Interval sampling stamped each frame with the start time of the video plus its time in the video. A timelapse packs several seconds of capture into each second of video, so its frames were stamped that many times too close together. Geotagged from a GPX by those stamps, they all landed near the start of the track. Geotagged from the video's own track, they moved so far per second that the speed check could reject them: a 30x timelapse of a drive read as over 1,000 km/h. Interval sampling now reads the rate from the video's GPS clock, as GPX sync does, and stamps the frames at it. The start time is mapped back from the first GPS timestamps at the same rate. --video_duration_ratio, which used to apply to every video, now paces only the videos without a GPS clock, so that a ratio given for those leaves the other videos in the batch alone. Each video whose clock overrides a given ratio says so in a warning. The samples are then geotagged from the video's own track (the gopro, camm and blackvue sources) by their time since the first sample, while the track is timed in video seconds. It is now timed in GPS seconds, at the rate of its clock. That also fixes distance samples of a timelapse, which were already stamped with their capture times.
caglarpir
force-pushed
the
stamp-timelapse-samples
branch
from
October 21, 2026 09:44
c2541c0 to
484d281
Compare
The previous commit timed the GPS points of a timelapse at one rate from
its first timestamp. Distance samples are stamped with the GPS time of
their video time instead, and the first timestamp of a GoPro MAX
timelapse can be about 3 s early: in one, the camera moved 6 m at 8 m/s
in the 3.9 s to the next one. On two such timelapses (30x and 15x), the
frames that geotagged were placed a median of 36 m and 5 m from where
the sampler picked them, and the last 2 and 1 frames were stamped past
the end of the track:
The image time is 1.801 seconds beyond the GPX end point
Time the track by the timestamps, interpolated between them and
extrapolated beyond them at the clock's rate. Stamp interval samples of
a timelapse the same way, from the GPS time at video time 0, as distance
samples are.
On those two timelapses, distance samples now all geotag where they
were picked. Interval samples (0.5 s) stay where they were with
--geotag_source gopro, and with a GPX of the same track they move from
a median of 0.6 m and 0.04 m (4.4 m and 1.4 m at most) to within 1 cm.
Videos without a timelapse clock are unchanged.
caglarpir
added a commit
that referenced
this pull request
Oct 23, 2026
Since #888, GPX sync places a track, and sampling stamps frames, through every GPS timestamp of the video. The cameras whose timestamps leave a straight line record in real time, so video time maps to GPS time along a straight line, and their timestamps jitter about it. A GoPro stamps each block of 1.001 seconds of video up to 1.7 seconds off the line through the rest: on a GoPro MAX, the accelerometer timestamps of those blocks advance 0.996 to 1.006 seconds each, while their GPS timestamps advance 0 to 3.8 seconds. A PANOX V2 stamps some fixes up to 6 seconds late. #888 followed that jitter. It placed a GPX up to 1.4 s off the line on a GoPro HERO7, 1.6 to 2.9 s on GoPro MAX videos with poor GPS, and 5.9 s on a PANOX V2. It stamped interval samples 5 s apart from 3.7 to 6.3 s apart (HERO7), and 10 s apart from 7.2 to 12.8 s apart (PANOX V2). Its message put the move of a GPX on a GoPro MAX at up to 56 ms, and that of GoPro interval stamps at up to 1.5 s; on these videos, both moved by up to 2.9 s. The LabPano Pilot One and Era, which #888 was written for, need no more than a straight clock. Their timestamps fit one at 1.143 GPS seconds per second of video, within 0.3 s over 14 minutes (0.7 s on the Era). The clock was read at 1x only because any rate below the timelapse rate of 1.5 was rounded to 1. Read the clock as the least-squares line through the timestamps, at the rate it fits, anchored at their median as before, and use it everywhere: GPX sync places the track by it, interval samples and distance samples of the video's own track are stamped by it, and the geotagging stage times the video's track at its rate. The fit leaves out the timestamps that #888 showed to be wrong: those out of order, those before a jump of more than a day, and stale first ones. The rate is 1x when it is within 5% of 1x, or when it departs from 1x by less than 2 seconds over the timestamps. On sample videos, cameras that record in real time measure within 0.4% of 1x over 20 seconds or more, or 1.6% for a GoPro MAX whose GPS glitches. Clips of a few seconds measure up to 14% off 1x, a drift of at most 0.3 s. The LabPanos measure 1.093 to 1.143, a drift of at least 15 s. A rate above 1.5 must still show in the median step between timestamps, so one timestamp far off makes no timelapse. Timelapses get a straight clock too. Once their stale first timestamps are left out, those of GoPro MAX, MAX 2 and Rove timelapses lie within 0.33 GPS seconds of the line, but for one GoPro MAX timelapse within 0.82 (55 ms of video), less than the jitter of a normal video. On sample videos from 9 cameras: - Without a GPX, process writes the same tracks for all of them. - A GPX made from a video's own track moves onto the straight line: by up to 1.4 s on the HERO7, 2.9 s and 1.6 s on GoPro MAX videos with poor GPS, 0.65 s on a GoPro MAX 2, 5.9 s on a PANOX V2, and up to 0.06 s on other GoPros. Interval samples are stamped evenly, 5.000 s or 10.000 s apart, and those of a LabPano 11.426 s apart for 10 s of video. Distance samples of the video's own track are stamped by the clock, and their positions do not change. - A GPX made from a LabPano's own track lands within 0.26 s of its timestamps over 14 minutes, and within 0.61 s on the Era. GPX distance samples of the 2 fps Era are no longer dropped: #888 timed its frames alternately fast and slow, so half of them fell under the sample distance. One LabPano video is the exception: its GPS drops out for 6 seconds of video, its positions jump 64 m, and its GPS time advances 2 s over 8 seconds of video. A GPX of its own track is placed up to 3.8 s off its timestamps, and interval samples geotagged from it up to 65 m off its own positions. - GoPro MAX timelapses keep #852's results: their placements move by up to 0.05 s, and all their distance samples are described. - A GPX that ends exactly at a video's own first or last timestamp, as one made from its track does, can now miss a sample at the very start or end of the video, which is stamped just past it and reported as outside the track: 1 to 4 samples on 4 of these videos. A logger track that covers the video does not. - BlackVue, Viofo and Ricoh outputs do not change, but for 1 ms rounding of BlackVue GPX track times.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Interval sampling stamps each frame with the video's start time plus its time in the video. Each second of a timelapse spans several seconds of capture, so its frames are stamped that many times too close together:
--geotag_source gpx, the frames all land near the start of the track. A 5 s, 30x GoPro MAX timelapse, geotagged from a GPX of its own GPS track, comes out with a median error of 670 m, its frames spread over 21 m of a 1.4 km route.--geotag_source gopro, the frames are placed right but stamped 0.5 s apart for 15 s of travel, so the speed check rejects them (1,134 km/h).Distance samples of a timelapse are stamped with their capture times already, but
GeotagImagesFromVideotimes the video's track in seconds of video, so with--geotag_source gopronearly all of them fail as outside the track.Changes
_read_video_clock(), as GPX sync does since Sync a GPX to the GPS clock of a timelapse, even one too noisy to publish #849). It stamps the frames of a timelapse with the GPS time of their video time, interpolated between the video's GPS timestamps (and extrapolated at the clock's rate past them), as distance samples are stamped.--video_duration_ratioused to apply to every video. It now paces only the videos without a GPS clock, so a ratio given for those doesn't affect the other videos in a batch. A video whose clock overrides a given ratio logs a warning naming the clock's rate.GeotagImagesFromVideo(thegopro,cammandblackvueimage sources) times the track of a timelapse by its GPS timestamps, to match the stamps. One rate would not: the first timestamp of a GoPro MAX timelapse can be about 3 s early, so a track timed at one rate from it places distance samples metres to tens of metres off, and the last ones past its end.Videos without a timelapse clock are stamped and geotagged as before.
Verification
Two GoPro MAX timelapses (30x and 15x), each also geotagged from a GPX of its own GPS track. Interval 0.5 s, with #854 applied so that a single video stream is sampled (see the end). Median error against the video's own track at each frame's video time:
gpxgpxgoprogoprogopro: 150 of 150 and 83 of 83 frames geotagged, each where the sampler picked it, where main geotags 0 and 7. Also at 3 m and 10 m, and on an 87 s, 15x timelapse (577 of 577).gpxand with their own source, and a GoPro MAX video sampled by interval and by distance with its own source: output identical to main.mypy,ruff check,ruff format --checkandusort diffare clean.GoPro MAX
.360Interval sampling interleaves the two video streams of a
.360file, so its frames are stamped as if twice as late (#854 fixes that). Until then, on a.360timelapse the second half of the frames is stamped past the end of the track and fails withMapillaryOutsideGPXTrackError, where main placed every frame 127 m to 1.4 km off.With #851: the imports of
sample_video.py.