[Insight-users] Application walk through

[Luis Ibanez]

Hi Neil,

Please see comments below,

Regards

Luis

---------------------------------------
Neil Killeen wrote:
>
> What we are building is a medical analysis platform which will
> probably use itk/vtk/fltk as its main toolkit components.  My idea was to
> use ITK to do all file handling and analysis, passing the image
> along to VTK for display.   Thus, even if the user *only* wanted
> to display an image, it would still go via ITK for the file
> handling (so that we have just one interface layer) and then
> pass it to VTK.
> 
> Because it's a template paramater, I can't even have
> the user specify the dimensionaltity in the UI or
> pre-fish it out of the file.  It has to be hard wired into the
> code, which I find bad.
> 
 >

In a medical application, the file you are
managing contains information for maintining
a living person... alive. Forcing your application
(and you as developer) to be aware of dimensionality
and pixel types is a contribution for acomplishing
the purpose of the application.

I doubt that in a real medical application you will
apply the same same kind of processing to a 2D image
than a 3D image or a 4D one, unless your application
is *really* generic and is only doing photoshopish-kind
f processing on the images (e.g. blurring, mirroing,
intensity transforms and so on).

I would suggest you invest a bit of time on top-level
design of your application. Any UML type of practice
will help on this. You will probably discover that the
pipeline suitable for 2D medical images is not necessarily
the same that the one for 3D or 4D. This goes both for
image processing with ITK and for visualization with VTK.

>
> Do you know of a way to work around this in ITK ?    I desperately
> want avoid re-writing file-handling s/w !!!   Perhaps I should
> use VTK file handling (I assume there is some, but don't know
> about it yet) and then filter the other way to ITK and then back again ?
> 
> 

I agree with you. File handling is painful.
The good news is that it is already done both
in ITK and VTK. What you will have to design is
the appropiate GUI interface that will take the
best from the existing support in both toolkits.
It comes down to the simple fact that instead
of having one generic menu option: "Open File"
you may have options:

   "Open MRI volume"
   "Open CT volume"
   "Open Fluoroscopy"

In the places where this types of images are
processed. I would insist in that you don't
treat a fluroscopic image in the same way
you manage one slice of MRI. So, independent
pipelines will be required for different
applications.


> 
> I thought you would probably say that...   Could the docs.
> of ImageFIleReader point you at the  appropriate place (not
> an ideal  solution IMO either) ?
> 
> 

The SoftwareGuide will hopefully contribute to
aleviate the need for documentation.


> 
> 1) well maybe it does, but surely the interfaces for the classes have to
> be self describing and not depend upon external documents to
> which the classes do not point and which many  people don't
> know exist.
> 
> Should you not define the interface in the appropriate base class,
> and then if any of the methods are overwritten, each specific
> class describes its interface ?
> 
> 


A large part of the documentation is generated by Macros.
The official reference documentation of ITK are the
Doxygen web pages. If you read the header files directly
this will look quite different from the final HTML pages.

Repeating the documentation of base classed on all the
derived classes is an options of Doxygen. You may want
to build your own set of HTML (or latex, or rtf) pages.
Just enable in CMake "BUILD_DOCUMENTATION" and then
run doxygen using the doxigen configuration file generated
by CMake.


>
> but I don't have a User directory in my tree.  What is  the directory
> 
> ./SoftwareGuide !
> 

Well,
it is were the "SoftwareGuide" is   :-)

A lot of Latex pages, CMake configuration files
JPEG,EPS images, Xfig figures, GNUplot scripts
perl scripts, and VTK Tcl script.

You will be surprise to see how fun is to write
documentation  :-)

> 
> as well as a variety of ppt files in the Training section.
> Wow you folks  have  written a lot of stuff !
> 
 >

Yeap, we have been busy...

The SoftwareGuide will be out there soon. It integrates
a good part of the documentation in InsightDocuments.

Please take into account that InsightDocuments is not
just documentation for the toolkit. It is the administrative
history of the project. You may find in there the minutes
of our meetings.


 >
 > So you find some
> function and its output is some dreadful typedef expression,
> but there is no link to take you to that typedef so you
> can find out what the reality is.  I can't drink
> more coffee or I will look like a coffee bean !
> 

You may find interesting to use "SourceNavigator"
This is the right tool for exploring code.
You can download it for free from RedHat.


>>
>>Image are not actually passed from one filter to another.
>>
>>in
>>
>>A  --->  B ---- > C
>>
>>the output image of filter A stays with A.
>>B "read" this image and use the data to compute
>>the values it puts in its own output image.
>>B's output image is an entity completly independent
>>of A's output image.  Then C reads B's output image
>>and use the data to compute the values of C's
>>outtput image.
>>
>>
> 
> ok.  so you get quite a lot of images stored in memory this way
> (they are in memory, right ?).
> 


Yes, they are in memory
Yes, they take space
but in that way, when you need to update, only
the minimum work required is performed.

It is the balance of life, you trade time for space


> i was envisaging one shared image in the pipeline somehow.
> i suppose since medical images are generally small (or at least,
> lagging behind the available resource in a state of the art
> computer) that this has not been an issue ?  Also you can destroy filters
> along the way to free up resources if need be I guess.
>
"small" is relative.
A typical volume is about 20Mb
A fluoroscpic image is about 1Mb
Some modalities for mouse imaging generate 2Gb data sets

The requirement of ITK specify that we should be able
to process in a 512Mb machine.