1,486

(1 replies, posted in General)

Currently it is either maxed at 60 frames or visible for the whole video.
However that max value was set arbitrarily and could be changed if it makes more sense.
The max could be 180 for example. (6 seconds at 30fps)

Some have expressed interest in having the fading only "after" the event.
Some would like labels that can stay 100% visible for a given period of time.
It's primarily an issue of not crowding the interface for everybody with options that only a handful use. So if anyone have ideas about how to integrate these cleanly in the interface (new control for example), they are welcome smile

CAR_UARD wrote:

Once the video is calibrated, speed measurement is exactly the same rather the video is at 25 fps or 300 fps

I'm not reproducing this issue… If I have a tracking path configured to display speed, and a calibration line somewhere, each time I change the framerate through "High-speed camera" menu, the speed displayed on the track reflects the change. Is it the right context ?

You do need to have a calibration line somewhere, otherwise the speed is in pixels/frame and that doesn't change with the framerate.

TeamTermin wrote:

Just wondering if there are any updates on the capture feature?

I more or less went into "vacation mode" regarding Kinovea for july and august smile
I'll try to deliver a new experimental version in the next few weeks. The priority will be fixing the issues with capture screen and the Windows 7 UI glitches.

daww wrote:

had to highlight the numbers already in, then right click to hit delete then I could write down my file name.

Well, there is one thing that could explain that. When you have the text highlighted, if the mouse goes away and enter some other part of the user interface like the file explorer or the main screen, then the focus is transferred to this area and lost on the textbox. You have to keep the cursor within the bottom area of the interface. This was done to enable other things like keyboard navigation and mousescrolling depending on the area where the mouse is.

daww wrote:

After capturing a video in a specified folder the explorer doesn't show it

Hmm, I don't think it is the responsibility of the recording program to refresh the file explorer. Probably just hit F5 to refresh it and you'll see the file appear.

daww wrote:

Would it be possible for Kinovea to support a remote, at least for recording a video away from the keyboard.?

One prerequitise to this is that I need a remote to test. By coincidence, a friend gave me a remote he's not using today. I haven't tried and I don't know if I can install it on my PC though.
Anyway, I'll see how this stuff works and see if something can be done.

1,489

(2 replies, posted in Ideas and feature requests)

Hi,
That is not currently possible.
However you can make a single drawing visible for the whole video and not the others. You would do that by right-clicking the drawing, go into "Persistence" menu, uncheck "Use default value" and check "Always visible".

1,490

(2 replies, posted in Ideas and feature requests)

Hi,
Basically two types of shapes are being considered.
1. basic geometric drawings (rectangles and ellipses). This is not implemented yet.
2. Complex shapes that the user can modify or even create himself in an SVG editor. This is known as "Observational References" and can be as complex as you want. They were introduced in experimental version 0.8.8 (maybe not fully polished), there is a screenshot in this thread.

1,491

(4 replies, posted in Bug reports)

Probably some people will only want the actual values as it is now, which means a configuration window needs to be added somewhere. Also, you may want to set the "granularity" of the target timescale (hundredth, thousandth…)

The continuous timeline has to be rebuilt from code. The internal time representation doesn't align with hundredth of seconds or anything. To build it, it will be possible to loop over all the positions of the target representation and figure out how far we are of the two adjacent actual positions.
Interpolating the spatial position to subpixel will be straightforward, but some people may prefer integer values… (Also I think we can get subpixel accuracy from the automatic tracking.) So another option or checkbox somewhere.

All in all, to do things properly, a new page in the preferences is probably needed. (and it could host the "coordinate system origin" button).

Or… Or this could be the standard behavior and no options to change it need to be added. Currently the export is dependent on the framerate because it's the fundamental unit of time of the video…
Ah…

1,492

(4 replies, posted in Bug reports)

Hi,
You may switch to frame numbers for the time representation, that should take care of the problem. However, if the frame are really not evenly spaced in time, you will loose some accuracy.
In any case, when working with the spreadsheet exports, you should generally use numeric time representation like frame numbers or ten thousanth of an hour, etc. ("Total milliseconds" will be added in the future).

edit:
Looking better at your second example, yes, it would be possible to interpolate the missing bits, and even get subpixel positions. That deserves some more thinking smile

1,493

(4 replies, posted in Bug reports)

Hi,
First of all, are you using 0.8.7 or one of the more recent experimental version ? Can you try with the 0.8.9 ? (The decoding library was updated in 0.8.8)

