Optimal US FPS

[tdowrick]

In GitLab by @ThomasDowrick on Aug 6, 2019, 11:05

See video for US running at 8FPS with minimal delay. The version of sksurgerybk I used for this is tagged as v0.3.4 / good_fps. I have made some additional notes that I will add later on.

good_fps_us.flv

[tdowrick]

In GitLab by @ThomasDowrick on Aug 6, 2019, 15:02

BK Capture only
Reading data from the BK and displaying with OpenCV can give ~30fps.

Random numpy data -> pyIGTLink -> Slicer 4.8(No PLUS)
I ran surgerybk/pyIGTLink just sending random numpy arrays (640 x 480 grayscale), rather than streaming data from the BK.

In this instance the absolute max fps reported by the Node Modified Statistics module was ~16fps, when the incoming image data wasn't being displayed on screen.

Turning on the image display dropped the fps slightly, to 13-15fps. Rendering the US image in the R, G and B windows simultaneously has the greatest slowdown. If only the R window is shown, the slowdown is minimal. This is likely related to the rendering issues that we are already aware of, that have been address in Slicer 4.10.

The fps deteriorates as the size of the array being sent is increased When I tried with a 640 x 480 x 3 RGB array, performance was ~5fps. This suggests that creating/sending the IGTLink Image message type is causing some delay, but I didn't do enough to check this conclusively.

BK -> pyIGTLink -> PLUS -> Slicer 4.8
I was running v0.3.4/good_fps with config file PlusDeviceSet_Server_StealthLinkTracker_pyIGTLink_Image_Calibration.xml to get good perfomance at 8 fps.

8 fps, with no/minimal delay, is sufficent to proceed, but it is not clear what is causing the difference between 8fps here and the 16fps maximum with pyIGTLink.

[tdowrick]

In GitLab by @DavidPerez-Suarez on Aug 6, 2019, 15:27

Thanks @ThomasDowrick!!

I am assuming, but I may be wrong, that the US images are grayscale. What is their size? could we, for comparison purposes, run the tests above with the same size than the random np array? I would say, get the array the same shape and size than the US, so we can make sure we are comparing the same and it's realistic.

Also, the alienware has slicer 4.10 installed in case you can/want to check.

[tdowrick]

In GitLab by @MattClarkson on Aug 7, 2019, 05:45

@JonathanShapey - do you ever need Doppler?

@ThomasDowrick / @DavidPerez-Suarez - normal B-mode should be greyscale, we only need RGB for doppler. So, if Jonathan says "no", then it would be good to switch to greyscale.

[tdowrick]

In GitLab by @JonathanShapey on Aug 7, 2019, 07:40

@MattClarkson Yes, we use Doppler in neurosurgery- most commonly in neurovascular surgery but also in cases where you want to check the location of large important blood vessels (e.g. anterior endoscopic skull base surgery to check the placement of the carotid artery). However, in lateral skull base surgery (i.e. the current application of the SBN project) Doppler is not routinely used.

[tdowrick]

In GitLab by @JonathanShapey on Aug 7, 2019, 07:41

@ThomasDowrick @DavidPerez-Suarez I agree with @MattClarkson that for this application normal B-mode should be in greyscale

[tdowrick]

In GitLab by @ThomasDowrick on Aug 7, 2019, 11:09

I had the same thought about greyscale, but I checked and it is already sending greyscale.

I don't have the SBN laptop with me, but I tested on my own Alienware laptop, and increasing the array size of the mocked data does have some affect on the fps. It starts off at ~30fps @ 640x480 and drops to ~25fps @ 870x560 (roughly the US size). I guess my laptop may be more powerful (but can't say for certain), hence why the fps is higher than on the SBN laptop.

I tagged 'test-fps-local-data' if anyone is able to run the comparison on the SBN laptop.