Skip to content

Stamp and geotag the samples of a timelapse by its GPS timestamps - #852

Merged
caglarpir merged 2 commits into
mapillary:mainfrom
caglarpir:stamp-timelapse-samples
Oct 22, 2026
Merged

caglarpir merged 2 commits into
mapillary:mainfrom
caglarpir:stamp-timelapse-samples

Conversation

@caglarpir

@caglarpir caglarpir commented Oct 20, 2026 •

Copy link
Copy Markdown
Contributor

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:

  • With --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.
  • With --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 GeotagImagesFromVideo times the video's track in seconds of video, so with --geotag_source gopro nearly all of them fail as outside the track.

Changes

  • Interval sampling tells a timelapse by the rate of the video's GPS clock (_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_ratio used 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 (the gopro, camm and blackvue image 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.
  • The telemetry is read once per video. If it fails to parse, the warning is now "Unable to read the telemetry of ...".

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:

main this PR
30x, gpx 670 m < 1 cm
15x, gpx 85 m < 1 cm
30x, gopro rejected (speed) < 1 cm
15x, gopro 0 m < 1 cm
  • Distance samples with gopro: 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).
  • Normal-speed videos: GoPro HERO7 and HERO8, BlackVue and Insta360 Pro sampled by interval with gpx and with their own source, and a GoPro MAX video sampled by interval and by distance with its own source: output identical to main.
  • Unit: 921 passed, 18 skipped, 1 xfailed. Integration: 69 passed. Doctests, mypy, ruff check, ruff format --check and usort diff are clean.

GoPro MAX .360

Interval sampling interleaves the two video streams of a .360 file, so its frames are stamped as if twice as late (#854 fixes that). Until then, on a .360 timelapse the second half of the frames is stamped past the end of the track and fails with MapillaryOutsideGPXTrackError, where main placed every frame 127 m to 1.4 km off.

With #851: the imports of sample_video.py.

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
caglarpir force-pushed the stamp-timelapse-samples branch from c2541c0 to 484d281 Compare October 21, 2026 09:44
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 caglarpir changed the title Stamp interval samples of a timelapse with their capture times Stamp and geotag the samples of a timelapse by its GPS timestamps Oct 22, 2026
@caglarpir
caglarpir merged commit bffc283 into mapillary:main Oct 22, 2026
16 checks passed
@caglarpir
caglarpir deleted the stamp-timelapse-samples branch October 22, 2026 11:25
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant