1 Topic by joan

  • joan
  • joan
  • Admin
  • Offline

This is Kinovea 0.8.27.
This version introduces image rotation and a host of usability improvements in drawings and measurements.


1. Player

Image rotation

The player now supports rotation of the input video by 90°, 180° or 270°. Videos that have been filmed in portrait mode on a handheld device should be automatically detected from their metadata. You can also force the rotation from the menu.

http://www.kinovea.org/screencaps/0.8.27/0827-imagerotation.png


2. Annotations

Copying and pasting objects

It is now possible to cut, copy and paste drawings around.

http://www.kinovea.org/screencaps/0.8.27/0827-clipboard.png

Once a drawing is copied, you may paste it in the same video or in another video in Kinovea, but not outside Kinovea. It will not use or interfere with the Windows clipboard.

The pasted drawing will retain the shape and style of the original and will be given a new name.

You can also paste images from the Windows clipboard directly as Image objects.

Labeling things

The text tool was somewhat lacking in usability. It is now created directly as a ready-to-use object with its name as the value and the editing mode has a similar styling than the normal rendering mode.

All text objects have a new secret arrow that you can show and adjust to create a pointing label.

http://www.kinovea.org/screencaps/0.8.27/0827-texttool.gif

As an alternative, the measurement objects like lines, markers, trajectories and circles now have the option to show their names in the mini label attached to them.

http://www.kinovea.org/screencaps/0.8.27/0827-linename.png

Styling

The style of arrows and squiggly lines was a bit broken and has been improved.

http://www.kinovea.org/screencaps/0.8.27/0827-arrows.png

It is now possible to select an existing drawing and set its style as the default style for all drawings of this type. This makes it much easier to quickly change the default style of a certain tool.

http://www.kinovea.org/screencaps/0.8.27/0827-setstyleasdefault.gif

Rectangle tool

Simple but always useful to draw attention to something, the rectangle tool is a newcomer to this version.

http://www.kinovea.org/screencaps/0.8.27/0827-rectangle.png

Custom tools debugging

Designing custom tools is not an easy task so a special rendering mode was added to show the various components of the custom tool as it is being worked on.
This is a global option and can be changed under menu Options > Preferences > Drawings > General > Custom tools debug mode.

http://www.kinovea.org/screencaps/0.8.27/0827-customtooldebug.png

Middle mouse moving

It is now possible to use the middle mouse button for panning around when zoomed or moving objects while a tool is still active. Previously you would have had to deselect the tool in order to pan or adjust an existing drawing.

3. Measurements

Precision cursors

The precision cursors have been improved and moving an existing drawing now uses the precision cursor instead of the opaque "closed hand" cursor as in previous versions.

Circle tool

The circle tool has graduated from being a descriptive object to being a measurement object. You can now display the coordinates of the circle center, its radius, diameter or circumference, all based on the current calibration.

http://www.kinovea.org/screencaps/0.8.27/0827-circle.png

The circle tool is "perspective aware" so it will display correctly (as a rotated ellipse of the correct size) when the perspective grid calibration method is used.

http://www.kinovea.org/screencaps/0.8.27/0827-perspectivecircle.gif

Archery tool redesign

The archery tool was redesigned to leverage recent changes in the custom tools framework.

http://www.kinovea.org/screencaps/0.8.27/0827-archery.png

4. Capture

Delay modes

The Mosaic compositing system introduced in version 0.8.25 was simplified and renamed "Delay mode". It now only supports the most important use cases of live delay, live slow motion and the quadrants view. The slow motion mode is now showing a countdown to the reset of the live stream for when the delay buffer will need to catch up to real time.

http://www.kinovea.org/screencaps/0.8.27/0827-delaymodes.png

Mirror

Mirroring the image is now supported in the capture screen via the menu Image > Mirror. Note that this is implemented at the display level only. It will not have any impact on frames recorded using the "Camera" mode of recording which takes frames directly from the camera and save them as-is (see Options > Preferences > Capture > Recording).

5. Feedback

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

2 Reply by getpa (edited by getpa 2018-10-12 14:16:40)

  • getpa
  • Member
  • Offline

Dear joan,

...amazing!

THX a lot, will use as of now & post any bugs detected.
Best regards,

detected issue nr 1: win32 Version has no support for the PSeye. (V26 win32 has no issues there)

- the repairman will never have seen a model quite like yours before -

3 Reply by Gabrivolea

  • Gabrivolea
  • Member
  • Offline

I have used kinovea for years and for me is a fantastic software.
In this new version I have a problem that I did not have in the previous one. After calibrating the space and digitize the trajectory of a mobile and give it to show measure does not appear the speed in m / s, but it keeps appearing in pixels / second, as if it had not calibrated the space. The other measures appear correctly. I do not know if I'm doing something wrong.

4 Reply by joan

  • joan
  • joan
  • Admin
  • Offline

