[IGSTK-Developers] Accessing ITK image

[Patrick Cheng]

I don't think there is a need to modify the ImageSpatialObjectToITKImage 
helper class.

The friend declaration is one way thing. Define the helper class as a 
friend of new class is enough(let the helper class access new class's 
protected member and functions). We don't need to declare the new class 
as a friend of the helper class.


Julien Jomier wrote:
> 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
>>>>
>>>
>>>
>>>
>>
> 
> 
>