The problem has been reported previously and there is a bug for it. (m142).
If I remember correctly, the duration information in VOB files is not reliable and the current time info can start at some random value and wrap around in the middle of the video.
I also found an issue related to FFMpeg but for the other way around, small files that were reported as 26 Hour long.

Ok, great.
I have started to fix the many interface issues related to this. Like options dialog, missing titles on drawing configuration windows, progress bar and others, the Working Zone selection bar, size of some buttons with images, splash screen, etc.
I'll try to work on this during september and fix some issues of the capture screen, and make a release for October 1st if time permits.

vincent wrote:

je fonctionne avec la version libre de kinovéa,

Il n'y a pas de version non-libre wink

vincent wrote:

Quand j'enregistre une vidéo après avoir sélectionné le passage qui m'intéresse... je n'arrive pas à relire le fichier enregistré car ce dernier est sous le format Mastroka (*.mkv)

Les fichiers MKV peuvent être relus dans VLC, MPlayer et Media Player Classic nativement, pour Windows Media Player, il faut installer un « filtre » par exemple FFDShow ou Haali Media Spliter (lien de téléchargement complètement à droite).

vincent wrote:

cependant je ne peux pas changer le format d'enregistrement. Quelles solutions pouvez vous me proposer?

Pour changer de format au moment de l'enregistrement, déroulez la liste de sélection du format. AVI et MP4 sont disponible. Cependant, cette option n'est pas dispo quand on choisi le mode « Combiner la vidéo et les données des images clés ».
Voir la page du manuel: Enregistrer des vidéos.

I think I have reproduced the issue. I went to the Windows' Control Panel > Display, and changed from "small - 100%" to "medium - 125%".

Then, when relaunching Kinovea… Wow. I get all kind of glitches in the interface sad
Including missing buttons on save and options dialogs. I posted a screenshot here.

Can you guys confirm this ? (That you have the option on medium or large).

1,497

(24 replies, posted in General)

Oh, I see. You want to compare the body positions without the differences in motion dynamics being an issue.
Currently we can only analyze body organisation simultaneously with gesture speed, and it would be nice to decorrelate the two, to normalize speed.

I'm a bit scared about multiple point sync due to the complexity it may add to the user interface (adds the issue of removing sync points) and to handling dynamic sync and frame by frame sync.
I'd hope to find a simpler way to achieve this gesture speed normalization if possible…
(Could be done by trial and error manually by playing with the slow motion of one of the video, but not a very friendly solution).

1,498

(19 replies, posted in General)

Hi,
Can you walk me through this again, I can't wrap my mind around the issue. This is what I do:
- I close Kinovea.
- I Go into "Program Files > Kinovea > guides".
- right click on protractor.svg > select Copy.
- then Paste in the folder : a dialog box pops up "Destination folder access denied", You'll need to provide administrator permission…" I click continue.
- Other dialog box "Do you want to allow the following program…" > I click yes.
- the new file is created "protractor - Copy.svg". (108KB).
- I reopen Kinovea, launch a small video.
- Then I can see the "protractor - Copy" entry in the menu.

As far as I understand, the only way for the file not to be displayed in the menu would be that it's actually not really in the Program files folder, eventhough the file explorer makes us think so.
I don't have a Vista machine so this was done under 7.

Hi,
I'll try to work on this over the week-end.
So far I can't reproduce the issue on my Win7 virtual machine. In the meantime, if someone could get a screenshot of the faulty dialog box, that may help.

The height of the dialog is computed dynamically to make room for the slow motion option. And the buttons are positionned relatively to the bottom of the dialog. So if for some reason something is taking more vertical space than during design time, that could lead to the buttons being behind the groupbox. Having a screenshot would help verify this.
You can attach the screenshot to bug m216, (look for the "Upload File" section) or send it by mail, thanks !

1,500

(19 replies, posted in General)

The only thing I can think of right now is the file virtualization thing. When trying to write to a critical location (like "Program Files") the system detects you are a non-privileged user and actually pushes your changes to a special location under your own user files directory. It may does that transparently for you from the Windows File Explorer, but the files wouldn't be added to the right folder from Kinovea point of view.
(I'm not sure that's actually what is happening though).

If we could validate this hypothesis, I guess the best strategy then would be to use the Application data directory to store the user's .svg instead. (currently done for color profiles files)

Do you have anything under "C:\Users\[username]\AppData\Local\VirtualStore\Program Files\Kinovea\" ?