Repository navigation
Keep a timelapse's clock rate when the GPX starts with the video - #853
Merged
caglarpir merged 3 commits intoOct 22, 2026
Merged
Conversation
caglarpir
force-pushed
the
gpx-start-time-keeps-clock-rate
branch
from
October 21, 2026 09:33
45ce2cb to
6351511
Compare
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.
This was referenced Oct 21, 2026
caglarpir
force-pushed
the
gpx-start-time-keeps-clock-rate
branch
from
October 21, 2026 11:49
6351511 to
9c725cd
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.
--interpolation_use_gpx_start_time places the GPX from the start of the video instead of by the video's GPS clock. It skipped reading the clock altogether, and with it the clock's rate, so a timelapse got its GPX laid out at 1x: a 5 s, 30x timelapse got 157 s of GPX, and distance sampling picked 5 frames along its first 12 m instead of 148 along the 1.4 km route. The clock is now read in that mode too, and placed at the start of the GPX, so that only its rate is used. A video that is not a timelapse has a rate of 1, and is placed as before. The coverage check still sees such a track as one that no clock placed: the clock gave it only its pace.
caglarpir
force-pushed
the
gpx-start-time-keeps-clock-rate
branch
from
October 22, 2026 09:04
9c725cd to
a8c3147
Compare
caglarpir
added a commit
to caglarpir/mapillary_tools
that referenced
this pull request
Oct 22, 2026
The previous commit clips a GPX track whenever a clock gives its pace along the video, so that where the video ends along it is known. Since the GPS clock's rate is kept for --interpolation_use_gpx_start_time (mapillary#853), that includes a track the option starts with the video: it is clipped as any other, and a GPS logger left running past the end of the video uploads only the part of the track that the video covers. Say so in the docstrings, which said a clock had to place the track, and test it among the tracks a clock paces.
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
--interpolation_use_gpx_start_timeskips reading the video's GPS clock, and with it the clock's rate (#849), so a timelapse gets its GPX laid out at 1x. Distance sampling a 5 s, 30x GoPro MAX timelapse picks 5 frames along the first 12 m of its 1.4 km route.Changes
_check_coverage()is unchanged.Verification
mypy,ruff check,ruff format --checkandusort diffare clean.With #851: no changes needed. Its rules then apply to this mode as to any track placed at the start of the video: a miss caused by
--interpolation_offset_timeraises, with the advice to check the offset. Merged with #851 (717bc81): no conflicts, and its tests for this mode pass.