Hi,

There is currently no tool for measuring an area in Kinovea.
I was also thinking about this recently while updating the tools for the next version.

I was thinking about a drawing tool where you "paint" an area and then you can right click that shape and make it show the measured cm² or whatever based on calibration. This way you could draw exactly the silhouette of the person.

I think what you are mentioning is to discard all pixels that are similar enough to a given hue and count the rest. That might be simpler to use if the room can be set up this way. I'm not sure how accurate that will be though, there will always be missed pixels in the background and false positive in the foreground.

The advantage of the green screen method is that it could be dynamic for free, whereas the painted area would only work for a single frame and you would have to edit it after each change of posture. The drawback of the green screen method though is that it doesn't readily fit in the tool framework and the player pipeline so it will complicate the architecture.

So far there is no clear path. Are you or anyone aware of other software that provide that type of area measurement feature (and that are not using a depth camera to do so)? Can the green screen approach be mocked up in Photoshop or something to see how accurate it would be and what is influencing the results precision?

Thinking of it a bit more, key images are the best way to set time marks. So it would be interesting to be able to right click on a key image and say "set as time origin", forcing the timing information to be relative to this point, like for the synchronized videos. Then a simple tool showing the current time would fill the need. It seems all the mechanisms are already existing. Except for the remaining UX difficulty to be able to flexibly set start/end visibility points.

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.

649

(6 replies, posted in Bug reports)

I reviewed this and I still think it's a 32bit/64bit issue.

It looks like they never released 64bit version of their drivers, so it only works when called from a 32 bit application.

The CL-EyeTest.exe application is 32bit.

They mention it supports x86 and x64 but that's because you can always run a 32bit application on an 64bit system so technically it "supports" it.

Users of other softwares like OBS or Chrome have reported the same problem. Only works with the 32bit variant of the host application.

650

(8 replies, posted in Bug reports)

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.

http://www.kinovea.org/screencaps/0.8.27/customtooldebug3.png

651

(16 replies, posted in Cameras and hardware)

Does it still crash if you set the following: Preferences > Capture > General > Display synchronization, set to Forced framerate and value to 25 or 30.

govert.vandevijver wrote:

But at the top of the image I see @17fps although the camera is setup in the "uEye cockpit" to have 60fps. Also, altough I configure the camera in the "uEye cockpit" to a monochrone image, the image in Kinovea will be in full colour. I looks like the camera parameters are ignored.

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.

653

(14 replies, posted in General)

I answered in the other topic here.

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.

655

(16 replies, posted in Cameras and hardware)

Could you send me the crash log (Unhandled Crash ***.txt ) and the log files from right after the crash?

656

(16 replies, posted in Cameras and hardware)

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…

Interesting setup using the phone as WiFi hotspot. Although I imagine the combo hotspot + camera + streaming must drain the battery very quickly.

658

(16 replies, posted in Cameras and hardware)

Thanks for the follow up. No problem smile

659

(16 replies, posted in Cameras and hardware)

Hi,

@purk_7 stated in another thread that the camera settings were reset after every reboot. Does anyone else have the same issue?

This is not expected. The settings should be saved on Kinovea side and re-injected in the camera when reconnecting, but there might be something special with this model and the settings can't be pushed back.

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.