496 Reply by joan

(13 replies, posted in Bug reports)

When you calibrate a line it will redefine the origin of the coordinate system to the start point of that line, maybe that's the trouble? You can move the origin away from the line by dragging the axes but if the line itself is tracked this might interfere. I haven't tested tracking both the calibration line and the coordinate system origin, this probably won't work well. It's possible there is a bug between the interaction of the coordinate system and the calibration line because this was changed recently.

The calibration stays in memory and is saved in the KVA file. If you make a new one it should overwrite it. At the moment you can't really reset to the uncalibrated state (short of editing the KVA file manually), this would be nice to have though!

There is a bug that was fixed recently but is not fixed in 0.9.3, is that the Linear kinematics dialog will show values in pixels instead of the calibrated unit, until some internal flag is triggered somewhere else. The easiest way to work around this is to go to the preferences and save them without changing anything and it should make the values display in the calibrated unit.

You can also right click a point and do "Display measurement" to show the coordinates directly on the screen, it should be easier for experimenting.

Go to forum: Bug reports

497 Reply by joan

(13 replies, posted in Bug reports)

Yes that's it, the measurements of the second point will be relative to the first.

Thanks for reporting that the coordinate system point is itself visible in the Linear Kinematics graphs, it doesn't really make sense to show it here since it's always zero by definition, I'll note to remove it for future versions.

Go to forum: Bug reports

498 Reply by joan

(13 replies, posted in Bug reports)

Maybe one way to do what you are looking for would be to have one tracked point be the origin of the coordinate system, and the other being a regular trajectory or tracked point.

You can show the coordinate system from menu Tools > Coordinate system, it is trackable. Normally if you track the coordinate system itself the other tracked points will be expressed in the moving coordinate system.

Go to forum: Bug reports

499 Reply by joan

(20 replies, posted in Cameras and hardware)

Regarding flickering, assuming it's coming from the mains AC frequency at 50Hz or 60Hz, can you guys try to set the camera framerate to a multiple of this to see if it improves the situation? Although I imagine you'll have 1/2 chance of synchronizing to the dark part of the flicker.

Go to forum: Cameras and hardware

500 Reply by joan

(42 replies, posted in General)

Dr.Dank wrote:

the graphs don't follow the scale set by calibrated lines and all accelerations are shown as zero.

You're right, there is something weird going on. If you go to Preferences > Playback > Units and simply hit save, then open the diagrams dialog again, it should be in the correct units… I'll investigate.

Being the second derivative acceleration is super sensible to even the smallest noise in the positions, and the normal filtering usually don't fix it, and you will get values that go up and down when they really shouldn't. Use this as an approximation. To give an idea, we tested with a simple ball in free fall and it was already hard to get a consistent g, instead we got something varying between 8 and 10 m/s².

The diagrams are somewhat interactive by the way, you can hover the mouse over the Y axis values and scroll, and it will rescale the axis. Inside the graph you can right click and drag to move around.

edit: OK I think I found the issue with the initialization of the speed and acceleration units. This should work in the next version.

Go to forum: General

501 Reply by joan

(20 replies, posted in Cameras and hardware)

When installing the Camera Software Suite or the runtime redistributables, it is necessary to use the "Custom" option in the installer, expand the "pylon Runtime" node and select "pylon C .NET Runtime" option.

If you have already installed the software you can re-run the installer and choose "Modify the current installation".

https://www.kinovea.org/screencaps/0.9.2/pylon-install.png

Go to forum: Cameras and hardware

502 Reply by joan

(42 replies, posted in General)

Dr.Dank wrote:

Something I didn't mention in my last post is that some of the videos only play until about halfway through. Converting to .mp4 seems to get around that problem, too.

vbendus reported a similar issue here: https://www.kinovea.org/en/forum/viewtopic.php?id=960

Are the video filmed with the default camera app on the iPhone or something else?

Go to forum: General

503 Reply by joan

(20 replies, posted in Cameras and hardware)

If you are used to version 0.8.15 note that the cameras now have their own tab in the explorer panel on the left. Instead of the old way of opening a capture screen first and selecting the source from its settings, you open the camera explorer and launch a camera from there (list or thumbnail) or drag and drop it to a capture screen.

Go to forum: Cameras and hardware

504 Reply by joan

(42 replies, posted in General)

Thanks for the sample, I can reproduce the issue right away. Already when advancing in the video there is a problem in the timestamps. It looks like after some point the timestamp is repeated and the next one is skipped. I'm not sure where this is coming from. I get the timestamp from the video decoding library.

