631

(2 replies, posted in Bug reports)

Hi,
The "Lock segments length" will force the lines to keep whatever size they had when you clicked the option. So when you move the ankle joint for example, it won't move freely around, instead it will keep the size of the leg the same.

The bike fit tool doesn't display the segments length, however this can be changed in the XML description of the tool which is user-editable.

Go to Kinovea program files folder, and under "DrawingTools\Custom" open the file "Bike fit.xml" in a text editor.
Under the whole <Segments></Segments> block you can add the following:

<Distances>
    <Distance point1="4" point2="5" />
    <Distance point1="5" point2="6" />
</Distances>

This will add length measurement for the thigh and leg segments. You can make your own changes as you like. Refer to the Segments section above for the points id.

Hi,
Yeah no solution at the moment, sorry about that. Personally I use AviSynth and VirtualDub when I need to preprocess videos for rotation/crop and whatnot. But it's more of a programmer's tool and still requires to re-save the video so the workflow is not that streamlined.

This is becoming close to the top requested feature at the moment though. I will have another look at it at some point to see if doing this at the image level just before rendering is acceptable performance wise.

633

(2 replies, posted in Cameras and hardware)

Sometimes for some reason you have to go into the settings for the camera in Kinovea (cog icon or click the infobar at the top) and change the stream format or the framerate to something else and apply. Then you can change back if you want.

634

(14 replies, posted in General)

Do you see the thumbnail for the camera in the camera list tab?
Could you collect the log file (see in help menu to get to the folder containing it) and send it over at joan at kinovea dot org, thanks.
Also, try the following: right click the thumbnail of the camera and select "Forget custom settings", if you are using the installed version, to remove the settings set with the previous version.

OK.
When you do the capture, whether in NCH Debut Video or in Kinovea, try to have almost nothing else running on the computer so the compression on the fly has more chances to sustain the framerate. Also, try to set the capture file target on an SSD if possible, it will also decrease chances of frame drops. If your camera supports MJPEG streams, doing the capture in Kinovea might give the best performance as it will store the frames coming straight from the camera without decompression/recompression.

Hypothesis: the file on the left has non constant framerate. The capture application set a custom timestamp to each frame as it was capturing them. Marked the final file as 30fps but in reality using non-constant intervals between the frames. And there might have been frame drops during the capture process, so some frames/timestamps are missing, and the resulting video is faster than expected.

Variable framerate is pretty rare and not supported in Kinovea, but the timestamp is nonetheless read from the metadata associated with the frame, so this could explain the behavior. 

Do you have a small example of such file that you could send me (joan at kinovea dot org) or upload somewhere, to verify that hypothesis?

What happens to the timestamps when you read this file on its own? Do they also progress in a non-constant fashion? Note that you can set the time format to "total milliseconds" to make it easier to experiment maybe.

To get the complete picture, what is the FPS value read by Kinovea? This is visible in the info bar above the video. Also please confirm that both videos are at 100% playback speed and the value of checkbox in Preferences > Playback > General > "Link speed sliders when comparing videos". Also the value in menu Video > Configure video timing > High speed camera > Capture framerate. Although these options did not exist in 0.8.15 so it's unlikely the culprit.

The timestamps in Kinovea should not diverge, that definitely smells like a bug somewhere. What happens when you click a random location in the common navigation bar at the bottom?

The way it's supposed to work is that the common time position is computed first and then it is mapped to each individual video and they are adjusted accordingly. What you describe would be an issue in the time mapping for this particular video, but it's especially strange if they are coming from the same capture software.

Do you have a way to check if this video is playing back at the expected speed when it's played alone in its own screen?

Forgot to ask, do you mean the content/action seen in the video is off but the timestamps are in sync, or do the timestamps diverge as well?

Thanks for the report.

If you open the two videos but invert the screens they are loaded in, does the desynchronization go in the same direction or in the opposite direction?

It's possible that the right screen gets less CPU time but 640x480@30 shouldn't be an issue. Do you see the right video lagging behind?

What happens if you open the same video twice and sync it, does one of them also drift compared to the other?

640

(14 replies, posted in General)

