Page MenuHomePhabricator

2D Streaming in mitkWorkbench/BlueBerry (?)
Closed, ResolvedPublic


Since I have been working with the workbench, the 2D rendering of (video) streams is relatively slow. In the workbench framerates between 5 and 15 FPS are common and often not acceptable. I am not sure about the component of this bug. It might change when I learn more.

Here is what I know so far:
-Reproducible with MITK-ToF, which replaces the data of an mitkImage (1 slice) constantly via a ToF-Camera
-Reproducible with MITK-US, which replaces the data of an mitkImage (1 slice) constantly via a WebCam or an US-device (both Linux and Windows)

> The pipeline how to generate the data does not matter (much) and it is not OS related

I wrote the following test applications:
a. Viewer app creating N mitkRenderWindows and streaming data.
b. Viewer app creating N QmitkRenderWindows and streaming data.
c. Viewer app creating N QmitkRenderWindows and streaming data with BlueBerry.
d. A RenderWindow added to the mitkWorkbench.

For testing purposes I used a 640x480 RGB stream. The framerates (FPS) for 1 Renderwindow are for the Apps 1.-4.:
a. 40, b. 40, c. 20, d. 10

> The Mitk Rendering seems to be reasonable fast for at least a single QmitkRenderwindow. Currently, BlueBerry or something that comes with it seems to have a huge impact.

The Framerates drop a lot for 4 Renderwindows:
a. 12, b. 10, c. 5, d. 4

> Rendering in multiple Renderwindows has a huge impact.

Since the QtEvent pipeline is assumed to influence the performance, I tried to remove all interaction from renderwindows by adding and empty event method to the QmitkRenderWindow like this:
protected: bool event( QEvent* /*e*/ ) {return false;}

This disables all interaction with renderwindows, but does not significantly increase the framerate (+2 FPS in the App d.).

> QtEvent pipeline seems to have no major impact.

I also did some profiling on the workbench without major insights. The profiler mainly reveals endless class of VTKs rendering methods which seems to be correct.

Event Timeline

To measure the FPS, I always used this code snipped:

vtkSmartPointer<vtkTimerLog> timer = vtkSmartPointer<vtkTimerLog>::New();
int i = 0;
while(i < 100)


MITK_INFO << "100 frames rendert in (seconds): "<< timer->GetElapsedTime();
MITK_INFO << "FPS: "<< 100 / timer->GetElapsedTime();

The Apps are pushed into:

The code is not well organized. Contact me if you want to reproduce this.

Closed. I explained all my findings to the MITK group on the last retreat.

kirchnth claimed this task.

This has been closed years ago - not sure why it has been reopened.