[IGSTK-Developers] Accessing ITK image

[Luis Ibanez]

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
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
> 
> 
>