[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