So if you put a line somewhere it's in centimeters according to calibration but the speed measurement on the trajectory is in pixels/s?
Is it on a brand new file or re-opening a file that you already calibrated in the previous version?
Are you calibrating using a line or a grid?
What if you go to menu Tools > Linear kinematics, is the speed in px/s there too?

5 Reply by joan

  • joan
  • joan
  • Admin
  • Offline
getpa wrote:

detected issue nr 1: win32 Version has no support for the PSeye. (V26 win32 has no issues there)

I can't reproduce this at the moment. I can still see and open the PSEye camera on the win32 version (definitely not working on the x64 version as the driver is win32 only).

Do you not see it at all or do you see the "No camera found" placeholder image from the driver?
Can you check the log and search for "PS3Eye" to see if there is any error related to opening but not being able to connect to the camera?

6 Reply by getpa

  • getpa
  • Member
  • Offline
joan wrote:
getpa wrote:

detected issue nr 1: win32 Version has no support for the PSeye. (V26 win32 has no issues there)

I can't reproduce this at the moment. I can still see and open the PSEye camera on the win32 version (definitely not working on the x64 version as the driver is win32 only).

Do you not see it at all or do you see the "No camera found" placeholder image from the driver?
Can you check the log and search for "PS3Eye" to see if there is any error related to opening but not being able to connect to the camera?


Dear joan,
the PS3Eye was not displayed in the cam list at all.
I did a clean new re-install of V0.8.27, this time the win32 version after x64 version installation.
Everything works just fine now - no issue with PS3Eye observed anymore.
Have two of them running in parallel at 75fps without frame drops.

THX for your reply & best regards,

- the repairman will never have seen a model quite like yours before -

7 Reply by stididup

  • stididup
  • Member
  • Offline

Thanks Joan for the new release.
I will now use the 0.8.27 version for research and teaching purposes.
The image rotation function will be very appreciated by my students. I will use it to maximize the size of the video on my screen (they will use it to keep the video "standing right"). The copy paste will be also very useful I think. And thanks also for the improvement of the arrows rendering.
I never asked for the change of the “closed hands” cursor but it’s really really such an improvement! The circle tool will be also great sometimes (not as far as Monday we had to measure (calibrate in fact) the diameter of a disk).
I will also try if this new version as still a bug (since 0.8.25, sorry but I never mentioned that) during the creation of the distortion correction file. I will go further in a later post.
Really really great!

8 Reply by joan

  • joan
  • joan
  • Admin
  • Offline

Cool, thanks.

Yeah, I definitely want to make the distortion correction more robust. And also provide a number of presets for popular cameras, as a middle ground between not being able to measure anything and doing the manual calibration yourself.

9 Reply by inorkuo (edited by inorkuo 2018-11-15 22:11:33)

  • inorkuo
  • Member
  • Offline

hi joan,

i am currently using an audio trigger software with the live delay feature in the stable 0.8.15 version with the ov2710 cameras to capture and analyze golf swings. i have been testing an ov4689 camera, which can do 640x360@330fps and 1280x720@100fps. with the stable version, the maximum delay i can get is just over 1 second which isn't long enough. i am now trying it with 0.8.27 which allows me to allocate more memory to achieve the necessary live delay. however, in my testing i have discovered that when i set the recording mode to "Display: records what is currently displayed on screen" the recording has many missing frames. a recording which should be at 330fps comes out to around 50fps. when recorded with the same camera with recoding mode set to "Camera: records the video stream coming straight from the camera" I do not have this issue and count around 330fps. is this a bug or is there a setting that i can change to correct this behavior?

10 Reply by joan

  • joan
  • joan
  • Admin
  • Offline

Hi,

It is the expected behavior for now. It's a trade off. When recording what is displayed on screen the images go through the delay buffer, painting pipeline (drawings and compositing) and generally undergo more conversions.

The two main use cases considered are live feedback and high speed capture. In order to support both as best as possible they are treated separately and optimized differently. So unfortunately doing live feedback on a high speed stream is going to suffer in one way or another.

The framerate you see is most probably the "display" framerate which is set on Preferences > Capture > General tab (25 fps by default). This is what gets saved when recording is set to display (a.k.a what you see is what you get). The other frames aren't pushed to the delay buffer in the first place.

You could try to increase it and see how high you can go. I don't remember if it's capped to the monitor refresh rate on the top of my head. I'm curious to see if you can get it to 300fps and where the bottleneck is, please report your results!

I imagine what you really would like is that when the audio from the golf club triggers the recording it still includes the few prior seconds of the swing, at the camera max framerate.

11 Reply by inorkuo

  • inorkuo
  • Member
  • Offline

hi joan,

that is exactly what i do with 0.8.15 which does not have this issue. i set the live delay to 3 seconds and trigger the recording by the sound of the club hitting the golf ball and kinovea captures the entire golf swing. i already had the display framerate at 330 fps so that does not seem to help.

i made a youtube video tutorial on how i am using kinovea to automatically capture my golf swing. most of it is about how to set everything up but if you skip to 9:23 that is when i hit a ball and demonstrate how it works.

