[IGSTK-Developers] Accessing ITK image

Julien Jomier julien.jomier at kitware.com
Fri May 5 17:16:21 EDT 2006


Patrick,

What you are proposing looks fine but the "user" will still have to 
modify the ImageSpatialObjectToITKImage class file to add a friend macro 
of his class (which is perfectly fine).
I don't think declaring the ImageSpatialObjectToITKImage has a friend 
only in the new class would work.

Also, with the current code, you don't even have to add any friend 
keyword because the function GetITKImage() is public. I think we want to 
make it at least protected and force the "user" to add the friend macro 
at some point.

Julien

Patrick Cheng wrote:
> Thanks Julien and Luis,
> 
> I don't think modifying the base class is a good idea. Different 
> application developer are developing different class using ITK images, 
> maybe segmentation, or registration. If they all ended up adding a line 
> or two in the base class, this will look very messy.
> 
> What we need is helper class, maybe called ImageSpatialObjectToITKImage
> 
> This requires the receptor class has defined a ITKImageType, and a 
> RequestSetITKImage() fuction.
> 
> I think this is a better way than modifying the base class. You only 
> need to declare this class as a friend in your new registration class, 
> and call the GetITKImage(igstkImageSpatialObject, your_new_class) later 
> in your code.
> 
> Let me know what do you guys think of this solution.
> 
> Patrick
> 
> 
> 
> class ImageSpatialObjectToITKImage
> {
> public:
> 
>   template < class TImageSpatialObject, class TITKImageReceptor >
>   static void
>   GetITKImage( const TImageSpatialObject * imageSO,
>                       TITKImageReceptor   * receptor )
>     {
>     //We need to setup the observer to catch the event here
>     igstkObserverConstObjectMacro( ITKImage,
>                              TImageSpatialObject::ITKImageModifiedEvent,
>                              TITKImageReceptor::ITKImageType)
> 
>     ITKImageObserver::Pointer itkImageObserver = TKImageObserver::New();
> 
>     imageSO->AddObserver( ImageSOType::ITKImageModifiedEvent(),
>                           itkImageObserver);
> 
>     imageSO->RequestGetITKImage(); //this will trigger an event
> 
>     if( itkImageObserver->GotITKImage() )
>       {
>       receptor->RequestSetITKImage( itkImageObserver->GetITKImage() );
>       }
>     // some error handling code
> 
> };
> 
> Julien Jomier wrote:
>> I don't think adding a private shared class will improve the current 
>> design. The current implementation should be ok.
>>
>> As Luis is saying if a user is implementing new classes in IGSTK then 
>> he should be considered as a developer and therefore adding one (or 
>> two) lines in the base classes is fine.
>>
>> Julien
>>
>> Luis Ibanez wrote:
>>>
>>> Hi Patrick,
>>>
>>> The solution is already illustrated in the interface between the
>>> ImageSpatialObjectRepresentationClass and the ImageSpatialObject.
>>>
>>> A private friend class can act as an intermediary to make possible
>>> to pass the itkImage from the ImageSpatialObject to the Registration
>>> class, without having to expose the itk Image in the public API
>>> of the ImageSpatialObject.
>>>
>>> Note that when you refer to a "user" that is writing her/his own
>>> registration class, this is actually "extending IGSTK" and therefore
>>> the new code should be subject to the same software development process
>>> as the rest of IGSTK. Exposing ITK or VTK classes in the public API
>>> will sacrifice all the safety that has been the concern of IGSTK so far.
>>>
>>>
>>> Please let me know if you find any difficulty in setting this same
>>> infrastructure for the registration class, I will be happy to help
>>> you with the code.
>>>
>>>
>>>    Thanks
>>>
>>>
>>>       Luis
>>>
>>>
>>>
>>> ======================
>>> Patrick Cheng wrote:
>>>> Hi everyone,
>>>>
>>>> For the new demo application, the registration class need to get 
>>>> access to the ITK image, so that it can segment out the fiducial 
>>>> points. Other ImageToImage registration also requires access to the 
>>>> ITK image too.
>>>>
>>>> This posts a problem to the igstkImageSpatialObject class, if the 
>>>> user need to use their own registration class, they need to modify 
>>>> the igstkImageSpatialObject class and declare their registration 
>>>> class to be a friend class.
>>>>
>>>> Is there a better solution to this problem?
>>>>
>>>> Patrick
>>>> _______________________________________________
>>>> IGSTK-Developers mailing list
>>>> IGSTK-Developers at public.kitware.com
>>>> http://public.kitware.com/cgi-bin/mailman/listinfo/igstk-developers
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> IGSTK-Developers mailing list
>>> IGSTK-Developers at public.kitware.com
>>> http://public.kitware.com/cgi-bin/mailman/listinfo/igstk-developers
>>>
>>
>>
>>
> 




More information about the IGSTK-Developers mailing list