[IGSTK-Developers] Accessing ITK image

[Julien Jomier]

Hi Patrick,

I see your point now (I blame the end of the week and lack of coffee 
;)). The modifications sound good to me.
Maybe static_cast<MasterConstSafety>(Luis) has something to say about this.

Have a good weekend,

Julien

Patrick Cheng wrote:
> 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
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>