ElvinC / gyroflow

[INACTIVE LEGACY VERSION, FIND THE PROJECT HERE: https://github.com/gyroflow/gyroflow] Video stabilization using IMU motion data from internal or external logs
http://gyroflow.xyz
GNU General Public License v3.0
611 stars 90 forks source link

Not needed to sync Hero 8 or Hero 9 GPMF gyro #51

Closed MiniGod closed 3 years ago

MiniGod commented 3 years ago

On the Hero 8 and Hero 9, the gyro is in perfect sync with the video. Video+Gyro sync should not be needed.

This applies to the Labs firmware, but maybe also the latest normal firmware? Old firmware for Hero8 is not in sync (the firmware that came with the camera back in the day).

dentex commented 3 years ago

I was wandering the same thing. If it can be of any help, I own a Hero8 with firmware version 02.50 and when using ReelSteady, it doesn't set any sync point (neither it saves that binary accessory files it creates with other GoPro cameras) so I inferred it assumes the gyro in sync by default.

MiniGod commented 3 years ago

According to this comment from a GoPro employee, post stabilization software (Reelsteady?) use use the sensor fusion streams CORI (Camera Orientation), IORI (Image Orientation) and GRAV (Gravity vector), not the GYRO or ACCL.

I guess it wouldn't take that much work to change gyroflow to not use gyro data, but provide the camera orientation directly.

Excerpt from https://github.com/gopro/gpmf-parser/issues/80#issuecomment-546714409:

Data like ACCL & GYRO are still needing work to improve the phase precision (I think is about 10ms delayed in the modes I've tested.) However ACCL & GYRO are less important compared with the sensor fusion data like CORI (Camera Orientation), IORI (Image Orientation) and GRAV (Gravity vector). All the MAX and HERO8 horizon leveling and post stabilization effects are now based solely on these new streams. As these new streams are one sample per frame, you don't need to use STMP. The STMP was not intended for post synchronization, as it has already been used for in-camera synchronization.

ElvinC commented 3 years ago

Oh interesting, thanks a lot for the info. That explains the delays observed using the raw gyro data. Should be possible to do then.

dentex commented 3 years ago

Translating for a non-insider, does this mean that for the moment with gyroflow it's normal to observe sync points with a certain offset? (I observed it's often kinda small).

ElvinC commented 3 years ago

normal to observe sync points with a certain offset?

Yes, pre-computed camera orientations are available for each video frame, but the raw gyro log is a separate track that can have some delay compared to the video.

MiniGod commented 3 years ago

Some quick tests with using CORI looks very promising.

CORI appears to be [w, -x, y, z] and signed int 16, so I used division by 0x7fff.

So in GPMF_gyro.py

# similar to omega / parsed_gyro
self.parsed_cori = np.array(cori) * (1, -1, 1, 1) / 0x7fff

Then in GyroIntegrator I used parsed_cori as orientation_list (instead of integrating gyro data).

I only used stabilizer.py, not gyroflow.py (not using the GUI).

This is the result with stab.manual_sync_correction(0,0):

https://user-images.githubusercontent.com/60520/133005727-f983061b-7064-4be6-8e8e-25f07bab4971.mp4

ElvinC commented 3 years ago

Very nice!

MiniGod commented 3 years ago

I've tested some actual drone footage from both Hero 8 and Hero 9, I can confirm that this is perfectly in sync. Some jitter I've had difficulties with before is now perfectly stabilized. Also, coordinates are the same on Hero 8 and Hero 9.

MiniGod commented 3 years ago

Fixed by #100