coachmattb wrote:

I notice that which USB port I plug into first makes the difference. Took quite a while thru the trial and error process but persistence pays off!

Maybe it has to do with the USB root hubs vs normal? I seem to remember that some USB ports are more important than others. In the device manager, you can see some are "root" while others aren't.

Maybe if you connect the two cameras on ports that ultimately go to the same USB root hub, it won't work as the driver will be loaded only once and detect that two cameras are plugged. But maybe if they are connected to two different root hub the driver is loaded twice and both work independently… (?)

1,037

(1 replies, posted in Bug reports)

This should be improved in 0.8.17. Please retry with this version and report.

1,038

(5 replies, posted in Bug reports)

Oh, I thought I had posted an answer here…
Anyway, I'm not sure what you mean by "it does show as a high speed camera" and "try to change back to a standard webcam". There is no concept of high speed camera in the Capture screen. The list of camera under "source" is the list of connected devices (+ a special device for network cameras). The high speed camera menu is used exclusively to adapt timing in the playback screen.

Please install 0.8.17 and retrieve the logs of when the problem occur. You can attach them to bug report 274.

1,039

(26 replies, posted in General)

I'm not quite sure how to reproduce the problem. I load two videos, synchronize on a common event, then use the blue buttons of the WZ bar : http://www.kinovea.org/help/en/selectionsmall.png Is it what you are doing that causes the problem ? If not please describe step by step.

Some notes:
- When the working zone fits in the cache capacity, it is loaded in cache and you may see a progress bar dialog. The dialog should disappear when all images are loaded.
- When you change the working zone of one of the videos, the synchronization point is reset to 0.

1,040

(26 replies, posted in General)

One trick you can try is use the "pause" button, and then use the delay slider to browse the buffered footage manually.

Being able to play at slow motion while continuing to buffer the live frames would be trickier (and would only last for a limited period of course.).
Probably doable by automatically moving back the delay slider at the right pace.

I imagine having proper replay scenarios is probably higher priority. (hit one key to: record X seconds of buffer, go on recording for Y seconds, then open the saved video in a playback screen and play it back at Z% slo-mo).

I think the original post issue is specific to the capture screen and should be fixed in 0.8.16 forward.

Regarding the stopwatch, it will follow the configured "time format" from Options > Time markers format. Double check if you have it set to "classic" or "frame number". When using timed format, it should indeed take into account the time adjustment for high speed camera.

Really ? That's awesome.
It was my understanding that the limitation was built in the driver…

For two DV camcorders of the same brand/model, it was found that two separate firewire cards are needed.

1,043

(26 replies, posted in General)

Oh, you mean importing animated GIF as Observational reference > Import image… well no, it's not supposed to work. It would need a new image tool with an internal timeline. Not overly complicated, but…

Similarly, importing a "directory of images" might be interesting. Importing a video would be more tricky.
One related thing I'd like to do in the future is to improve the "merge" feature in dual screen scenarios and have one of the video as a small insert on top of the other instead of blunt superposition.
I can very well imagine an "animated image" tool, that would display its current image based on some sort of "source". The "source" would just have to provide the right image based on a specific time. That could be a GIF, a video, an image constructed on the fly to draw a plot, the real time image from the camera maybe, possibilities are endless.
But that's not for short term smile

Exporting to GIF is not planned for now.

1,044

(5 replies, posted in Français)

Bug corrigé en version 0.8.17.

1,045

(26 replies, posted in General)

also I se a bug I tried to overwiew a sequennce of 16 picts and save it but doesent work on this version? just apear a image saved with only N°1 but nothing on it ??

Ah, it's a bug.

i cant see animated gift show up

Do you indeed have animated GIFs in the folder you are exploring ?
http://www.kinovea.org/screencaps/0.8.x/hit.gif

1,046

(0 replies, posted in Français)

Version expérimentale, merci de remonter toutes les regressions !

Installeur: Kinovea.Setup.0.8.17.exe

Le topic annonce sur le forum anglais.