https://youtu.be/IZZcpEykmWU

the live delay feature in 0.8.15 does not have this tradeoff and works great. the problem is with larger resolutions and higher frame rate cameras, there is not enough memory to make the delay long enough. are there any plans to make the live delay work like it does in the stable version while increasing the memory availability?

12 Reply by aheavrin

  • aheavrin
  • Member
  • Offline

Hello - relatively new to Kinovea. Using 8.27 for college biomechanics. Does this version support exporting tracked angles, distances, etc. (auto-tracked) to Excel? I have tried it several times and the exported data is only for the measures at 'time zero.' I have read previous posts on previous versions and see this is an issue. Forgive the rudimentary question. Any feedback appreciated.

13 Reply by Faultyclubs (edited by Faultyclubs 2019-01-29 06:53:38)

  • Faultyclubs
  • Member
  • Offline
joan wrote:

I imagine what you really would like is that when the audio from the golf club triggers the recording it still includes the few prior seconds of the swing, at the camera max framerate.

Yes, is this possible please?  The way it was in 8.15 worked for golf but the current versions (including v8.27) simply do not.

(Note: we need a user variable number of "few" prior seconds since it depends on the speed of ones swing).

The main problem with v8.15 (besides being a dead-end) is the capture pipeline is extremely inefficient.  I can capture 640x480 at 120 fps on my i5 computer but cannot handle 1280x720 at 120 fps.   v8.27 is dramatically more efficient at high speed camera capture but the architecture is broken for golf.

Perhaps an option to turn on a circular "pre-recording" buffer is all that's needed in the high speed camera pipeline?

Anyway, as users we're blissfully unaware of how hard it might be to fix this problem but hopefully something can be done!  smile

14 Reply by Waheeden

  • Waheeden
  • Member
  • Offline
joan wrote:

Hi,

It is the expected behavior for now. It's a trade off. When recording what is displayed on screen the images go through the delay buffer, painting pipeline (drawings and compositing) and generally undergo more conversions.

The two main use cases considered are live feedback and high speed capture. In order to support both as best as possible they are treated separately and optimized differently. So unfortunately doing live feedback on a high speed stream is going to suffer in one way or another.

The framerate you see is most probably the "display" framerate which is set on Preferences > Capture > General tab (25 fps by default). This is what gets saved when recording is set to display (a.k.a what you see is what you get). The other frames aren't pushed to the delay buffer in the first place.

You could try to increase it and see how high you can go. I don't remember if it's capped to the monitor refresh rate on the top of my head. I'm curious to see if you can get it to 300fps and where the bottleneck is, please report your results!

I imagine what you really would like is that when the audio from the golf club triggers the recording it still includes the few prior seconds of the swing, at the camera max framerate.

Hi Joan,
Thanks for Kinovea - it is an amazing tool!  I've been using Kinovea with Inokuo's AutoIt golf swing recording script.  Instead of the standard two OV2710 cameras, I am using two OV4689 cameras recording 100fps at 1280x720 on a 4 second delay. I updated the camera firmware with a fixed framerate version so there are no drops.  With the "Display Framerate" set to 100fps, I get a steady maximum of 32fps in this "Two Capture Screen" configuration.

I rewrote Inokuo's script to take advantage of the "Allow Multiple Instances of Kinovea" option.  Two Kinovea windows are both recording 1 camera feed each.  With this configuration, I get double the previous framerate, which turns out to be 64fps.  This is pretty close to the 60Hz screen refresh rate you mentioned as the possible upper limit for delayed recording.  I have two questions:

1) If I used a 120Hz display, would you expect Kinovea to display the full 100fps that the camera is putting out?

2) Perhaps 1 out of 10 swings while running the 2 instance configuration, Kinovea gives me an "Unhandled Exception - The process cannot access the file 'x.xml' because it is being used by another process".  My guess is that the two Kinovea instances are trying to access the same file at the same time, but it could also be a timing problem in the AutoIt script.  I added the log file in the bug tracker (Issue #421).  Do you know what could be causing this issue?

Thanks!

15 Reply by joan

  • joan
  • joan
  • Admin
  • Offline

Thanks.

1.
I checked and there is no artificial capping at the display refresh rate, at least not in the current codebase, so it shouldn't make a difference to use a 120Hz display I think. I'll double check in an actual test that it works as intended.

It's possible the slowing down is coming from other parts, especially the fact that it has to decompress the image for display and then recompress for recording. Very interesting that it works twice as fast when using two instances. Maybe a threading issue, can you check in task manager, (on performance tab, right click to show logical processors), when you have 2 cameras in one instance vs one camera in each instance if the CPU usage is confined to one core vs spread out.

2.
Regarding the unhandled exception, I don't see the error in the log. There should be other files in the log folder dedicated to the unhandled exceptions, can you attach one of these to the bug? What is "x.xml"?

If you use the .zip version of the install you could duplicate the entire folder and have the two instances work on their own directories, to make sure they are not trying to write in the log at the same time or whatever.