Hi Klaus, Apologies for the delayed reply. We are aware that there are still some issues with rendering large datasets (e.g. program aborts under Windows), and your report (black window/memory leakage) adds to this. We'll have a look at this for the next MITK release (due in a couple of weeks).
> 3. When I click the left mouse button in a 2D window, then it is like I > clicked it in the 3D window. The quality gets worse and as soon as I > release the mouse button it is rendered in high quality again. Seems to > be unnecessary (it just slows down everything). This re-rendering occurs since when clicking into a 2D window, the 2D planes are moved accordingly. Since these planes are (by default) also displayed in the 3D window, it becomes invalidated and has to be rendered again (the planes should move also in 3D). The behavior of sequentially switching from low resolution to high resolution is due to the Level-of-Detail (LOD) mechanism for volume rendering: the low quality "preview" image is rendered fairly quickly, and the high resolution volume is rendered later on, when the user stops interacting. > 4. I am using a debug toolkit chain (vtk, itk, qt3, mitk, everything is > compiled as shared) and it took 2:45 minutes to render the volume. Even > in the release version it takes very much time. > Some time ago, I implemented a small example just using vtk, itk and > wxwidgets to load a volume and to render it and it was never that slow. > So why is this function in mitk/mainapp that slow? What happens under > the hood? (I noticed for example, that a copy of the volume is made) This is probably due to the configuration of the volume rendering used by MITK. The high-res mapper of the LOD approach (you can have a look at its implementation in mitkVolumeDataVtkMapper3D) uses rather small sample distances, making the overall quality better, but the rendering slower. In the current version VTK also supports a 3D texture based volume renderer, but it its implementation is still rudimentary (as compared to state-of-the-art approaches) and is therefore not yet utilized by MITK. Regards, Mathias ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ mitk-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mitk-users
