[IGSTK-Developers] Hi, question about ImageSpatialObjectRepresentation code

Hui Zhang zhang at isis.imac.georgetown.edu
Thu Nov 17 16:27:18 EST 2005


Hi, Luis,

We are thinking about to integrate orthogonal, oblique and slab-MIP image
representation into one 2D image representation class. For all those three
 image represenations handle extracting 2D slice(s) from 3d image data like
 those:
Orthogonal: 2d slice in three specific directions,
oblique: 2d slice in the arbitary direction,
slab-MIP: multi parallel slices in the arbitary direction, but will project
to one 2d slice,

 So there are a lot of commons between them, they may be derived from one
 basic class or have some close hierarchy relationship.

 Oblique -> Orthogonal
        -> slab-MIP

 David has a new vtk class and will contribute to vtk cvs. So by using that
 class, this structure can be implemented by the pipeline:

 vtkImageReslice -> vtkImageProjection, with vtkImageActor.

 Those three image representations may still belong to 2D image
 representation category, for that vtkImageProjection take a bit different
 computation than real volume rendering category, and the result will be
 projected and displayed to a 2D slice finally.

 In the 3D image representation, they may have different representations
 like:

 RayCastingRepresentation, including alpha bleding, MIP, NIP,
SurfaceRepresentation, derived from iso-surface extraction algorithms,
TextureMappingRepresentation, powered by GPU rendering from VTK.
...

Regards,
James


> ----- Original Message ----- 
> From: "Luis Ibanez" <luis.ibanez at kitware.com>
> To: "Hui Zhang" <zhang at isis.imac.georgetown.edu>
> Cc: "'IGSTK-developers'" <igstk-developers at public.kitware.com>
> Sent: Wednesday, November 16, 2005 9:17 AM
> Subject: Re: [IGSTK-Developers] Hi, question about 
> ImageSpatialObjectRepresentation code
>
>
>>
>> Hi James,
>>
>> You are right,
>>
>> We need another, and probably many other more
>> variations of the Image Representation class.
>>
>> That's part of the reason why the Representation
>> was separated from the actual content of the image.
>>
>>
>> We could anticipate to have:
>>
>> 1) Oblique Image Representation class
>> 2) MIP     Image Representation class
>> 3) Volume Rendering Image Representation class
>>
>>
>> among others.
>>
>>
>>
>>  Luis
>>
>>
>>
>> -----------------
>> Hui Zhang wrote:
>>
>>>> Hi,
>>>>
>>>> I check the current ImageSpatialObject /
>>>> ImageSpatialObjectRepresentation code from IGSTK and find it is easy to
>>>> use this class to display the 2D slice image from Axial / Sagittal /
>>>> Coronal view. The code use the vtkImageActor to set the orientation and
>>>> slice number, as below:
>>>>
>>>> switch( m_Orientation )
>>>>     {
>>>>     case Axial:
>>>>       m_ImageActor->SetDisplayExtent( ext[0], ext[1], ext[2], ext[3],
>>>> m_SliceNumber, m_SliceNumber );
>>>>       break;
>>>>     case Sagittal:
>>>>       m_ImageActor->SetDisplayExtent( m_SliceNumber, m_SliceNumber,
>>>> ext[2], ext[3], ext[4], ext[5] );
>>>>       break;
>>>>     case Coronal:
>>>>       m_ImageActor->SetDisplayExtent( ext[0], ext[1], m_SliceNumber,
>>>> m_SliceNumber, ext[4], ext[5] );
>>>>       break;
>>>>     }
>>>>
>>>> My question is, through this category, we can't display any oblique
>>>> image slice and integrate them into the same class. If the surgeons 
>>>> need
>>>> get oblique view along the planned path or tracked tool, or even
>>>> slab-MIP view, the program can't make any use of the existed
>>>> ImageSpatialObjectRepresentation class. That means, we'll have two
>>>> different ImageRepresenation classes, one for the fixed-axis, and one
>>>> for the oblique axis. What we did before in our current navigation
>>>> system is, we use vtkImageReslice instead of vtkImageActor, and made 
>>>> the
>>>> orthogonal image representations (Axial / Coronal / Sagittal) are three
>>>> specific oblique views. So, in my question, can we implement with
>>>> vtkImageReslice in ImageSpatialObjectRepresentation class, instead of
>>>> vtkImageActor? And from this implementation, the orthogonal image
>>>> representation can be easily a derived class or just three specific
>>>> settings.
>>>>
>>>> Regards,
>>>>
>>>>
>> ---------------------------------------------------------------------------------------------
>>>> Hui (James) Zhang, Ph.D.
>>>>
>>>> Imaging Science and Information Systems (ISIS) Center
>>>> Department of Radiology
>>>> Georgetown University Medical Center
>>>> 2115 Wisconsin Avenue, Suite 603
>>>> Washington, DC, 20007
>>>>
>>>> Work phone: 202-687-2902
>>>> Work fax: 202-784-3479
>>>> Cell phone: 240-476-9361
>>>> MSN: zh_skyfox at hotmail.com <mailto:zh_skyfox at hotmail.com>
>>>>
>> ----------------------------------------------------------------------------------------------
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> 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