Skip to content

Apply the interpolation options to videos geotagged from a GPX - #851

Open
caglarpir wants to merge 1 commit into
mapillary:mainfrom
caglarpir:process-video-interpolation-options
Open

caglarpir wants to merge 1 commit into
mapillary:mainfrom
caglarpir:process-video-interpolation-options

Conversation

@caglarpir

@caglarpir caglarpir commented Oct 20, 2026 •

Copy link
Copy Markdown
Contributor

Fixes #827

Problem

process ignored --interpolation_offset_time and --interpolation_use_gpx_start_time for videos. They reach the image geotaggers through SourceOption.interpolation, but the GPX video geotagger read them only from VideoSyncOption, which only distance sampling sets (#841). The track uploaded with a video stayed where the GPS clock of the video, or the start of the video, put it, whatever the options said.

Fix

  • GPXVideoExtractor reads both options from SourceOption.interpolation, which process sets on every source. Sampling sets it too, unless a source has options of its own, as process_geotag_properties() does. VideoSyncOption keeps only the start time, and with it the check that a GPX can start with the video. That check stays out of process, whose users can't pass the --video_start_time it asks for.
  • The offset moves the track along the video. The timestamps of its points stay those of the GPX, just as an image geotagged with the offset takes the time of its position along the GPX. Only sampling shifts them as well, for the geotagging stage to add the offset back.
  • The README no longer says that offsets can't be applied with --video_geotag_source.
  • The coverage check from Reject GPX tracks that miss the video, as placed on its timeline #848 judges the track where the options place it, as it already did when sampling: an offset that moves the track off the video fails it.

Verification

First point of MAPGPSTrack (ms) for the GoPro MAX test video, with a GPX that starts 2.59 s before its GPS clock:

options before after
none -2589 -2589
--interpolation_use_gpx_start_time -2589 0
--interpolation_offset_time 2 -2589 -4589
--interpolation_use_gpx_start_time --interpolation_offset_time 2.5 -2589 -2500

The timestamp of that point is 2019-11-18T23:44:40Z in every case, the time the GPX recorded it.

Without the options, process gives the same descriptions as main for the test data. video_process gives byte-identical frames and descriptions, with and without them.

@meta-cla meta-cla Bot added the cla signed label Oct 20, 2026
process ignored --interpolation_offset_time and
--interpolation_use_gpx_start_time for videos. They reached the image
geotaggers through SourceOption.interpolation, but the GPX video
geotagger read them only from VideoSyncOption, which only distance
sampling sets. The track uploaded with a video stayed where the GPS
clock of the video, or the start of the video, put it, whatever the
options said.

GPXVideoExtractor now reads them from SourceOption.interpolation, which
process sets on every source. Sampling sets it too, unless a source has
options of its own, as process does. VideoSyncOption keeps only the
start time, and with it the start-time check, which stays out of
process: process has no --video_start_time to offer.

The offset moves the track along the video. The absolute times of its
points stay those of the GPX, just as an image geotagged with the offset
takes the time of its position along the GPX. Only sampling shifts them
as well, for the geotagging stage to add the offset back.

Without the options, process gives the same tracks as before, and
video_process the same frames and descriptions, with or without them.

Fixes mapillary#827
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.

--interpolation flags do not work with "process" command?

1 participant