The 3D flight map learns two things about where the camera really was.
Gimbal angles from the video. Air 3S and newer write no gimbal fields to the SRT, so every gaze pass on the 3D map came up "estimated". The MP4's own telemetry stream has the real yaw and pitch on every frame, and flightmap --gimbal-from-video now reads it and joins it frame by frame onto the SRT track. It's opt-in because ExifTool has to walk every sample of every video (about 15 seconds per gigabyte); without the flag, a 3D map that notices angles it could have used says so once. The desktop app has a matching checkbox in the 3D options. Needs ExifTool (dji-embed doctor --install exiftool). SRT values are never overwritten, and the Mini series still uses --flight-log.
Along the way: a level gimbal has no pitch tag in the stream at all, and an aircraft on the ground no relative-altitude tag, because protobuf drops fields at their default value. Those now read as 0, not unknown, which also tidies up sidecar-less convert runs.
The ground it launched from. If you press record after take-off, the clip's first sample is airborne, often over terrain quite unlike the launch site. The 3D map used to take its ground reference from that first sample, which put the flight sculpture, the cockpit view and the gaze at the wrong height and could chop the curtain short. It now takes the reference from a sample that is actually on the ground (the start when it qualifies, otherwise the landing), and badges the cockpit view when a clip never touches down.
Thanks to a pair of deliberately flown test clips for pinning the second one down.
What's Changed
- feat(flightmap): read gimbal attitude from the MP4 djmd stream when the SRT has none (#546) by @CallMarcus in #547
- fix(flightmap --3d): ground reference from a sample on the ground, not sample 0 (#548) by @CallMarcus in #549
- release: prepare version 2.13.0 by @CallMarcus in #551
Full Changelog: v2.12.1...v2.13.0