This is Kinovea 0.8.26.
This version introduces new kinematic analysis tools and focuses on polishing existing features and fixing bugs.


1. General

It is now possible to run multiple instances of Kinovea at the same time by changing the option under Preferences > General > Allow multiple instances of Kinovea.

http://www.kinovea.org/screencaps/0.8.26/0826-multipleinstances.png

2. Annotation

The management of the opacity of drawings was simplified.
Instead of having a needlessly complicated dialog on each drawing with a "persistence" value, all the drawings are now either always visible or follow a global option for fading in/out of their reference frame.

The global value for this fading is set under Preferences > Drawings > Opacity.

http://www.kinovea.org/screencaps/0.8.26/0826-opacity.png


3. Measurement

General

It is now possible to export the time series of trackable drawings like the angle tool and custom tools. See Angular kinematics and Linear Kinematics below.

The "data analysis" menu has been removed from individual trajectory drawings and placed in a global menu at Tools > Linear kinematics, as the window now combines data for all trajectories. See Linear kinematics below.


Angle tool
The angle tool was improved to be more versatile. It supports three new options to switch between signed or unsigned angle, change direction from counter clockwise to clockwise, and switch display to the supplementary angle.

The following screenshot shows the same angle object with different options applied.
http://www.kinovea.org/screencaps/0.8.26/0826-angle.png

Linear kinematics

The linear kinematics window is now found under the menu Tools > Linear kinematics and supports multiple sources. You can check/uncheck trajectories to be included in the analysis. The name and color for the plot are taken from the objects configuration.

http://www.kinovea.org/screencaps/0.8.26/0826-linearkinematics.png

When comparing several trajectories, three time models are available: absolute, relative and normalized. "Absolute" time will simply respect the original timeframe of the trajectory. "Relative" time will align all trajectories to a common starting point, to compare how they evolve over time. "Normalized" time will stretch trajectories to a common starting and ending point, to compare their "shape" over time.

Exporting trajectory data to CSV will export a common time column first and then one column per trajectory.

The trackable drawings (point, line, angle, custom drawings, etc.) have their individual points included in the trajectories. So if you track and angle drawing, its three points will show up in the linear kinematics window as three distinct trajectories that you can treat as any other trajectory.

Angular kinematics

A new kinematics analysis window has been introduced for angular kinematics. It is available under the menu Tools > Angular kinematics.
This window will let you visualize angular kinematics values like angular velocity or tangential velocity for angles that were tracked in the video.

http://www.kinovea.org/screencaps/0.8.26/0826-angularkinematics.png

Trackable drawings that have an angle, including custom tools, will show up in the list of sources and can be checked/unchecked.
The time options "relative" and "normalized" are also available.

Angle-angle diagrams

A new analysis window for angle-angle diagrams has also been introduced at Tools > Angle-angle diagrams. These are diagrams that directly map the angular value of two angles against each other.
This is useful to get insights into the dynamics of a specific motion. A typical example is to plot the knee angle against the ankle angle over a few cycles of running or cycling. The overall shape of the cyclic curve can be compared to the literature or between athletes or sessions.

http://www.kinovea.org/screencaps/0.8.26/0826-angleangle.jpg

The diagram is defined during the overlapping period of time of the two angles considered.
The angle-angle diagram will also work for custom tools that contain angles. This is possibly the most practical way to use this feature, for example with the bike fit tool or a tool dedicated to the angles you want to review.

In addition to the raw angle value, it is also possible to map the angular velocities or tangential velocities of two joint angles against each other.

General tracking

If you need to track the same joint angle at distinct times in the video, create several angle tools and track them independently. Each tracked point has an underlying timeline of positions that is not exposed to manipulation. Filling this timeline with discontinuous sequences will cause unexpected behavior.

It is now possible to completely bypass the data filtering by changing the global option under Preferences > Drawings > General > Enable coordinates filtering. Note that this filtering is to remove the high frequency noise created by the digitization process, it should be left enabled unless you intend to run your own filtering algorithm on the data.

4. Capture

Recording modes

In order to restore the ability to record delayed videos, a new recording mode option is available in the global preferences under Capture > Recording.

http://www.kinovea.org/screencaps/0.8.26/0826-recordingmode.png

