We are about to switch to a new forum software. Until then we have removed the registration on this forum.
I've been working on a way to use the sensors built in the latest GoPro to show the forces applied to the camera and use that info to also stabilise the image without using the built-in digital stabiliser. I finally found a way to extract the data, that I explain here: https://community.gopro.com/t5/Hero5-Metadata-Visualisation/Extracting-the-metadata-in-a-useful-format/gpm-p/40293 (It's tedious, I know). Edit: Now the data can be extracted easily. Just Uncompress this folder and drop your files on GPMD2CSV.bat (for Windows): http://tailorandwayne.com/GPMD2CSV.zip
So I want to share the code I'm using because I'm sure it can be improved and I want more people to use these data, so that GoPro cares about us and provides appropriate tools. I worked with my Hero5 Session, but if you own a H5 Black you will also have GPS data to work with. For the sketch to run, you need to extract the data in csv format as I explain in the previous link, then rename the video file as input.mp4. It is important to set the variable for the vertical field of view and the size() of the sketch, which should match the original file ratio. The sketch will stabilise the image based on the gyro and display info for the gyroscope (in RPM), accelerometer (G force) and temperature (Celsius).
Some issues I've found: - There is drift. Some of the functions compensate for it, but are quite imperfect. - Related to that. There is no compass sensor, so we can't have an absolute orientation to force a flat horizon or fully compensate the gyro drift. - For some reason very quick spins are not properly compensated. I would guess the sensor is not accurate at high angular speeds, but there might also be something wrong in my code.
Things to note: - I find the best way to use the stabilisation code to first optically compensate the image and generate extended margins. This is a good tutorial on how to do that (but this slows the workflow even more, of course): http://abekislevitz.com/gopro-tutorial-fisheye-removal/ - I think most customisable variables are explained, but let me know if they're not clear.
And here's the code. Please feel free to suggest improvements or alternatives.
Answers
Some changes I've made to minise the effects of sensor drift manually:
Declare this variable in the "customisable" section
float driftZ = 0.00309; //rads per second that we should compensate for in the Z axis. Might be different for each camera and situation. You can modify it on the go with the right and left keys to find the best value
Take it into account in calculations. After this line
preRotation.mult(millisecondsDifference);
add
Change
gyroDisplay.z += millisecondsDifference*float(table.getRow(lastRow).getString("GyroZ"));
for
gyroDisplay.z += millisecondsDifference*float(table.getRow(lastRow).getString("GyroZ"))-(driftZ*millisecondsDifference); //compensate for drift
After
add
displayData2();
The custom function nfj becomes
And we add these two functions to display and control drift on the go
and
Not sure if this is the cleanest way to explain changes. I'll try to keep an updated version of the sketch here: http://tailorandwayne.com/gyrocam.pde
Yes, but
returns
So we still get negative zeros
This works for me
Your current nfj() fails for when
float f = -0.0;
, while my version works! 8-XFor
float f = -1.1369292E-4;
, it outputs-0.00011369292042218149
if we allow 20 decimal digits.W/ only 3 decimal digits, it outputs
-0.000
, and 4 decimal digits:-0.0001
.B/c
-1.1369292E-4
isn't actually0
, the-
shows up even when using your updated fix! :-&In short, your latest posted fix isn't fixing anything for me here! :-@
At least my own alt() works for when it's
-0.0
. Check out the results below: :POops! Now I've found out why my side isn't working as yours! :-SS
My decimal separator in my OS is a comma
,
instead of a dot.
! b-(So your
float(s)
evals asNaN
here!!! :-&I need to change it to
float(s.replaceFirst(",", "."))
in order to work here. :-<Anyways, here's the fixed version for both of our versions: O:-)
So if I understood you, now both functions work equally well. Correct? They do on my end
Updated the Accelerometer calculations bit to take into account changes in accelerometre sampling pace. My accelerometer is quite inaccurate anyway, it reports 1.035 Gs while sitting flat.
Almost! Only diff. is that your version outputs 2 indent spaces instead of 1 when we pass
-0.0
to it. 8-|Cool, thanks
Now the data can be extracted easily. Just uncompress this folder and drop your files on GPMD2CSV.bat (for Windows): http://tailorandwayne.com/GPMD2CSV.zip
I have changed my sketch to work with this new system and to correct for several other things (gyroscope data shown was not correct, way to compensate accel inaccuracies...)
I keep an updated version here: http://tailorandwayne.com/gyrocam.pde Might think about setting up a Github instead.
Glad you resolved it, and thanks for sharing!
Consider posting the GitHub in the forum under Share Your Work. If others are interested in working with the GoPro and you are feeling generous you might also consider wrapping it up in a contributed library.
@jeremydouglass Thanks! I will try to do that once I have some spare time, and hopefully I'll also be able to extract more data that the v2.00 firmware has (iso, shutter speed...). I've never created a library before, but that could be an interesting challenge.
I see some problems though. The data would still need to be extracted with the external tools. I don't think you can include that within the library functionality.
Also, what could the structure of the library be? You call for the data of a frame, or does it include the functions of processing.video.* but with the syncronised data?
So here's what I first used this workflow for:
I decided to organise the data in Processing and do the image processing in After Effects, in order to keep image quality as high as possible considering the huge amount of transformations I wanted to make. So the sketch now has an option to export tables that can be copypasted to After Effects layers (the video itself for position and rotation or other types of layers for gauges with other info).
The sketch is pretty messy at the moment and I doubt I will find the time to put a library together, for a while, but might be useful if someone is trying to achieve something similar: http://tailorandwayne.com/gyrocam.pde
Fantastic! Thanks for sharing your work. How did you figure out how many milliseconds to offset the gyro data in time to line up with the video for stabilization? I'm finding if you put the gyro start time at 0 it is not lining up with the movie. It always needs to be offset by a frame or more. Is the correct offset stated in the metadata somewhere? Thanks in advance!
By trial and error. I don't think it's stated anywhere. I also find that the offset changes slightly depending on the format you are shooting
Thanks for the reply! Were you ever able to find an offset through trial and error that works every time, or do you need to use a different offset each time?
I would say the offset is constant for a specific format. I can't check, as I am travellig
Thanks again. Very interesting.
I published this in a Github to maximise the possibilities of anyone improving/reusing it: https://github.com/JuanIrache/gyrocam/
I don't have time to create a library (should learn to create libraries first!), and the demand does not seem very high. The GPMD2CSV tool should be published too in an organised way... I'll think about it.