[IGSTK-Developers] Accessing ITK image

[Patrick Cheng]

That sounds good, actually I tried to use the event/observer in the 
friend class, it's much harder and complicated than I imaged it would be.

Patrick

Luis Ibanez wrote:
> Hi Julien, Patrick,
> 
> After looking at the current mechanism for getting images out
> of the ImageSpatialObject, I agree with both of you that the
> implementation is not scalable.
> 
> Considering that Julien recently improved the class in order
> to return the ITK image as an event with payload, the need
> for a private implemenation of the Request is less important.
> Most of the safety is no granted by the fact that the request
> passes first through the State Machine.
> 
> It seems that the way to go here is to have a make the Request
> method public, and add a similar one for the VTK images. In this
> way, external classes will be able to gain access to the internal
> ITK and VTK image representation, but only after passing through
> the forced verification of the StateMachine.
> 
> I'm making those changes in the IGSTK/Source directory in the
> sandbox.
> 
> 
> 
>    Luis
> 
> 
> 
> ---------------------
> Julien Jomier wrote:
>> 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
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
> 
> 
> 
>