As a temporary work around you could use the Tools > Linear kinematics window to export the data instead of Export to spreadsheet. The Linear kinematics window is newer and eventually the Export to spreadsheet function will be re-implemented on top of it. However this only lets you export one measurement at a time.

Another bug I see is that you have set a time origin but the trajectory times are still relative to the beginning of the video.

Go to forum: General

505 Reply by joan

(20 replies, posted in Cameras and hardware)

First of all please confirm you are using Kinovea 0.9.3 because the old 0.8.15 doesn't support the Pylon SDK.
The current version 0.9.3 is built against Pylon SDK 6.0. I haven't tested it against their latest 6.1.
Go to the log (menu Help > Open log folder, then open log.txt), in the first few lines after an empty space where the program restarts, you should find the camera initializations. There should be something like this:

932 - DEBUG - [Main] - RootKernel - Loading camera managers.
990 - INFO  - [Main] - CameraTypeManager - Initialized Basler camera manager.
...

If you have an error message instead of this please post it here or post the log or send the log at joan at kinovea dot org.
If you don't have an error message, can you see the thumbnail of the camera in the camera explorer?

Go to forum: Cameras and hardware

506 Reply by joan

(17 replies, posted in General)

I'm not sure what you mean by a pause of 9ms to 20ms, at 30 frames per second the frame interval is 33ms. Is the pause only when you replay the file now? Is it always at the same point in the video or does it change? Does the video speed decrease on its own?

Go to forum: General

507 Reply by joan

(36 replies, posted in General)

It's only to capture video at this point.

Go to forum: General

508 Reply by joan

(17 replies, posted in General)

Yeah, in one of the logs there is for example this:

Frame #100. Conversion/Encoding: ~1.010 ms. Write: ~1.890 ms.
Frame #200. Conversion/Encoding: ~0.790 ms. Write: ~1.750 ms.
Frame #300. Conversion/Encoding: ~1.480 ms. Write: ~1.680 ms.
Frame #400. Conversion/Encoding: ~1.580 ms. Write: ~1.960 ms.
Frame #500. Conversion/Encoding: ~0.850 ms. Write: ~1.590 ms.
Frame #600. Conversion/Encoding: ~1.430 ms. Write: ~39.580 ms.
Frame #700. Conversion/Encoding: ~0.830 ms. Write: ~1.730 ms.
Frame #800. Conversion/Encoding: ~0.920 ms. Write: ~1.730 ms.
Frame #900. Conversion/Encoding: ~0.830 ms. Write: ~85.980 ms.
Frame #1000. Conversion/Encoding: ~1.030 ms. Write: ~7.390 ms.

The last number is the average write time in milliseconds over 100 frames. But the most likely where it's 39 or 85 is that there is a single frame that was blocked for several seconds for some reason. I've seen the same pattern when I put the target directory on the system drive.

Go to forum: General

509 Reply by joan

(17 replies, posted in General)

So in the final recording there is a period of time where the time or frame counter advances but the image stays the same? Interesting. In that case that would mean the frames were duplicated at the source and the freezing would already exist either at the Pylon library level or the camera…

Could you send me a log file at joan at kinovea dot org? There is timing info while recording that could be interesting to analyze to see if there is a spike visible.

Other things to check:

- What version of Pylon have you installed, the module is based on Pylon 6.0.

- You can try to add a camera simulator in Kinovea by doing Manual connection in the camera explorer panel and changing the camera type. Then you can change the image size and framerate to match the real camera and see if the same problem occurs.

- It's also possible to add a camera emulator from Basler. In the Pylon viewer you can go to menu Help > Get help, and then to Software > pylon Camera software suite > Camera emulation and then under "Enabling Camera Emulation in the pylon API" they describe how to add camera emulators. Basically you need to add an environment variable in Windows named "PYLON_CAMEMU" with a value corresponding to how many emulators you want. When you do that they will appear in Kinovea as normal cameras and you can change the settings. The framerate probably won't really go as high as the real camera though.

Go to forum: General

510 Reply by joan

(17 replies, posted in General)

Thanks. And the drop counter in the info bar stays at 0 or it increases?

To summarize, the problem is that the display for the live camera (delayed) freezes for a moment, although the corresponding recorded file doesn't show a jump between frames. Is this correct?

One thing that can cause lower performance is when the target folder for recording files is on the same drive as Windows, as the system is regularly writing into its own files sometimes it competes for drive access. When I do this on my machine the live image freezes every 10 seconds or so and the drop counter increases. As soon as I move the target to another drive it works. (Both drives are SSD).

Go to forum: General