You are not logged in. Please login or register.
Kinovea - Forums → Posts by joan
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 
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).
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).
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 !
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\" ?
I have a start up problem, it crashes. Yet it works on some computers
Hi,
Can you try to get the Unhandled Crash logs please.
Hmm… And you can see the original ones, right ?
Can you remind your OS version ? Windows 7 ? And are you running as administrator or normal user ? (Will try to reproduce the context)
Hmm, looking at the code I can see that the function is only looking for ".svg" files with the extension in lowercase. So if your files are ".SVG" for example, it won't find them.
Is that what's happening ?
I'll fix this for next version.
Ah yes, frame by frame and play have different behavior. When doing frame by frame, it seemed more sensible to actually move frame by frame in each video.
But I can see how it make little sense if the two videos have differing framerates.
Maybe both could be aligned on the fastest framerate of the two. If we have video A @ 30fps and video B @ 15fps, going to the next frame would move A by 1 frame, and B by 0.5 frame(staying on the current frame).
We can keep a counter to detect when the slowest video should advance one frame.
I'll add it to the suggestion queue 
Even after you restart Kinovea ? Can you see the others ?
What happens if you make a copy of an existing file, can you see the copy ?
When building the menu, no deep scanning of the file is done, so anything with an .svg extension should show up…
It was removed some time ago…
Generally the silouhete is not as clear cut as in the snapshot above, because there is all kind of lines in the background.
Here is a video of the effect applied to a golf video.
It is funny to watch, but if the goal is to focus on the motion of the athlete/student, I think we should try to think about something more useful/powerful, like removing the background and things like this.
Hi,
That dialog box is set be shown at the center of the screen, maybe that doesn't work similarly on various systems.
Can you move up the dialog box by dragging it with the title bar ?
It has a maximum size of 370 pixels which should be fine for any screen resolution but well…
Also, there is an additional option group that appears when the speed cursor is not on 100% (a new check box to save at slow motion rate). Could you guys try both with and without slow motion (just change the speed and try saving again) and see if it makes any difference ?
Thanks
Hi,
Normally the synchronization is already framerate independent.
Let me know if you find otherwise, that'd be a defect.
Expected behavior: You set the sync point on an event in each video with differing frame rates, then when hitting Play both video are played at their respective speed, and they still get by the sync point together.
You can also slow down one video but not the other, etc. They should still get to the sync point at the same moment.
Hi,
It works to some extent (couldn't test thoroughly), but it's been reported to crash for others + flickering issue during capture itself.
Not the same errors as you though.
I'll gather all defects and work on them globally in September.
Thanks for the report.
Hi,
Just tried but it didn't crash.
Can you be more specific about the context, what saving option do you use ?
Thanks
Kinovea - Forums → Posts by joan