You are not logged in. Please login or register.
Kinovea - Forums → Posts by joan
Bonjour,
Hmm, essayez de faire un clic droit sur le projet "Root" puis "Définir comme projet de démarrage" ou commande équivalente.
Il me semble que lorsqu'on importe une solution il ne sait pas forcément quel est le projet qui sert de point d'entrée. Du coup, il prend le premier qu'il trouve, et ce n'est pas le bon.
Voir également quelques infos correspondantes sur le wiki : building from sources.
Sweet. Thanks for the insight.
Hi,
It is pretty hard for the program to follow a point that changes shape during the video. This is probably what is happening here.
The foot for exemple rotates around the ankle. The hip may be occluded by the arm at some point, etc.
Also, at any given time, there might be some places in the image that actually looks more like the previous position target than the new position of the target itself. This happens when the point to track is small and background get included in the "target". I have experienced that with knee tracking when the person is far from the camera and the leg looks thin on the image.
I would suggest manual tracking at first. Instead of hitting play, just nudge the mouse scroll up a bit to get to the next frame, and see if the automatic tracking is fine for this very frame.
Do this until the tracking goes nuts, and when it does, re-adjust the position manually.
I understand that doing this over the whole video is fastidious 
One other solution (not always an option) is to place some markers on the person.
If you go that route, try to use uniform circular markers. (basically, their appearance shouldn't change when you rotate or translate them.) I found some cheap circular colorful stickers in the kids department of a general store, they look like this.
You can also set dim light conditions and use reflective / led markers.
A sample video may help understand if the issue is that the tracking scenario is too hard to be automatized in the current version, or if there is indeed a defective behavior that should be addressed.
Thanks for the feedback.
Regarding the delayed live, (which I think can be useful in almost any sport to get unattended video feedback), technically, we need to cache frames somewhere to be able to play them later in sequence.
One approach would be to use a global parameter for "Memory Usage" for the whole application.
Such a memory usage setting is currently in use for analysis mode (frames caching) in Player screens, and it could be reused for the capture frame buffer. (meaning setting either a max duration, say 20 or 30 seconds, and setting a max RAM usage, 1GB for instance.)
Asking for RAM usage is not particularly user-friendly, but I couldn't find anything better for playback screens (ideas welcome). That is why it is more or less hidden in the preferences and we try to get good defaults that works for 90% uses. (Currently, 12 seconds and 512MB).
So to sum up, by default you would be able to select a delay between 0 and 12 seconds. For longer delays, you'd have to tweak preferences and increase allowed memory.
(Actually the 12 seconds would depend on the size of images captured…)
Does this sound reasonnable ?
Another completely different approach would be to use an on-disk buffer. In this case the frames would be temporarily stored on the hard drive instead of in memory.
This would allow for virtually unlimited delay (minutes, hours, depending only on hard drive space), but I'm not too sure of the complexity added by this approach in terms of architecture and obviously the loss in performance.
For those interested in the "under the hood" part, here is a schematic of a proposed architecture, using a in-memory buffer. (Comments also welcomed)
Ha ! You only got one wrong, the one I had most doubts about 
The video camera icon (first) was actually intended to be used as a start/pause for frame grabbing. That is, one may use it to freeze the stream sent by the camera on the current image.
I started with a Play/Pause classic icon, but I found it not appropriate for the function…
What you mention (Selecting the capture device) is missing. I thought it would be best if done only once at screen initialization time, but being able to switch device at any point would come in handy. So that means another button.
If anyone think one of these in unclear please chime in !
The "settings widget" was supposed to be a "foldable panel" rather than a drop down menu, the user would fold it by clicking the down arrow on the right (or anywhere in the grey area), leaving only the grey line with a summary of the settings. (unfolding by clicking the grey line again).
I'll upload another mockup.
edit:
So, there are two "camcorder" icons now, but hopefully they are understandable.
Also swaped image and video in the settings panel to match the order of the buttons…
The white area may host the delay slider, and frame cursor when these are implemented.
Let's tackle the user experience part, since it is one of the most important thing, in fact, probably more important than the raw number of features.
I made some UI mock-up, so we can do a little usability experiment 
On the following image representing a tentative capture screen, can you guess what the buttons / icons / etc. mean ?
What do you think they mean ?
Thanks
Hum, in fact this specific interaction is pretty complex and is not clear how / if we will be notified when a device is plugged in.
So, it's probably better to focus on the second interaction: The user changes screen configuration; what do we do depending on the number of camcorders connected?
Then maybe it becomes easier to answer:
Each time there is a new capture screen created, we present the list of camcorders connected that we can link to a screen.
- if we already have another capture screen with a camcorder linked to it we don't list this camcorder as available.
- if there is only one possible device, we automatically link to it and start grabbing its frames.
- if there is no device, we display a small warning dialog.
Does it sound reasonnable for a first shot?
Then we can expand for the connection notification later ?
So, let's say we start with the basic options, 0. frame grabbing, 1. freezing/pausing the frame grabbing, 2. saving the stream to a video file on the fly, 3. displaying the images with a delay, and maybe : 4. browsing directly in the recently captured images without the need to save them to a file.
About saving single frames to disk, a function where you can save the current image with a single click / keypress would probably be interesting too (?)
(with an automatic file name and going to a predefined folder)
Yes, forgot to mention that some thinking is also needed to handle the various cases of camcorders / screens.
This is probably on of the first thing to discuss.
So, basically as a user, we would be able to use the "View" menu to prepare the workspace : select one capture screen, select two capture screens, select a hybrid mode where you have one capture screen and one playback screen.
We need to clear up the user interactivity here because there are many possible scenarios. I'll give them names just in case we need to refer to them later.
Possible screen combinations :
S1 : 0 screen.
S2 : 1 playback screen.
S3 : 2 playback screens.
S4 : 1 capture screen.
S5 : 2 capture screens.
S6 : 1 playback screen + 1 capture screen.
Possible number of devices connected:
C1 : 0 camcorder
C2 : 1 camcorder
C3 : 2 camcorders
C4 : 3 or more camcorders
There are two kind of interactions here:
1 - The user plugs a camcorder to the computer. What do we do depending on the current screens cofiguration + number of camcorders already connected ?
2 - The user changes screen configuration. What do we do depending on the number of camcorders connected ?
Each and every combination will need to be taken into account at some point in the code, so it would be really nice to have a consistent and sensible behavior.
Examples for interaction 1 - The user plugs a camcorder to the computer.
S1 (0 screen) : show a dialog box inviting the user to display a capture screen. If there are already other connected devices, display a list to choose from ?
S2 (1 playback screen) : Should we display a dialog box ? Should we create a capture screen automatically ?
S3 (2 playback screens) : Should we display a dialog box ?
S4 (1 capture screen) : Is it already linked with another connected device ? if not we should directly link the device with this screen. If yes, what do we do ?
S5 (2 capture screen) : Is there an unused screen among the two ? Do we link the device with it automatically ?
etc.
OK, maybe we can group these and just need to define a globally consistent and intuitive behavior for:
- There are not any capture screen available to link the camcorder to.
- There is at least one empty capture screen that we could use.
- There is more than one camcorder that could be linked with a capture screen.
- There is more camcorders connected that we can handle.
Please anyone add your thoughts on what the behavior should be !
Thanks
Yes, being able to cancel long operations is a must !
I need more infos to be able to understand what the issue is.
When the error message appears, you should be able to click on some button to make it display the full error log.
What you are looking for is something that look like this:
************** Exception Text **************
blah, blah, blah.
blah, blah, blah.Please copy and paste this here if possible.
Also, you may try to locate the crash logs of Kinovea as explained in this thread : http://www.kinovea.org/en/forum/viewtopic.php?id=121
If you find some files named "Unhandled Crash", please copy the content here. (or send by mail : joan at kinovea dot org )
Can you expand the details of the exception dialog and paste the exception content here ?
Also, please state which version of Kinovea you are using, and your version of Windows,
Thanks
So, this is what I came up with, it's just a rough draft / suggestions, please definitely add your thoughts and what you think we should do.
So, from my point of view : (again, do not hesitate to scratch it and input your own views)
At a very high level, we could support the following functions : 1. delayed live, 2. pause the frame grabbing and browse in recent history, 3. continuous recording to disk, 4. draw on screen.
What I mean by these are:
- delayed live : the ability to display on screen what the camera saw a few frames ago instead of what it is imaging currently.
- pause frame grabbing and browse : the ability to freeze the frame grabbing and see what the frame buffer contains, eventually save it to a file.
- continuous recording : the ability to save what is currently grabbed by the camera, or what is currently displayed on screen, to a file.
Do you think they are reasonable and compatible goals ?
Do you think there are other functions that could be interesting ?
Do you think some of these are in fact pretty useless ?
If you have some specific usage scenarios corresponding to these or a combination of these, please input them as well. Having well defined usage scenario will help for the interaction design part.
"Capture" (as in grabbing frames from a DV camcorder and processing them on the fly) is one of the 4 main functional areas that need to be addressed as soon as possible in a future stable release.
I would like as many persons as possible to help design this component which will be a key part of the project.
The areas that most need to be discussed are : what are the functionnalities offerred, how the user will interact with them, and what will be the underlying architecture.
Once we have those, we can start refactoring the current implementation of the capture screen.
(the current implementation is more or less "proof of concept" code, the architecture will probably need to be altered.)
Could the printing option be scalable to larger picture a.s.o. ? Now the resolution drops to inrecognizable blur when there are more than 10 pictures even with HD-video. Scaling the background to postersize (A3->) before making the sequence could perhaps improve this?
Yes, there could be an intermediate dialog box to select the final pixel size…
The printing size however will depends on the dpi, I don't know if we can change that.
Currently each image is reduced so the complete "Overview" fit in the display, and this is also this size that is used when saving.
Also, one improvement that may be useful for this function is to be able to change the time resolution by mouse scrolling (the number of pictures sampled), so you start at 25 pictures for example, but you just scroll in a few times to see only 4 images (or out to get 36, 64, 81, etc.).
To all,
I have freezed and updated the translation file to the latest revision :
http://www.kinovea.org/wiki/doku.php/tr … latestfile
A few strings were added and one or two were modified. As always they are highlighted in yellow, and the missing strings in red.
This is the final round before the official release !
Kinovea - Forums → Posts by joan