1,201

(6 replies, posted in Bug reports)

I tried various combinations but I couldn't reproduce the issue. Whatever I do, the mirrored video in the dual file exported is fine. Is there any specifc context I am missing ?

One bug I stumbled upon, when saving a single video with the mirror option, it's not mirrored.

1,202

(6 replies, posted in Bug reports)

www.kinovea.org/bugs/

Thanks for the samples.
I confirm the videos will work in next version.

1,204

(6 replies, posted in Bug reports)

Thanks for the report.
Can one of you guys add it to the bug tracker ?
Thanks.

1,205

(5 replies, posted in Bug reports)

Re: Drawing loosing sync with the video. There is maybe a remaining issue with a specific input format / framerate and MKV as output format. Please detail your case.

Re: other experiments.
- It is not normal that key images with no drawing don't show up in the slide show export.
- The persistence (ghosting) is irrelevant for slideshow saving.
- There shouldn't be any limit to the number of key images to be exported in the slide show. Admittedly it wasn't tested thoroughly, so maybe there is a bug somehow.

To make further experiments and help with the diagnosis:
- Deactivate the ghosting if you want (Options > Preferences > Drawings > Persistence > uncheck "Enable persistence").
- Identify the key images by drawing big numbers on them with the pencil tool. Then check what goes out in the exported video.

Thanks

1,206

(1 replies, posted in Bug reports)

Did you use the "Save video with a pause on each key image" saving method ?

1,207

(1 replies, posted in Bug reports)

Hi,
The problem is in Kinovea, not with the file formats. It is a known problem but quite tricky.
Sorry for the loss of time information in your analysis session.

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)