You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
How did you install ODM? (Docker, installer, natively, ...)?
Docker running on MacOS
What is the problem?
Currently the video processing code makes the assumption that all srt files will contain exactly the latitude/longitude/altitude keys. https://github.com/OpenDroneMap/ODM/blob/master/opendm/video/srtparser.py#L56
Whenever there is an invalid altitude key, we end up erroring out in the underlying call to self.ll_to_utm.TransformPoint(lat, lon,alt) and all further dataset processing stops. In some versions of the srt files produced by newer dji drones, we have [rel_alt: xxx abs_alt: xxx] fields as opposed to a fixed altitude key. See attached for an example.
What should be the expected behavior? If this is a feature request, please describe in detail the changes you think should be made to the code, citing files and lines where changes should be made, if possible.
There are a few ways this should be addressed.
We definitely be checking for values before calling out to self.ll_to_utm.TransformPoint. We already do so for lat/lon, but we're not doing so for alt. That's likely the easiest short term fix.
We should wrap the calls to get_gps in a try-catch to prevent erroring out causing a cascading failure which prevents other datasets from being processed.
How can we reproduce this? What steps did you do to trigger the problem? If this is an issue with processing a dataset, YOU MUST include a copy of your dataset AND task output log, uploaded on Google Drive or Dropbox (otherwise we cannot reproduce this).
I've included a srt file attached here which contains the non altitude srt altitude keys. DJI_0664.SRT.zip
I've also uploaded a video and corresponding srt to google drive.
Otherwise, this should be easily reproducible from any SRT data that does not contain altitude information.
If I get the time I'll try submitting a fix for this myself since it's pretty small. Opening the issue for visibility and discussion if there's a different way this should be handled.
The text was updated successfully, but these errors were encountered:
For Anyone finding this issue, a temporary fix until this is patched, use this regex on your SRT file to replace the [rel_alt: xxx abs_alt: xxx] values with just a regular [altitude: xxx] value: "(rel_alt:.* abs_alt:)" replace with: "altitude:"
How did you install ODM? (Docker, installer, natively, ...)?
Docker running on MacOS
What is the problem?
Currently the video processing code makes the assumption that all srt files will contain exactly the latitude/longitude/altitude keys.
https://github.com/OpenDroneMap/ODM/blob/master/opendm/video/srtparser.py#L56
Whenever there is an invalid altitude key, we end up erroring out in the underlying call to
self.ll_to_utm.TransformPoint(lat, lon,alt)
and all further dataset processing stops. In some versions of the srt files produced by newer dji drones, we have[rel_alt: xxx abs_alt: xxx]
fields as opposed to a fixedaltitude
key. See attached for an example.What should be the expected behavior? If this is a feature request, please describe in detail the changes you think should be made to the code, citing files and lines where changes should be made, if possible.
There are a few ways this should be addressed.
get_gps
in a try-catch to prevent erroring out causing a cascading failure which prevents other datasets from being processed.How can we reproduce this? What steps did you do to trigger the problem? If this is an issue with processing a dataset, YOU MUST include a copy of your dataset AND task output log, uploaded on Google Drive or Dropbox (otherwise we cannot reproduce this).
I've included a srt file attached here which contains the non
altitude
srt altitude keys. DJI_0664.SRT.zipI've also uploaded a video and corresponding srt to google drive.
Otherwise, this should be easily reproducible from any SRT data that does not contain altitude information.
If I get the time I'll try submitting a fix for this myself since it's pretty small. Opening the issue for visibility and discussion if there's a different way this should be handled.
The text was updated successfully, but these errors were encountered: