Hello,
This is an important known issue that is being worked on.
The problem boils down to not knowing the framerate of the video we are saving, because we don't receive frames at the same frequency when simply viewing compared to recording.
The discrepancy depends on the CPU load…

Added to the idea backlog in the Saving category, as "Option to take slow motion into account when using the time freeze export".

Discussion follows in this thread.

Hi,
The issue should be fixed in the next version, 0.8.16.
If possible you can send me a small sample file so I can verify that this specific file will indeed be supported.
(joan at kinovea dot org - less than 3MB please)

Hi,
I totally agree that the wording is confusing. I have struggled since the begining to find something appropriate.

Here is a proposition to simplify the save dialog:
1 - Remove the first option of saving the video "naked". (If you want to save the video without any drawings on, just don't add drawings in the first place).
2 - Change the wording of the next options to:

A - Save video while keeping tools modifiable
B - Save video with tools applied on images

Let me know if these seem more straightforward.
The wording issue came from the fact that the set of things that can be painted on the video is heterogenous. There are the drawings like arrows or labels which are attached to a key image, there are grids or magnifier that are not attached to a key image, there are tracks and chrono, etc. The internal name is "Metadata" but that's not telling much to the user.

The caveat with the new wording is that it does not necessarily convey the fact that option A will save the key image comments (the block of formatted text). Also, you still have to "guess" that when saved with option A, the drawings will not show up in regular players or in YouTube, Vimeo, etc.
But overall I think it's clearer.

Technically, option A use a special stream to save the meta data. A multimedia file can contain for example a video stream, an audio stream, several subtitle streams, all packed in a single container. This technique is used to embed the metadata inside a single file. The format is specific to Kinovea, so the extra data is only visible when reopening the file in Kinovea, not in other multimedia players. The option of saving the data in a external file is also provided as the last option of the same dialog.

Let me know what you think of the new wording.

Hi,
It is an extension of the Chronophotography type of effect that is scheduled for integration ASAP (but time is severely lacking these days).
(idea backlog ref: "Special effects - Chronophotography (kinogram merged into a common reconstructed background)")

The camera doesn't necessarily need to be fixed, if we can rebuild the background.

The steps would be
1. Find how images relate to each other spatially.
2. Rebuild the empty background by aligning and combining the images (if the athlete is moving relatively to the background, any given background position will be clear most of the video)
3. Compare each position with the rebuilt empty background to differenciate background pixels from athlete pixels.
4. Create an image or video with the total background and a few selected positions pasted on it.

Currently I have been focusing on steps 1 and 2, because I don't want this feature to be limited to fixed camera. You can see some results here.

jbrond wrote:

The only thing I am missing in Kinovea 0.8.15 is the option to adjust the exposure. Exposure is important if you want to avoid motion blur in the images. Normally you use the "Video source" (DirectShow programming stuff) to do that. But I dont see the properties for enabling that in kinovea?

Thanks for the feedback on this camera.
Try to use the "Properties" button to access the driver's properties page with the extra settings.

jon wrote:

- ability to drag and select multiple files in main File Explorer page

Can you elaborate, I'm not sure I understand what you mean with this. Double selection to directly open in dual player mode ?

jon wrote:

- F5 to refresh File Explorer page after deleting/renaming videos in windows.

Maybe this could be automated somehow. For the observational reference menu, we register ourselves to Windows to be notified when there is a change in the folder, so we trigger a rebuild of the menu to reflect the new list of files.
Maybe we could do something similar by registering for changes on the current directory and rebuild the file list upon notification.

(Maybe also consolidate the list in the first post to keep track of those intertwined with discussions)

1,239

(20 replies, posted in General)

Chas Tennis wrote:

To double check, does Kinovea use the color information as well as the brightness for tracking?

Sorry, it wasn't clear at all from the first post. Yes, the color information is fully used during the matching.
Black/White will always be better for the matching itself (color and contrast) but color difference alone should help.
Aside from the internal pattern of the marker itself, it could help when using several markers of the same material/shape/brightness. It should help matching the right marker with the right trajectory.

1,240

(1 replies, posted in Bug reports)

Added bug 249 to track this issue.

1,241

(2 replies, posted in Bug reports)

You are not missing anything, it is a known bug sad
When recording starts, we get frames less frequently than normal. The final file stores the original frequency information, hence the mismatch.
Haven't found any solution yet.

[late edit: this issue should be fixed in 0.8.16]

1,242

(5 replies, posted in Bug reports)

billrp wrote:

But the .mkv files will need to be converted to .mp4 to be used elsewhere, such as Youtube.

Normally Youtube supports the MKV format without problems. Are there issues ?
Multimedia players like VLC or MPlayer will also support Matroska (MKV) natively. For playback in Windows Media Player or Media Player Classic, you may need to install a third party demuxer.

To export the video with the drawings applied on images (whichever format), you use the 3rd option. (Saving videos).

billrp wrote:

And unfortunately if the video screen is zoomed, that is not saved in the .mkv file.

Yes, that is a problem. I'll add it to the bug tracker.

Yes, I also thought about that… but I think the most popular ideas will still bubble up.

I would like to keep it super simple, and many applications do work with these "like" systems, even if you can vote for everything (digg, wikio, planets). You will not vote ALL because you know it will devalue the ones that you like more than others.

Even with only a few votes casted it is already interesting. I think it will help a lot.

1,244

(5 replies, posted in Bug reports)

It is really intended to contain the analysis data (comments, drawings), not anything else.

There is no concept of projects in the sense that an analysis file would be attached to a video and this link saved in yet another file. If the analysis file (.kva) has the same name as a video file in the same folder it will be loaded when you open the video. This is the way to emulate "projects": simply save the .kva with a similar name as the video (default option).

You can also save the analysis data embedded inside the video while keeping it editable. This arguably removes the need for "projects".
This design is to keep things flexible: you can load any analysis file into any video (File > Load key images data).

1,245

(5 replies, posted in Bug reports)

Hi,
The .kva files contain the tools and drawings you have added to the video. It is the analysis data.
The dialog under "File > Save" will only have the option to save to .kva when there is something to save. (When you have added some key images and some drawings).