[IGSTK-Developers] ImageReader/ImageSpatialObject/ImageSpatialObjectRepresentation

[Frank Lindseth]

Hi everybody,

Some questions / comments  regarding the CT/MR/US-ImageReader, the CT/ 
MR/US-ImageSpatialObject (???USImageObject???) and the CT/MR/US- 
ImageSpatialObjectRepresentation:

Background:
In the name of safety there exists special versions (CT/MR/US) of all  
these classes.
In a typical neurosurgical case for example, both pre. op. CT and MR  
can be used (sometimes just MR, sometimes just CT and sometimes both  
modalities).

1) Regarding the intended use of the CT/MR/US-ImageReader:
- Is the app. user supposed to know the modality of the DICOM data he/ 
she tries to open  (the app. developer supplies two menu choices:  
OpenMR and OpenCT) ?
- If the user do not have to know in advance (a reasonable  
requirement), should the app. developer first try, lets say a  
MRImageReader, and if an error of the right type is generated, try  
CTImageReader, etc.?
- ???
A humble suggestion from the Trondheim group: Let the user open  
whatever he wants, read the first DICOM file, find the right modality  
from the header, if the found modality correspond to one of the  
supported IGSTK-readers, instantiate the special DICOM reader (CT/MR/ 
etc.) and load the image data, if not (or if the modality-tag is  
missing) generate the appropriate error event (all encapsulated in an  
DICOMImageReader, easy for the user, easy for the app. developer, and  
as safe as you get it...)

2) Is it really necessary to have special versions of the  
ImageSpatialObjectRepresentation (in terms of slicing it shouldn't  
matter whether you work with a MR or CT volume)? This is perfectly ok  
as long as you work with a SINGLE volume but if you work with  
multiple volumes from different modalities the app. code will not  
look very nice (there will be a couple of if-statements in such a  
app. for example....). In order to make multimodal-imaging/viz.   
work, at some point CT/MR/US data must be regarded as just a voxel- 
cube, otherwise everything will become to complicated.  It's a good  
time to start to thing of the data in this way, after the volumes  
have been read into the system

3) It takes some time to load a large DICOM data set, so it would be  
nice to have a progress bar, is there a way to have update events  
pass the IGSTK-layer so that they can drive the progress bar?

4) Non of our data looks good using the components above (+View2D) in  
the standard way . How is the default  window with/center set? DICOM  
header, Voxel content analysis, etc.? When the level/center is  
changed the data looks ok, and the user should of course be allowed  
to change these parameters, but shouldn't the default values be close  
to ok?

Regards,
Frank