Several issues found in SRT parsing and GPS altitude handling

ODM
1

Hello,

While working with video + SRT workflows in ODM (especially for RTK / ground-based video use cases), I identified several issues that can lead to loss of precision or incorrect metadata parsing. I’m sharing them briefly with suggested fixes.

Issue 1 – GPS altitude is rounded when written to EXIF

File: opendm/video/video2dataset.py

Altitude values are correctly parsed from the SRT file, but they are rounded to an integer when written to EXIF:

gps_ifd[piexif.GPSIFD.GPSAltitude] = float_to_rational(round(altitude))
# 192.048 -> 192

This causes loss of vertical accuracy, which is critical for RTK and precise ground surveys.

Suggested fix:

gps_ifd[piexif.GPSIFD.GPSAltitude] = float_to_rational(altitude)

or (to preserve millimeter precision with a stable denominator):

gps_ifd[piexif.GPSIFD.GPSAltitude] = float_to_rational(round(altitude * 1000) / 1000)

Issue 2 – Missing comma in shutter regex list

File: opendm/video/srtparser.py

Due to a missing comma, two regex patterns are unintentionally concatenated into a single string:

shutter = match_single([
    "shutter : \d+/(\d+\.?\d*)"
    "SS (\d+\.?\d*)"
], line)

Suggested fix:

shutter = match_single([
    "shutter : \d+/(\d+\.?\d*)",
    "SS (\d+\.?\d*)"
], line)

Issue 3 – Incorrect zero check when parsing latitude/longitude/altitude

File: opendm/video/srtparser.py

The following condition compares a string to an integer and therefore always evaluates to True:

lambda v: float(v) if v != 0 else None

Suggested fix:

fv = float(v)
return fv if fv != 0 else None

Issue 4 – RTK altitude regex only matches integers

File: opendm/video/srtparser.py

The current regex does not capture floating-point RTK altitude values:

("RTK ... (-?\d+)\)", ...)

Suggested fix:

(-?\d+\.?\d*)

These issues mainly affect GPS/Z accuracy and metadata consistency, particularly in high-precision RTK and ground-based video workflows.

I’d be happy to help with testing or preparing a PR if needed.
Thanks for the great work on ODM.

1 Like
2

Hi there.. i’ve recently experienced what you say.. i’ve had to do a job in 2 separate times because of the rain (i use a mavic3E+RTK)..

  • The first run has been done with classic setup, taking photo delayed by time 0,X sec each
    For an area of around 28.000sqm and 200m points

  • The second run has been done with (always RTK on) video (video +SRT file ofc)
    Area of 54sqm :sob: and 47m points

Obviously i can’t overlap the two models and probably will need to redo the whole work :-/
(i use webODM 2.8.1)

1 Like
3

@Kemal, I think you can open a pull request - information here: Pull requests · OpenDroneMap/ODM · GitHub

2 Likes
4

Yes, a pull request would be most appreciated. I created the relevant issues on repo:

1 Like
5

I’ve submitted a pull request to address the SRT parsing and GPS altitude issues discussed here.
Thanks for the guidance!

1 Like
6

Excellent! Thank you. Do you have a good test dataset I could use?

1 Like
7

Disregard. I’ll test with this: https://github.com/pierotofy/drone_dataset_dji_video/archive/main.zip

1 Like
8

Understood. In my workflow, the video and SRT files are generated using position data from an RTK GNSS receiver. After the update, I will also test it with my own dataset. I can share a sample dataset if needed.

1 Like
9

An additional sample dataset would be great. It will be interesting to see the impact with that precision and accuracy of data.

10

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.