Hi Peter,
Thanks for your answer. I work with the main author of the
FiberNavigator. (In fact, we all met in Sherbrooke last year) We decided
to create FNav 2.0 because the first project has become really hard to
manage. It's fast, but it's coded using old technologies, direct opengl
calls and thousands lines of code. We tested MITK as a framework to
recreate FNav and we had huge performance problems. The more I test, the
more I think that modifying the mappers and avoiding update is the key.
I have a question for you. We add a boundingbox with an interactor in
the scene. Each time we move it, it calls Update(). This is quite slow
when you use a big dataset. We replaced the 2D mapper with a mock mapper
(doing nothing) and everything was ok. I guess this Update is important.
Redrawing only the bounding box is probably not enough, because we also
need to redraw what was behind? Would it be possible to refresh only the
bounding box and stop the Update() process? What would happen if I do that?
Also, I'm not really a OpenGL/MITK connoisseur, so I don't know if it's
possible to do that... With the 2D and 3D views, we are in fact looking
at the same data, in a different perspective. When we visualize a
FiberBundleX, the 3D mapper draws everything (glVertex3f, etc.) then
each 2D mapper takes a polydata slice and draws it. We are sending the
complete dataset + 3 slices of it. Would it be possible to send the
complete dataset one time, then ask each 2D views to apply a geometry
shader on the data that's already there? The shader would keep only the
vertices from zMin to zMax for Axial, xMin to xMax for Sagittal and
yMin, yMax for Coronal.
Thanks for your time.
Le 2014-08-11 03:37, Peter Neher a écrit :
Hi Nil,
sorry for the late reply! Indeed you are right. Handling such big
fiber bundles is an issue in MITK. In the last month I started to feel
these issues myself since the fiber files I am handling seem to grow
constantly :) I guess we will have to rework the whole fiber
representation in MITK to tackle this issue. The MITK fiber format is
basically an vtkPolyData and we are using the corresponding
vtkPolyDataMapper to get everything on screen but it seems this is not
the way to go for such big files. It would be interesting to see how
the FiberNav guys approached this task.
Regarding the unnecessary rendering refreshs of MITK, I will look into
that. Maybe we can tweak something there.
Again, sorry for the late reply. In general if you have issues
regarding fibers and tracking in MITK you can also include me directly
when sending an email to the users list. Then it's harder for me to
miss it.
Cheers
Peter
On 18.07.2014 22:43, Nil Goyette wrote:
Hi all, I tested loading a .trk file in MITK. My first test was a
500k fibers file and I got a allocation error. My second test was
with a 150k fibers files. I saw the Axial slice appear, waiting 5
minutes and it was still searching. I then tested a vtp file with
150k fibers (around 12 millions points). It loads fast enough (about
6 seconds), but each time I move the crosshair, it takes 5 seconds or
more to refresh. When I move in the 3D view, it's sometime really
fast (more than the FiberNav), sometime absolutely slow. I also had
problem with the window refresh. When I open the TaskManager, MITK
constantly try to refresh the 4view,.
I know I don't have the best computer around, but it was working
using the Fiber Navigator (a well known tool in the field). I tried
with a better computer and I had mixed results, it was ok 1 time out
of 3, randomly.
Is MITK built to handle such a big load? Can a user hopes to achieve
performance on par with the Fiber Navigator?
Thanks for your time.
--
Logo Imeka <http://imeka.ca/> Nil Goyette, M.Sc.
www.imeka.ca <http://imeka.ca/>
------------------------------------------------------------------------------
_______________________________________________
mitk-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mitk-users
