You are not logged in. Please login or register.
Kinovea - Forums → Posts by joan
Hi,
In addition to several existing threads about OS X support, I'll repost what I've posted in the French forum a few days ago:
Not going to happen soon 
Not the same programming language, not the same framework, not the same memory constraints, technical restrictions imposed by Apple, mandatory to buy a Mac to write an app, incompatibility of the AppStore terms of use with some open source licences…
Not even mentionning the lack of resource to actually do it.
Merci de renseigner mon impatience !
Pas pour bientôt
Pas le même langage de programmation, pas le même framework, pas les mêmes contraintes mémoire, restrictions techniques imposées par Apple, obligation d'acheter un Mac pour écrire une appli, incompatibilité de la licence de l'AppStore avec les licences libres…
Tout ça sans parler du manque de ressource pour le faire.
Would there be a way to automatically sync the video speeds based on the frame rates of the video?
There are two kinds of synchronization in Kinovea. (I refer to them as static and dynamic but the distinction is not named in the interface).
Static sync is when you use the common frame tracker, common "next", common "prev", "first", etc. buttons. It's purely frame-based. When you ask "next", it advances one frame in each vid. This one is sensitive to frame rate.
Dynamic sync is when you use the common "Play" button. It is not sensitive to differing frame rate. You can compare a 50fps video with a 10fps video, if they both last ten seconds, they will end in unison. It's just as if you'd press play on both. It is however sensitive to differing capture speed (your problem) and this information is not exposed in the file so we can't fix it automatically.
I just realized that I have already tried to address the issue of synchronizing one high speed video with a normal video a few month ago 
Are you using 0.8.15 or 0.8.16 (the fix being only in the latter).
In 0.8.16: open both videos, then specify the capture speed of the high speed camera. (motion > high speed camera).
The slow motion sliders will be locked on the value of the high speed video (the normal video will play in slow motion).
Some questions:
Error message ?
Kinovea version ?
What save option did you use ?
All files or only some of them ?
Can you get logs ?
Hi,
For info I've been working in the "FileTypes" branch for the last weeks (warning, it's very experimental and broken in several places). Let me check if I can reproduce your issues (don't have VS2010 though).
I do remember that EmguCV is advertised to be for .NET 3.5, but I had found a way to make it work for 2.0 anyway. Did you reference the dll in \Refs folder or did you install it separately ?
edit:
Synched trunk to a new folder, opened in VC#2008 Express, switched to x86, rebuilt: OK.
Set "Root" as startup project, F5 : OK.
There's only one Drawings.Designer.cs in the sources (also see here), maybe it's something that resulted from an automatic conversion to .NET 4.0 / Visual Studio 10 ? Not sure.
edit 2:
Ok, I tried with VC#2010 Express and… well.
The automatic conversion does a number of nasty things that breaks the project.
1 - it alters all the .csproj files and redefines the toolchain (compiler, linker, resgen, etc) to be of the 4.0 version instead of 2.0/3.5. (Because .NET 4.0 is a new framework, whereas 3.5 and 2.0 where based on the same underlying infrastructure).
2 - it took the liberty to regenerate all the resources files using the new toolchain.
For most it's not an issue. (Except that now we can't use the project in older version).
For some reason it created "Drawings1.Designer.cs" and added it to the project (instead of replacing the old one). I think it's a bug of the converter.
For the issue with Emgu.CV that can't be loaded… I'm not sure but I think it has to do with references to assemblies in the GAC like System or System.Data. They will automatically use the version corresponding to a certain target framework. So when the target FW was changed to 4.0 in point 1, it actually changed the actual referenced assemblies.
So, I guess that for now, we will say that one has to use an IDE based on framework 2.0 or 3.5 (VC#2005, VC#2008, SharpDevelop 2 or 3) or SharpDevelop 4.x.
I can't repro for now.
I have loaded two vids you previously sent me and let them run side by side in loop for 10 minutes without crash.
I'll try to think of something based on the exception stack trace, if you have more details don't hesitate.
So is the bug that the 2nd video opens at 100% while the 1st remains in slow motion (ie 30%), or is the bug that once two videos are open, the speed between the two are locked together (change one speed, both speeds change)?
It's not a bug it's a feature !™
Haha, always wanted to say that one 
The issue is the locking. Previously the sliders were free from each other, and it was a feature request to have as many things as possible locked together while comparing.
And it does make sense in the context of comparing two videos that have the same capture speed. Similar concept that when you press F6 to create a key image, it creates it in both videos at once. (ok, I'm might be the only person to know about this one).
The fact that you can open one video, slow it down, and then open a second one and have different slow motions is a little trick I hadn't thought about. I would consider this an unrelated bug.
Anyway, the workaround might be to provide a CTRL or Shift modifier to deactivate the locking when changing the speed (if possible/practical).
It will not be by default, because having two videos with differing capture speed is still not the most common scenario. Unless most people think it's an annoyance anyway, in which case it can certainly be disabled. (Feedback please).
Just to be clear for all readers, this is about videos with different capture speed (say one normal video and one 1000fps video). Videos with different playback frame rates (e.g: 30fps vs 24.97fps) are supported out of the box.
Juste pour dire que je trouve ça très intéressant
Hello,
Yes, it is a known side effect of the slow motion being locked between videos.
Haven't gotten around to implement a work around yet.
I'll have a look at this. The way the videos are read has completely changed in 0.8.17 so verification that dual playback works is needed anyway. (that is what you refer to by head to head, right ?)
If you have more details (does it with only these videos or with all), how does the error manifests itself, is it a crash, freeze, something else, etc.
Log files would help a lot.
Yes, it is the problem.
Basically the camcorder (and all other that save to hard drive, DVD, or flash card) do not have streaming capability. The USB connection can only be used to transfer files.
The only workaround with this type of device is to use the analog outlet and an analog to digital converter at the PC end. (either HDMI or S-Video depending if the camcorder is HD or not)
You need to provide more details.
What doesn't work ? (capture, playback)
What happens when it doesn't work ? (error, black screen, something else)
What is the exact model ?
etc.
Very quickly not to disrupt the topic:
- Key images in Kinovea.
- Most simple drawings (like lines or angles) are "attached" to a specific key image.
- Tracks and stopwatches are not attached to any key image.
- Image sequence. No bearing to key images. Just to do automatic snapshot at regular intervals.
- Load key images data: this feature is already here so you can check for yourself. It opens a regular "Open file" dialog that let you pick any KVA file on your hard drive, and import on the current video.
- Format vs extension. Data representation (format) is XML. But the file extension is .kva to make it easier to associate the file with Kinovea. (Very common schema). Open the file in notepad to see how it looks.
- Observational references.
Thank for the comments !
This would leave only two options on the dialog, and this could actually be handled differently:
1 - There could be a simple "save" menu that would always save analysis to text file. (KVA). (KVA = Kinovea Analysis text files?) Do nothing if there is no key images or tracks, etc. ?Please clarify. It would be important for me to save KVA files with tracking information. Also more than one KVA file might be associated with a single video. I am unclear whether the KVA saves the tracks.
Yes. It would work like this:
- When you first open the video, the "save" menu is disabled.
- As soon as you add a key image, a stopwatch or a track, the "save" menu is enabled and let you save all these meta information.
- To be clear, if at some point you remove each and every analysis information, the save menu becomes disabled again. The "export to spreadsheet" sub menus follow the same principles.
The export menu would always be enabled to let you save the video as an image sequence or to save it slow motion even if you did not enrich it.
3) Future. Using Kinovea compare my practiced serve to the pro-serve regarding the timing of both pronation & internal shoulder rotation. No practice yet until I understand pronation timing. When I use Kinovea I would want to save more than one analysis for a given video especially for tracking different objects. There would be one video and sometimes several KVA files associated with that one video. Save new or modified KVA file for each work secession with a given video.
This is definitely possible. When you save a KVA file, you get to choose the file name.
- If you keep the suggested name that matches the video file name, this particular KVA file will be opened automatically when opening the video. (companion file).
- If you choose a different name, you will have to import it explicitely later, using "Load key images data" menu.
You can have several files associated with a particular video, each focusing on a specific aspect for example, and you can combine them all into the current video using the "load" menu repeatedly ("combining" is from 0.8.16 forward. Before, it did a "replace").
4) Finally, in the future communicate what I have using Kinovea videos with analysis tool results permanently in the video using the option discussed here.
Yes, and I feel this is more precisely conveyed by an "export" verb. Because once done, you won't be able to edit the analysis of the exported video.
edit:
Some caveats,
- Contrary to the current default option, the original file would not be backed up in any way, so it must be clear that it shouldn't be deleted.
Hopefully this will be clear since you will only be able to use .kva as format target. But the user still has to understand that this is not a video format, and that this file will only "work" when imported onto an existing video.
- Currently the observational references, (.svg and images), are not saved into the KVA.
(It is certainly technically possible though, as SVG is XML, and raster images could be stored either in CDATA tags or encoded in Base64.)
Returning to this topic.
I'm actually not too sure of the usefulness of the default option anymore. Discussion continues over here.
Kinovea - Forums → Posts by joan