Repository navigation
Resolve an exiftool_xml pattern against the videos of video_process frames - #867
Merged
caglarpir merged 5 commits intoOct 22, 2026
Merged
Conversation
A misspelled source type, as in --geotag_source foo or gpx,foo, failed
with a ValueError traceback ("'foo' is not a valid SourceType"), and a
JSON source with a key the schema does not know, such as
{"source": "gpx", "path": "track.gpx"}
failed with a jsonschema ValidationError traceback. Both exited 1, as for
a crash.
They now raise MapillaryBadParameterError (exit code 2), naming the
supported source types and their aliases, or what the schema rejected
("'path' was unexpected"). This covers --geotag_source and
--video_geotag_source in process and video_process, which parse them the
same way.
…r image
A truncated GPX file, or a file that is no GPX at all, given as the GPX
to geotag images from failed the whole run with a RuntimeError traceback
("Error parsing GPX ...: GPXXMLSyntaxException"). A video geotagged from
the same file gets a MapillaryInvalidGPXError in its description. A GPX
path that does not exist failed with a RuntimeError too, and a GPX file
with no timestamped point with an AssertionError. An NMEA file failed
with a traceback in each of these cases, and when a sentence had no time
or date (TypeError), such as the void ones a receiver writes before its
first fix, or when the file had no RMC sentence to give the date
(UnboundLocalError).
Every image now gets a MapillaryInvalidGPXError in the description,
saying what is wrong with the file, and the run exits as for any other
file that fails to process. The file was given to geotag the images
from, so a mistyped path fails them, as it did, rather than leaving
them to the next geotag source without a word.
…is given The README says that --video_geotag_source applies to videos and --geotag_source to images. But the default sources were used only when neither option was given, so with --video_geotag_source alone, images had no source at all, and went missing from the description file without a word, as if they had not been there. That includes the frames video_process samples: `video_process VIDEO --video_geotag_source native` sampled the frames, then wrote an empty description file and exited 0. Geotag images by the default sources when only --video_geotag_source is given, as when neither option is. The videos are still geotagged by --video_geotag_source alone.
GeotagImagesFromVideo geotagged every sample by the track of every video it was given, since the samples moved from its constructor to to_description(). With the samples of two videos, each sample came out twice, the second time outside the other video's track, and the check that it returns no more images than it was given failed: `process SAMPLES --geotag_source gopro_videos --geotag_source_path DIR` crashed with an AssertionError for a DIR of two videos. Geotag the samples of each video by its own track, as before.
…rames
A pattern names the XML of a video after the video:
video_process VIDEO OUT --geotag_source '{"source": "exiftool_xml", "pattern": "%g.xml"}'
sampled VIDEO by its XML, then failed every frame with "Cannot find the
image in the ExifTool XML". To geotag the frames, video_process gives
every source the video import path, which overrides a pattern, so the
video itself was read as the XML. Without it, the pattern would have
been resolved against each frame, which has no XML of its own.
Resolve the pattern against the videos that the frames were taken from,
found in the video import path, for the videos whose XML it names. The
other frames, and images, are geotagged from the ExifTool XML as before.
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.
Stacked on #866; review the last commit.
Problem
A pattern names the ExifTool XML of a video after the video:
mapillary_tools video_process GS011498.360 out --video_sample_distance 5 \ --geotag_source '{"source": "exiftool_xml", "pattern": "%g.xml"}'sampled the video by its XML (#862), then failed every frame with "Cannot find the image in the ExifTool XML": 30 errors, exit 6, on a 95-second GoPro MAX clip. To geotag the frames,
video_processgives every source the video import path, which overrides a pattern, so the video itself was read as the XML. Without it, the pattern would have been resolved against each frame, which has no XML of its own.Fix
Resolve the pattern against the videos that the frames were taken from, found in the video import path, for the videos whose XML it names. Other frames, and images, are geotagged from the ExifTool XML as before.
Verification
mypy --python-version 3.9,ruff check,ruff format --checkandusort diffare clean.