[aravis] Re: Getting Thermal Imaging data using python and ARAVIS

  • From: Saurabh Chatterjee <saurabhsaurc@xxxxxxxxx>
  • To: aravis@xxxxxxxxxxxxx
  • Date: Sat, 23 Dec 2017 07:59:14 +0530

No, there's nothing wrong with the cables. It's working fine in MATLAB,
Flir tools, etc. Only Aravis has the problem.

Incidentally I'm not sure what I did exactly but now Aravis seems to not
work with my camera at all now, even the aravis viewer. Oh well..

On Sat, Dec 23, 2017 at 12:27 AM, Jared Starkey <JStarkey@xxxxxxxxxxxxxx>
wrote:

This could be an issue with a bad transmission medium.


Have you tested your cables?


------------------------------
*From:* aravis-bounce@xxxxxxxxxxxxx <aravis-bounce@xxxxxxxxxxxxx> on
behalf of Saurabh Chatterjee <saurabhsaurc@xxxxxxxxx>
*Sent:* Friday, December 22, 2017 9:09 AM
*To:* aravis@xxxxxxxxxxxxx
*Subject:* [aravis] Re: Getting Thermal Imaging data using python and
ARAVIS

Ok, I modified the code to print the time taken for each frame.

Indeed, what happened is that it seemed to slow down pretty bad for
certain frames
Eg.
Frame:  110  time taken:  0.0009679794311523438
Frame:  111  time taken:  0.001013040542602539
Frame:  112  time taken:  0.0014612674713134766
Frame:  113  time taken:  0.0010993480682373047
Frame:  114  time taken:  0.004855155944824219
*Frame:  115  time taken:  0.48161911964416504*
Frame:  116  time taken:  0.001965761184692383
Frame:  117  time taken:  0.0023725032806396484

Because of those bad frames, it slows down the entire frame rate.

So it is probably a packet resend problem.

Now for the bad news. I meddled with the packet resend settings and ended
up even worse off- now the packet error seems to occur practically every
other frame.
I don't even know how to get back to the previous settings.. Hopefully
I'll work it out..

On Fri, Dec 22, 2017 at 6:09 PM, Nial Peters <nonbiostudent@xxxxxxxxxxx>
wrote:

Hi,

This may be irrelevant to your problem, but some years ago when I was
using Aravis with a FLIR SC645 thermal camera I found that occasionally a
frame would take a huge amount of time to transfer compared to normal. It
turned out to be due to packet resend requests. As soon as a packet was
dropped and Aravis requested a resend, the camera seemed unable to cope,
sometimes freezing completely and needing to be reset. I found that
disabling packet resend requests in Aravis resulted in a more reliable
throughput, as long as you can cope with a frame being occasionally lost.
I'm not sure how you do this with the Python interface (and I may also be
well out of date with the current Aravis release) but in C it was using

*g_object_set(camera->stream, "packet-resend",
ARV_GV_STREAM_PACKET_RESEND_NEVER, NULL) *As I said, this didn't happen
very often, so perhaps it is possible that for small value of numFrames you
don't see this problem, but for larger numbers it is occurring for one or
two frames and slowing things down? You could easily test this by recording
the time taken to retrieve each frame and see if it is just a few frames
that are slowing things down or whether there is an overall reduction in
throughput for large numFrames values.

Cheers,
Nial



On 21/12/17 10:12, Emmanuel Pacaud wrote:

Hi,
Hi,

Le ven. 15 déc. 2017 à 14:52, Saurabh Chatterjee <saurabhsaurc@xxxxxxxxx>
<saurabhsaurc@xxxxxxxxx> a écrit :

For a low value of numFrames ( say 100 ), I get frame rate of 60
For high values ( say 600+ ), the frame rate goes down to about 25 or so..

any idea why that might be happening?


Did you check the CPU and memory consumption of your software ?

How did you setup the acquistion framerate ?

    Cheers,

        Emmanuel.






--
Saurabh Chatterjee
Phd, Aerospace Engineering
Indian Institute of Space Science and Technology, Thiruvananthapuram




-- 
Saurabh Chatterjee
Phd, Aerospace Engineering
Indian Institute of Space Science and Technology, Thiruvananthapuram

Other related posts: