You are not logged in. Please login or register.
Kinovea - Forums → Posts by joan
For the point at frame i, it uses the positions at frames i-1 and i+1 and divide by 2 time intervals.
Also depending on where you are looking the speed is calculated using either the raw positions or filtered positions. If you use the Linear Kinematics dialog it uses the filtered values unless you have disabled filtered in the preferences.
You can go to "File > Open replay folder observer…" and point it to where the captured videos are saved.
No at the moment there is no generic USB 3 Vision support. Only specific vendors are supported. Although I will be looking into this for future versions.
Yes the time is the total number of milliseconds since the start of the application. So between 2226 and 6249 there are a bit more than 4 seconds. In this case the USB 2.0 camera took just 30 ms to initialize, the ~1-second gap between 543 and 1481 is from another bug that I have fixed since.
This is even stranger than I thought. One camera took about 600ms and the other 4 seconds (both pretty slow) even though they are the same model…
Thanks. Interesting!
If you open the log and check the time column (first number), is there a big gap just before the first line mentioning the camera?
Like this:
1627 - DEBUG - [HD USB Camera thumbnailer] - SnapshotRetriever - Starting HD USB Camera for thumbnail.
5808 - DEBUG - [UI314xCP-C thumbnailer] - SnapshotRetriever - Starting UI314xCP-C for thumbnail.
I'm not sure if that's what you meant but for the shortcut thing you don't have to write any code. All the commands are listed in Preferences > Keyboard. It's just that this particular one doesn't have a shortcut assigned, you'll see it says "None". But you can assign one from the preference page.
The recent observers list should be populated automatically when an observer is opened, but I imagine you could edit it manually for testing purposes.
I just pushed a change to support patterns in the filename part of the replay observer (everything was almost ready to go). This should work with observers defined in workspaces. So based on how you setup the capture output files it should be possible to have each observer specific to each capture.
For example, in the workspace file:
<FullPath>D:\temp\cam1-*.*</FullPath>This will observe the files under "D:\temp\" but only the ones that start with the "cam1-" prefix. You can use multiple "*" wildcards and also "?" for single character match. For example "?at.*" will match "bat.mp4" and "cat.avi", but it won't match "flat.mp4".
A unique "*" will still match any file and is still the default when creating an observer from the main menu by pointing a folder.
1 - The audio trigger is always live so for at least one of my instances, I do get multiple videos. I have added a line to the source code to disable the trigger but I don't have a sufficiently elegant way to re-enable it.
There is a command called "ToggleArmCaptureTrigger" that enable/disable the audio trigger, it's not bound to any keyboard shortcut by default but maybe you can use that? It's the same as clicking the speaker icon in the capture controls.
The auto disarming for a cool-off period is on the roadmap but most probably not for the next version.
2 - The replay observer will always load the most current video and I am recording from 3 cameras into the same directory. I could record into different directories to solve this.
For this what I wanted to do originally was to support glob patterns in the filename. At the moment the "filename" field for a replay observer is set to "*", as in, "any file". (further filtered by supported extensions). But the idea was to allow for finer filtering on the filename so you could have observers that only load a specific camera if the file patterns are set appropriately.
The tricky part really is where to put the UI to let the user specify this. But we could start by making it work for workspaces.
Now that there is a menu to switch between video and observer directly in the player infobar, I think it will be a good place to host that extra customization option.
Hello everyone,
There seems to be an issue with some (all?) IDS camera and slow startup time. Looking for more data about this.
When opening the program on the camera tab, how long does it take for your IDS cameras to fully show up?
I have a small USB 2.0 "UI1220LE" and based on the logs it already takes about 300ms. But I have received logs of people where the high-end cameras are taking multiple seconds.
Data I've gathered so far:
- UI1220LE: 0.3 s.
- UI3240LE: 1 s.
- UI3140CP: 4 to 5 s.
- UI3160CP: 5 s.
I don't reproduce this with other machine vision cameras so I'm wondering where the problem might be coming from and if it could be mitigated. We've already ruled out the "USB selective suspend" option in Windows power settings, we still get the same lengthy initialization with the option disabled.
Do you have similar slow startup times with high-end IDS cameras (multiple seconds)? Is it the same in uEye Cockpit?
Thanks
Great! What was the name of the software? Maybe I can reproduce the crash and see if anything can be done about it.
The requirement here if I understood correctly is to have a single instance of Kinovea with a single screen inside, and to switch between capture and playback, to minimize resources consumption.
Yeah, at the moment I don't have a good idea on how we could do this nicely.
One idea maybe would be to have a command that starts a playback screen on whatever is the most recent entry in the capture history. Then you could close the capture screen and use this command. To reload the camera afterwards would require the workspace function to work at any point in the life cycle of the application instead of just the startup.
No, it is not expandable unless the source code is modified. The underlying mechanism is "commands" and the shortcuts are bound to commands. The preferences.xml file defines the mapping between commands and shortcuts. In order to add a new shortcut there first need to be a existing command. A command does not necessarily have a corresponding shortcut bound to it.
What is the action you wanted to do via a keyboard shortcut?
Yes. This should be fixed in the next version.
Allow me to clarify what is happening. In previous versions the direction of the calibration line was completely ignored, and the coordinate system was always aligned with the image axes. This was a bit restrictive, if the camera was rotated a bit you couldn't really get vertical or horizontal coordinates in world space, they were always aligned with the rotated camera. We had to use the plane calibration to work around this limitation.
In 0.9.3 the line direction is used as the horizontal axis. This way we can have a rotated camera and still get coherent coordinates. But as you noted this is not always desirable.
In the next version when you define the scale of the line you also tell if this line is along the horizontal axis, the vertical axis, or if its direction should be ignored and the coordinate system should use the image axes.
Try version 0.9.3 if possible, there is a new recording mode and more improvements.
When you press the red record button it records the video using the mode set in Preferences > Capture > Recording. This defines if delay is taken into account or not and whether the recording is done on the fly or not.
It decides to compress the video or not based on Preferences > Capture > General. Depending on the speed of the storage medium and the CPU one option might be better than the other. If you have an SSD with room to spare you can try recording without compression.
If the length of the recordings fit in the delay cache you can try the Retroactive recording mode. In this mode it stores the frames in memory until the the recording operation is over and then compress/save all at once, this avoids dropped frames. You can change the size of this cache in Preferences > Capture > Memory.
Kinovea - Forums → Posts by joan