Fix OPK computation for oblique/rotated camera orientations and prefer gimbal yaw for DJI

[thadwald]

This PR improves camera orientation handling for DJI drones with oblique or non-standard camera mounts.

When parsing XMP values, Xmp.DJI.GimbalYawDegree (world-referenced) is preferred over Xmp.DJI.FlightYawDegree when available
Flight yaw reflects aircraft heading; gimbal yaw reflects actual camera pointing direction
Critical for flights where the gimbal is rotated independently of aircraft heading

The change also refactors OPK rotation matrix to include camera roll

The refactored cbb reduces to the original [[0,1,0],[1,0,0],[0,0,-1]] when roll=0, so behavior is unchanged for standard configurations.

Tested with DJI M3E and Zenmuse X5S oblique imagery and standard nadir datasets. Nadir datasets produce identical results to the original implementation. Oblique datasets work fine.

Also tested with Sheffield park 1 and Güterweg Ritzing - Helenenschacht datasets. Gimbal positions look correct, and model solves correctly with OpenSFM Algorithm set to triangulation.

[YanNoun]

Does it work with the dataset mentioned in this issue mapillary/OpenSfM#1098 ? This one has 180 roll images so there’s a 180-roll check + axis flip to perform to make it work.

[thadwald]

I have ported your commit to opensfm, to the compute_OPK function of ODM:

YanNoun/OpenSfM@dd18fe7

It produces identical (correct) results as my fix on my branch does with DJI M3E data, including with the 180-roll images.

I suggest that if you keep the compute_OPK function in ODM then just copy your opensfm one instead of using mine. It's much cleaner.

[thadwald]

Does it work with the dataset mentioned in this issue mapillary/OpenSfM#1098 ? This one has 180 roll images so there’s a 180-roll check + axis flip to perform to make it work.

I have also tested your new OPK procedure on the dataset mentioned. It works fine.

[thadwald]

To straighten up some potential confusion/miscommunication:
This PR needs to be removed because while It fixes the 180º DJI issue , it fails to address the issue with NED frame Z axis somehow being incorrectly aligned with ECEF Z, which causes angle errors that only emerge off-nadir.

Would it be any help if I submitted a PR that merges your changes to the OPK calculation from openSFM?