Search options (Page 47 of 136)

I agree it would be interesting and useful to have this feature with negative time.

Right now I'm not satisfied with how the stopwatch works and at some point I'll attempt to improve it.

To better understand the way it works internally consider that it has a "visibility start" and "visibility stop" and it has a "counting start" and "counting stop". The "counting" segment is always nested inside the "visibility" segment. The countdown mode is simply "inverting" the value of the counting.

The shortcomings at the moment is that you can't move the "visibility start" point, so once you put a stopwatch on the video it can never be moved back to an earlier point. And you can only move the "visibility end" point backwards in time with the "hide" menu.

I am trying to think of a way to make it more flexible.

The system you describe with the countdown going on in the negative makes me think that this would be better suited for a new tool that would let you set a single point in time, rather than a segment in time.

There is also another time tool that is missing, one that allow the measuring of several segments in a row, with or without gaps between them.

Another interesting one would be a "cyclic timer" tool that counts to a given time and auto-resets and starts counting again.

Hi,

I have addressed the following points for the next release:

1. Position of the text for angles

There is now a "textDistance" attribute on the angle node.

<Angle origin="1" leg1="2" leg2="3" signed="true" ccw="true" supplementary="false" radius="0" textDistance="40" tenth="true"/>

2. Double constraint fixed length + rotation steps.

The rotation steps constraint now has an attribute "keepDistance" that will force the point to stay at the same distance from the origin. I think it still didn't make sense to have a full multi-constraints system, as this was the only meaningful combination of two constraints.

<Constraint type="RotationSteps">
        <RotationSteps origin="1" leg1="0" step="5" keepDistance="true" />
</Constraint>

Note that the existing "DistanceToPoint" constraint supports the SHIFT modifier that forces segments to lock onto 45° steps. This is supported out of the box and doesn't need any specifics in the tool file.

3. Completely locked points.

There is now a "LockedInPlace" constraint that will simply ignore the applied motion.

<Constraint type="LockedInPlace" />

In addition to that, there is now a debug mode for the custom tools. It will be available from menu Options > Preferences > Drawings > General, check box "Custom tools debug mode". It will show the points ids, the segments ids and names, and angles ids and parameters. Counting starts at 0.

To clarify a point, the way the IDS cameras work, at least in regards to the IDS SDK used in Kinovea, is that each application is responsible for managing its own set of parameters for the camera.

When the program connects to the camera for the first time it will always receive a default parameter set. Then they have helper functions to save and load the parameter set as it gets customized for the application.

You can see the file where these parameters are saved for Kinovea by going to menu Help > Open log folder, and then go to the sub folder "CameraProfiles\IDS". There you should see a .INI file for your camera. There will be entries like image width, height, framerate, exposure, etc.

The parameters you set in IDS uEye Cockpit are only used by the Cockpit application.

This works differently than, say, Basler cameras, where they have a "global" parameters manager/API and all applications will read/write the same values.

In uEye Cockpit you can also see this concept by the menu File > Load parameters and File > Save parameters. This will save an .INI file that has the same format as the one you can find in the sub directory of Kinovea preference files above.

I imagine that if you had a specific parameter that you wanted changed that is not exposed in Kinovea you could try to save the .INI file from uEye Cockpit and then merge it with the file used by Kinovea. Although I would like to hear about these specific parameters to see if it would be relevant to have them supported natively in Kinovea.

Hi,
Kinovea has its own configuration for some of the parameters and should leave the others untouched.

What do you have when you go to the camera parameters in Kinovea? (You can click on the info line at the top or use the configuration button in the lower left).

You should be able to set the stream format to MONO 8 here for monochrome and change the image size, framerate, exposure and gain.
The framerate configured can only be reached if the exposure duration value is low enough though, as exposure has priority over framerate. For your 60 fps target, make sure the exposure duration is less than 16 666 microseconds.

This is for 0.8.26 by the way.

Interesting. It might be due to the amount of current the camera is pulling and the extension cables aren't up to spec?   
Some people use Ethernet-to-USB adapters to extend USB over long distances. Maybe an avenue to consider…

Thanks for the follow up. No problem

I just tried it for testing and it worked. (Using 0.8.26).

The app I used is "IP Webcam" from Pavel Khlebovich: https://play.google.com/store/apps/deta … p;hl=en_US

When starting the server on the smartphone, it gives the IP address of the stream in the lower part. It is the IP of the phone with the port configured (8080 by default). When connecting to this address in a browser, the phone serves a web page. I clicked Video renderer > Browser button on that web page and got the live stream inside the page.

Then I did right click on that live stream image and "Copy link location", to get the URL of the actual stream, it was indeed http://<ip>:8080/video.

Copying this address in the configuration dialog in Kinovea made it work. I left the stream format to MJPEG in Kinovea and didn't change any defaults in IP Webcam. I did not choose the MKV option in IP Webcam.

Kinovea still has to be set to Capture > General > Display synchronization > "Camera frame". Not "Forced framerate". I haven't investigated further on this point at the moment.