Search options (Page 63 of 133)

At the moment this is not possible. You would have to decimate the data points in an external software.

I have started to work on improving tracking and measurement for the next version, and one area that I want to improve upon is the way the resulting data is presented and how it can be exported. Interpolation and decimation would be good candidates features for this.

In the next version plots of the measured data can be created directly in Kinovea, the problematic issue is mostly to design a good user interface to present the plot(s) and allow for flexible ways to export raw or filtered data.

Hi,
Unfortunately I think what you want to do is not currently possible.

At the moment the command line interface can only open Kinovea in playback mode, not capture or mixed mode. It is definitely a weak point to be addressed.

Opening YouTube streams or anything directly from Internet is not possible. If they cache the videos as files on a shared drive on the local network and the machine running Kinovea can access it then it should pose no problem (although I haven't much tested playing videos from network locations).

Hi, thanks for the feedback!

1. Windows XP : note that the new version needs .NET 3.5. I think I forgot to mention it. Maybe that's the problem.

2. Magnifier: If I understand the need, it would mean to turn the magnifier into a regular drawing tool, that can have a persistence. I like this idea because currently it is a special tool and that means specific code in a few places which is not ideal.

3. Changing text: Interesting idea. Being able to keep 100% opacity between two key images would be interesting for all drawings actually, not just text, but at the moment I don't know how to have a simple user interface for this. The persistence dialog is already not very intuitive, I don't want to add complexity to it.

Having the text tool able to hold different texts depending on the time could be done too. But similarly, it must not add complexity to the existing text tool (basic tools must stay basic). So maybe a menu like "Multitext" that needs to be activated. When activated the persistence is switched to "always visible" and there are new menus to create and delete sections inside the text tool timeline. When you modify the text value, only the value of the section is impacted. Some sort of visualisation of the sections would be more user friendly.

After some thinking having persistence opaque between two key points would probably be the best option but both needs careful user interface design…

Hi,
Unfortunately the tracking of general tools cannot be exported to file yet. It's only for analysis on the fly for now. Only the trajectory tool data is saved to file.
This will be worked on in one of the next two versions.

Hi,
It should work… if you have video A and B, you have mirrored B and you have superposition active, Image B should be mirrored when seen on top of A. A will not be mirrored. Forcing A to be mirrored is not desirable in my opinion because a very common scenario is to compare two videos filmed from a different side (or two high jumpers with different takeoff foot for instance), and mirroring only one video so they are comparable. You can always explicitly mirror both videos if need be.

However I see there are bugs when moving the image around…

Yes, I had thought of this but the mere fact of saving to file is adding burden to the CPU from the extra copy of images and access to disk, so an average computed before recording starts would still overestimate the true framerate of the capture…

A more ambitious solution would be to record in a dedicated format with timestamps associated with each image and honoring the timestamps at playback time. It would break compatibility with other softwares though.

Hi,
The "playback is too fast" problem arise when we select a framerate but we do not receive the frames at the advertised rate.

Due to something else, PC being busy, camera giving wrong info, etc. we receive images at a lower rate. We still save the advertised framerate in the file metadata for a lack of a better value. So when played back, it plays at the advertised framerate even though frames were captured at slower rate. Hence the speeding up of the action.

If you use 0.8.21, the actual framerate at which frames are received is displayed in the top bar above the viewport. You will probably see a lot of variability when choosing higher framerates, and more stability for lower framerates.

At the moment I do not know how to mitigate this problem. Saving the actual framerate seen when the record button is hit is not really an option since it's very variable. Maybe keeping the average of the framerate of the sequence and using this, but the issue is that the metadata is written before the capture starts…