Search options (Page 78 of 133)

Pour la capture il faut la version 0.8.15 ou plus.
L'onglet « Capture » des préférences est présent même lorsqu'il n'y a pas de caméra connectée.
Pour lancer l'écran de capture cliquez sur la petite caméra dans la barre d'outils.

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.

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).

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.

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.