Low frame rate

[BigMuscle85]

Seek Thermal camera should have frame rate about 9 frames/sec. I am running on Raspberry Pi 4B and when using this library, the frame rate is stuck at 4.4 frames/sec. CPU usage is very low. When using official Seek Thermal SDK, the frame rate is correctly at +- 8.8 frames/sec.

I am running with Seek Mosaic Core 320x240 9Hz camera.
I tried with seek_test_pro example and the frame rate is low too.

What could cause this problem?

[Bostwickenator]

Unfortunately we do not have access to the mosaic cores for testing. Frankly I'm quite surprised to hear they work at all with this library. Currently this library is tested against the Seek Compact line of cameras. My guess at this point would be something to do with the USB frame buffer size. We might be requesting too little data. You said you tried with the compact pro example, did you have to make modifications to it before the camera worked (if slowly)?

…

On Wed, Aug 25, 2021, 6:18 AM BigMuscle85 ***@***.***> wrote: Seek Thermal camera should have frame rate about 9 frames/sec. I am running on Raspberry Pi 4B and when using this library, the frame rate is stuck at 4.4 frames/sec. CPU usage is very low. When using official Seek Thermal SDK, the frame rate is correctly at +- 8.8 frames/sec. I am running with Seek Mosaic Core 320x240 9Hz camera. I tried with seek_test_pro example and the frame rate is low too. What could cause this problem? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#67>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMOHDA7QEMRJVNTO4GHCBLT6TGR5ANCNFSM5CY2YSUA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email> .

[BigMuscle85]

I didn't do any modification to the code, so I guess the camera is the same as Compact Pro. It is also reported with the same vendor and product numbers:

Bus 001 Device 004: ID 289d:0011
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  idVendor           0x289d
  idProduct          0x0011
  bcdDevice            1.00
  iManufacturer           1 Seek Thermal, Inc.
  iProduct                2 PIR324 Thermal Camera
  iSerial                 0
  bNumConfigurations      1

When I increase request_size in fetch_frame, then nothing happens. It still reads 13680 bytes only.

[BigMuscle85]

The issue is probably not related to the camera but it seems that even small delay in the code results in losing every second frame

[13:55:17] Frame id = 6, counter = 114
[13:55:17] Frame id = 1, counter = 115
[13:55:18] Frame id = 20, counter = 116
[13:55:18] Frame id = 3, counter = 119
[13:55:18] Frame id = 3, counter = 121
[13:55:18] Frame id = 3, counter = 123
[13:55:19] Frame id = 3, counter = 125
[13:55:19] Frame id = 3, counter = 127
[13:55:19] Frame id = 3, counter = 129

example code contains 10 ms delay on waitKey:
char c = cv::waitKey(10);

If I reduce to 1 ms only, then frames are not lost and frame rate increases to correct 8.8 frames/sec. It is actually weird, because 10 ms delay should still allow up to 100 frames/sec.

[Bostwickenator]

Wow that's really odd. I'm not seeing that reduction in frame rate with the 10ms sleep. Good sluthing 🕵️‍♂️. I wonder if this core expects an outstanding request before it starts accumulating a frame or something odd like that. Doesn't seem likely given from your description it's otherwise completely compatible with the Compact Pro. If you fire off a PR for that change I'll be happy to merge it.

…

On Wed, Aug 25, 2021, 7:13 AM BigMuscle85 ***@***.***> wrote: The issue is probably not related to the camera but it seems that even small delay in the code results in losing every second frame [13:55:17] Frame id = 6, counter = 114 [13:55:17] Frame id = 1, counter = 115 [13:55:18] Frame id = 20, counter = 116 [13:55:18] Frame id = 3, counter = 119 [13:55:18] Frame id = 3, counter = 121 [13:55:18] Frame id = 3, counter = 123 [13:55:19] Frame id = 3, counter = 125 [13:55:19] Frame id = 3, counter = 127 [13:55:19] Frame id = 3, counter = 129 example code contains 10 ms delay on waitKey: char c = cv::waitKey(10); If I reduce to 1 ms only, then frames are not lost and frame rate increases to correct 8.8 frames/sec. It is actually weird, because 10 ms delay should still allow up to 100 frames/sec. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#67 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMOHDFYSEAVBRJBG3SXLL3T6TM5DANCNFSM5CY2YSUA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email> .

[BigMuscle85]

I just put frame grabbing into the separated thread and it solved my issue.

[Arnold1]

hi, im comparing the InfiRay 2 Pro and Topdon TC-001 with the SEEK thermal compactRPO.
the InfiRay 2 Pro and Topdon TC-001 seems to have a frame rate of 25 which SEEK thermal compactRPO. whats the advantage of using a SEEK thermal compactRPO instead of those other cameras?

this project does not work with the InfiRay 2 Pro and Topdon TC-001?

[NanoExplorer]

This becomes a much bigger issue with the Compact Fast Frame models. Even the 1 ms delay is too much and I lose every other frame, resulting in frame rates comparable to the non-fast-frame model. On my fork I have code allowing the driver to fire off the next frame request before calling waitKey: NanoExplorer@a0db26a .

Edit: don't use that exact code quite yet though, it will leave the camera in an undefined state.