Je recherche toujours un contributeur qui pourrait traduire de l'Anglais vers le Français ces messages d'annonces de versions, posts sur le blog et autres !

1,047

(26 replies, posted in General)

Animated GIFs should show up in the file explorer as any other files and be readable as videos (previously only the first image would show up).

For images, the fact that they now turn into videos will be useful for some applications. For example consider the schema of a football field. You could open it side by side with the match video, and add drawings synchronized with specific moments.
This scenario is not really possible until the duration can be configured, but it'll come. Similar application can be for anatomy schema and clinic exam video.

Re: Sandbox menu,
Uh-oh, don't touch my playground! big_smile It's a secret menu that I forgot to remove. It shouldn't be there, will probably do nothing or crash.

1,048

(26 replies, posted in General)

Experimental version feedback needed ! big_smile
Beware of regressions and report anything suspicious. Do not assume the issue is known.

Installer: [s]Kinovea.Setup.0.8.17[/s], See Kinovea.Setup.0.8.18 instead.

So what's new ?

A. Playback performances
Reading performances has been the number one effort of this iteration. It has led to some wide and deep refactoring to the internal pipeline.
I don't want to go too far into the details because they are probably boring, but there are a few things you might be interested in to make the most of it.
I'm not going to post benchmarks either, please test with your files and report.

1. Asynchronous decoding with prebuffering.
- It is a third mechanism to pull the frames from the files into Kinovea. (the others being "one frame at a time", and the "cache" or "analysis" mode).
- It is enabled automatically anytime relevant.
- Conceptually, the buffer looks like this:

http://www.kinovea.org/screencaps/0.8.x/prebuffer.png

During continuous reading, the play-head is always kept roughly at this position. The buffer anticipates some frames ahead of the position (green blocks) and it keeps a few after it.
The result is smoother reading and support for immediate back stepping (up to a few frames).
It runs in its own thread so the decoding can be done in parallel to the rendering.


2. Unscaled rendering.
- It's not hardware accelerated graphics, but it's the closest thing I know of in GDI+ land.
- The idea is to decode the images at the size we will render them, so that we can render them without interpolation.
- It may seem obvious, but it has far reaching implications, considering image stretching feature, zooming, magnifier tool, mirroring, trajectory tool and coordinates, dual screen superposition, etc.
- The important point is: the smaller the image, the smoother it will play.
- To provide more control, it is now possible to manually squeeze the image smaller than its original size. So if a file is jerky, try to reduce the rendering rectangle a bit.

B. But also
- Danish locale ! (Heinrich Winther).
- Animated GIF. Yes, you read that right baseball mechanics addicts wink
- Images files are now treated differently. They are turned into 10-second videos. (So you can add several sheets of drawings on it). Duration will be configurable later on.

Killed bugs : 257, 258, 269.

+ Raw changelog.

Almost every area of the application have been impacted somehow. So please report regressions ASAP, thanks.

Bonjour,
J'ai répondu sur le forum anglais pour une plus grande transparence générale.
Je pense aussi que c'est un manque dans le programme. Il y aura une itération dédiée à de nouveaux outils, j'espère pouvoir y inclure un outil de ce type.

Hello,

I believe it's also probably what was suggested in this thread.

I think it's an important point, and after looking quickly at some physical goniometers, I can see how the current angle tool is not appropriate for a range of applications. 
What I'd like to do is to first think of it as a separate tool, say a goniometer tool or similar, dedicated to measuring joint angles and range of motions.
It does not have to resemble a physical goniometer, but should probably provide the same services and convenience. We'll see if it can be merged with the simple angle tool later.

- Setting the reference angle -> a third manipulable branch, or having a fully graduated circle, or just main landmarks, or something else…
- Mesuring an angle relatively to the reference.

Don't hesitate to suggest on the form or usability or anything you think of.

edit:
In addition to being able to manually set the reference angle, it may be interesting to have a contextual menu with presets for joints… But some have several degrees of freedom…