[IGSTK-Developers] "many simple specialized" componentsvs. "fewer, more complex and general components"

[Luis Ibanez]

Hi Frank:


Frank Lindseth wrote:
...
> 
> I like to end with a very concrete issue:
> I'm convinced that the modality specialization of the ImageSpatialObject 
> and ImageSliceRep. comp. should be removed (spec. of ImageReader could 
> be justified). This specialization adds little or nothing in terms 
> overall safety, and it causes a lot of problems on the app. level for 
> all realistic IGS app.:
> http://public.kitware.com/IGSTKWIKI/index.php/DesignChallenges#Things_that_comes_to_our_attention_as_we_work_along
> http://public.kitware.com/IGSTKWIKI/index.php/Talk:DesignChallenges#Thing_that_came_along
> 


Sure,


Only one changes is needed in the Reader:


In line 90 of itkDICOMImageReader.h  replace

      igstkStandardTemplatedAbstractClassTraitsMacro

with

       igstkStandardClassTraitsMacro

that will add the New() method to the DICOMImageReader


With this change, you should be able to instantiate the
reader, image spatial object, and image representation
classes.


Note however, that you still have to deal with the issue
of defining a variety of pixel types at compile time. A
good solution to that problem is given in the paper that
Andinet posted to the Insight Journal:


     http://insight-journal.org/dspace/handle/1926/495
"Seamless VTK-ITK pipeline connection for image data handling"


---

I would suggest, however, to keep the image modality specialized
versions {CT, US, MRI} for those who want to use them in order to
constrain the use of specific applications.



   Regards,


       Luis