The Camera recording mode is the default and will record the video stream straight from the camera to disk, compressing it on the fly if necessary. This is the best performance path. For some combinations of framerate and image size, it is the only usable option.

The Display recording mode will let the video go through the buffering system for the delayed live feature and the composition system for mosaicing (if active), and it is the final image that will be recorded to disk.

Here is a simplified diagram of the capture pipeline and where each recording mode operates.

http://www.kinovea.org/screencaps/0.8.26/0826-diagramcapturemode2.png

As an example, let's say we have a 10 second delay active and we record for 20 seconds. Let's define the press of the record button as time "0".
- In camera mode, the video will contain the action from time 0 to 20.
- In Display mode, the video will contain the action from time -10 to +10.

Camera modules

An entirely new camera module was written to support IDS cameras.
http://www.kinovea.org/screencaps/0.8.26/0826-idscam.jpg

The Basler camera module was improved and updated to support Pylon 5 API.

Memory buffers

The maximum allocated memory for the capture module is now based on whether Kinovea is currently running on 32-bit or 64-bit Windows. This should allow for much longer delay when memory permits.
The option to increase the memory allocated for delay buffer can be changed under Preferences > Capture > Memory.

http://www.kinovea.org/screencaps/0.8.26/0826-capturememory.png


5. Feedback

Feel free to use this post for feedback, bug reports, usability issues, feature suggestions, etc.

This should be fixed in the next version. Added the trajectory label as a comment line above the corresponding data.

I'll look into this.

Moving forward the preferred way to export trajectory data is through the linear kinematics window and its CSV export. It's under the trajectory objects context menu in 0.8.25, but will be under "Tools" in the next version and will allow reviewing and exporting the kinematic data of several trajectories at the same time.

Yes the timing information by default depends on the framerate of the video, so time intervals will be wrong. If you know it's wrong and you know the correct framerate, you can fix it in menu Video > Configure video timing > in the bottom pane you will see what Kinovea reads from the file. In your case you can change the value to 29.97 and apply, and the playback speed as well as all time dependent measurements should be correct.

If you can see two balls in just one frame, it could very well suggest that the original footage was indeed interlaced and that it got deinterlaced. When an object moves a lot between the two half-frames the deinterlacing algorithms tend to "reconstruct" the object twice.

To improve the automated tracking you can change the size of the search and object box used by the trajectory tool. For some objects it's best to reduce the "object" window to avoid tracking background. You can also adjust the position of the object manually to get the most control. This will work better with the camera higher above the ground. Then if you go to the trajectory data analysis you can find all the measurements and export them quickly to the clipboard or CSV file. This uses a smoothing pass on the data to minimize the noise introduced by the digitization process. The exact procedure is described in the "About" tab of the data analysis dialog.

Note that you can also correct the distortion of the GoPro directly in Kinovea, it will not undistort the images but it will distort the coordinate system to match the lens. The calibration procedure is not very well documented at the moment though. But in theory it could be more accurate than using the stock de-fishing algorithm of GoPro studio which will use standard values for all devices, whereas here you would calibrate exactly for your camera lens. (Depending on how the sensor is glued on the board the optical axis may not be exactly aligned with the center of the image).

This is only relevant if you are making spatial measurement on the images though, if you just do time measurements because you already know the distance between markers visible on the images I don't think you need to correct the distortion at all.

Hi ysag, could you try with 0.8.25 first to see if the problem persist?

Also there is a nasty bug in 0.8.15 when trying to export the video on top of the file currently opened. Avoid doing this as it could corrupt the file.

Thanks for the file. I see that the action is indeed sped up, but I also get the same in VLC and SMPlayer. Kinovea reads the file as 4,989s long, 299 frames, 59.93982fps. VLC also says 59.93982fps. Using VLC 2.26.

Are you sure it's not the pre-processing that introduce this effect?

Did you shoot in 1080p or 1080i in the GoPro? I've read there are issues with the 1080i mode not really being interlaced. Maybe the defisher or converter thinks it's interlaced when it's actually not, and it tries to deinterlace it. This could merge pairs of frames and end up twice as fast as expected.