Hi Matt,
Finally, please find my comments below.
Best,
Sascha
On 06/03/2011 03:20 PM, Matt Clarkson wrote:
So far so good. However, my requirements are
3). to have potentially many different views (orientation,
magnification, slice numbers, intensity ranges, lookup tables), of
different images.
4). to have different images visible in different views. Imagine you
have 3 images. You have a fixed image, and 2 moving/floating images,
which have been registered and resampled by two algorithms into the
space of the fixed image, and you want to compare "which one is best".
So, imagine you have 2 columns in the main view. In the left column
you want to display the fixed image, and 1 resampled image, and in the
right column you want to display the fixed image and the other
resampled image. You then want a single button click to toggle BOTH
views simultaneously.
Given your requirements I would suggest you to have a look at the
QmitkStdMultiWidget class itself. What it actually does is to manage a
set of QmitkRenderWindow instances and link them together. The actual
rendering and event processing part is contained in QmitkRenderWindow
(or in its base classes). Since you need to support more flexible
layouts, linking, and visibility scenarios, you will probably have to
write your own "QmitkStdMultiWidget" class.
Also, if I look at the code, each functionality appears to reference
QmitkStdMultiWidget explicitly. It seems to me that I would require a
Display window with a completely different widget (or widget
containing many other widgets). However, If the functionality's all
explicitly reference QmitkStdMultiWidget, then I would have to extend
this class (via inheritance, and inject a child class in place, or add
functionality to QmitkStdMultiWidget, thereby possibly changing the
interface, or use Decorators or something). It seems that there
should be a way to have significantly different types of views, but I
can't quite see where to do this.
Your analysis is completely correct. The QmitkStdMultiWidget class is
referenced too often and in many cases an alternative, more modular
approach would be better suited. This has partially historical reasons.
I would refrain from inheriting from QmitkStdMultiWidget since it is not
really designed to be sub-classed (none of its methods are virtual).
Somewhere, I must be missing a link. For example, Bundles such as the
PointSetInteraction, simply add points to the Data store, (the Model),
so it doesn't matter which widget is viewing the data. This Bundle
must be View/Widget agnostic. Whereas clearly, Bundles like the Image
Navigator, you would expect to be tied to the QmitkStdMultiWidget as
it specifically controls 3 orthogonal planes.
Right. There are some bundles which are tied more to QmitkStdMultiWidget
than others (in theory). Unfortunately, the base class
(QmitkFunctionality) which most of the views use which are contributed
to the BlueBerry workbench by our bundles, is itself referencing
QmitkStdMultiWidget directly. However, you don't have to inherit it.
Currently, we are redesigning the way we access singletons in the MITK
core library and the new solution will also allow for a more modular way
to access registered instances of certain classes (think of a simplified
OSGi service model). This will make it easier to get some instances
(controller classes) in a generic way instead of querying the current
QmitkStdMultiWidget instance.
So, questions are:
5.) How do I have a main viewing area, which can have up to 25
completely independent views? showing different images, slices,
orientations, magnification factors. (intensity range, and lookup
table can still be stored with the image, and consistent across
views). Would I create my own 5x5 multi widget?
Yes, I would suggest to create your own QWidget subclass which uses
QmitkRenderWindow instances, maybe similar to QmitkStdMultiWidget. Start
simple and embed this widget in a BlueBerry Editor (have a look at the
QmitkStdMultiWidgetEditor class).
6.) How do I control it? Would I end up, starting with a base class
of a completely different Functionality that was NOT dependent on
QmitkStdMultiWidget. For example, if I wanted a widget to control
slice/magnification/orientation, it wouldn't be very applicable to
QmitkStdMultiWidget, so would it just have to connect to my specific
5x5 multi-widget? If so, you need to know which of the views you are
updating.
Yes, for your view you would inherit from berry::QtViewPart (some views
in MITK which don't need the convenience methods in QmitkFunctionality
also do this). To not make the same mistake as existing MITK views do,
you could verify that your editor is visible (by using BlueBerry
specific API) and then search for your BaseRenderer instance (or
vtkRenderWindow) by using a name lookup:
vtkRendererWindow* myRenderWindow =
mitk::BaseRenderer::GetRenderWindowByName("MyRenderWindow");
and for example use mitk::RenderingManager::RequestUpate(myRenderWindow)
to request a rendering update for a specific window. Have a look at the
API of mitk::BaseRenderer and associated classes.
For viewing a different set of data in different render windows, use
render window specific properties on mitk::DataNode instances. This way
you still have one universe of data (one mitk::DataStorage) but control
their appearance by setting mitk::BaseRenderer specific
mitk::BaseProperty instances.
7.) Would I end up with a completely different perspective, using a
completely different view widget, with completely different controls
to the rest of MITK. If so, should I use MITK? I still think the
BlueBerry Application framework, and having a consistent universe of
data that could be visible in either the QmitkStdMultiWidget, or my
5x5 one would be useful in itself. But I need to know how much code I
could use from MITK as is, and how much MITK-style code I would be
writing myself.
I think MITK as a class library together with BlueBerry still has a lot
of benefits in your case. You should be able to use all of the MITK
rendering classes in your custom multi-widget and benefit from the
global data storage and its data-node base property system. What you
would need to write is the logic to link your render windows and keep
their state consistent (as the QmitkStdMultiWidget does). But all the
controller classes (for example for controlling the camera or slicing
planes) should be usable out of the box.
If you think about reusing for example the segmentation bundle, we
should think about modifying it such that it does not reference the
QmitkStdMultiWidget explicitly.
Writing your own perspective could be viewed as "cosmetics" and done in
the end, when you figured out how to solve the hard problems :-)
Thanks ever so much for listening.
Any advice would be appreciated.
Matt
I hope this helps and please keep asking!
Best,
Sascha
------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
mitk-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mitk-users
