Repository navigation
OpenOSV 0.6.2
OpenOSV 0.6.2: the Avata 360's calibration, read as the aircraft writes it
One report, two rounds. 0.6.1 guessed at the schema name; the reporter's osvtool probe output (#7, thank you) showed the name was right and the lens records were not what the Osmo 360 writes. 0.6.2 reads them.
What's fixed
- An Avata 360 clip was refused as "no lens calibration" with the schema read correctly (#7). The Avata 360 writes each lens's extrinsic as Euler angles only (no quaternion, four zeros in its copy), so every record failed the calibration test; and it keeps its lens records in
native_refine_farwith nothing usable innative_refine. The decoder now builds the quaternion from the angles by the relation the Osmo 360's own records follow (checked on every populated slot of the sample clip: better than 0.03 degrees), and the native choice falls back throughnative_refine_far, DJI's own order. The clip opens and stitches. A quaternion the camera wrote is never replaced, so nothing changes on an Osmo 360. - An Avata 360 clip no longer opens looking at the ground, or levelled upside down. Its master lens looks down and its nose is the body's -Z, so the view is placed in that frame before any attitude is read: forward, sky up. Its stored attitude has no verified reading yet (the default one puts up 141 degrees from true up on the clip measured), so stabilisation stays off on it, with a log line, rather than level the world by a reading that is wrong.
osvtool --attitude-convention <reading>still builds the track for anyone with footage to verify one. osvtool probe --reportis the one command for a bug report. It prints every field of sample 0 as the camera wrote it (--rawprinted only a node count before), a line per calibration record saying what it holds and what keeps it from being usable, and a new attitude section: which sources every frame carries, the first frame's values, the readingautowould use and whether it is verified on the product. It writes the JSON beside the clip and says what to attach. The "no lens calibration" message points at it.
Good to know
- Still built without an Avata 360 clip to test on: the lens numbers and the frame come from a contributor's measurements of two recorded clips against DJI Studio's output. If 0.6.2 opens yours, please say so on #7. If the stitch or the direction looks wrong, a frame of OpenOSV's output next to DJI Studio's would settle it.
- Stabilisation on the Avata 360 is off until its attitude reading is verified. Horizon Leveling and RockSteady need a clip to check against; the Osmo 360 is unchanged.
- Everything else is 0.6.1: the stitch, the colour, the plug-ins and the LUTs are unchanged.
- Tests before this release: the metadata, protobuf and calibration suites (with new cases for the Euler extrinsic, the
native_refine_farfallback and the aircraft's frame), the attitude suite, the importer's CPU suite and the CLI suite with the sample clip, all green. No GPU suite was run: no kernel changed.
How to update
Close your editor, unzip the zip for it and double-click Install.cmd. Premiere users: launch it once holding Shift.
Downloads
OpenOSV-0.6.2-premiere-windows-x64.zip: Premiere ProOpenOSV-0.6.2-resolve-windows-x64.zip: DaVinci Resolve (preview)OpenOSV-0.6.2-vegas-windows-x64.zip: VEGAS Pro 17.0 (experimental)
ffmpeg-9.0.1-source.tar.gz and ffmpeg-9.0.1-vcpkg-port.zip are the source of the FFmpeg build the zips ship (LGPL-2.1).
SHA-256
0d66c7e51a92aa00ab88340004ef80eea125f318eaa8acc093e8ed54865e2cd5 OpenOSV-0.6.2-premiere-windows-x64.zip
e907e625b7163a6c3671d30be5b84e27f76f56e66b73176c6962d76960a4f0ee OpenOSV-0.6.2-resolve-windows-x64.zip
555782d78393811f17e6a58ff433cda63079941cf538ccbebdcc82fecf7a8467 OpenOSV-0.6.2-vegas-windows-x64.zip