[IGSTK-Users] Get dimensions from igstkImageSpatialObject

[Luis Ibanez]

Hi Torleif,

1) You are right, you actually have public access to the
    RequestGetVTKImage() method, and if you connect an
    observer to the ImageSpatialObject you will get an
    event with the pointer to the vtkImageData.

    So, yes, you could grab the vtkImageData this way.

    This is actually bad news,... because it means that
    we failed to encapsulate the vtkImageData properly.

    The risk here is that once an application developer
    gain access to a vtkImageData pointer, it can change
    properties and values of the image, bypassing IGSTK.

    These method were intended to be called from other
    IGSTK components, but... currently we cannot prevent
    a developer from calling the methods from outside
    IGSTK.


2) It will be great to put the VolumeRendering image
    representation class in the sanbox. In that way
    we can do code reviews and raise up its level of
    testing.


3) Yeap, the conversion of the image to unsigned char
    pixel type looks like a bug.

    It looks like we should replace the;
    vtkImageMapToColors in igstkImageSpatialObject:
http://www.vtk.org/doc/nightly/html/classvtkImageMapToColors.html

"The vtkImageMapToColors filter will take an input image of any valid 
scalar type, and map the first component of the image through a lookup 
table. The result is an image of type VTK_UNSIGNED_CHAR. If the lookup 
table is not set, or is set to NULL, then the input data will be passed 
through if it is already of type VTK_UNSIGNED_CHAR."

    with vtkImageMapToWindowLevelColors
http://www.vtk.org/doc/nightly/html/classvtkImageMapToWindowLevelColors.html
map the input image through a lookup table and window / level it

"The vtkImageMapToWindowLevelColors filter will take an input image of 
any valid scalar type, and map the first component of the image through 
a lookup table. This resulting color will be modulated with value 
obtained by a window / level operation. The result is an image of type 
VTK_UNSIGNED_CHAR. If the lookup table is not set, or is set to NULL, 
then the input data will be passed through if it is already of type 
UNSIGNED_CHAR."

    I'll try this replacement and submit an Experimental build
    to see how it goes.


    Would you like to create a bug report for this issue ?


      Thanks



         Luis



----------------------
Torleif Sandnes wrote:
> Thanks for your reply.
> 
>> If you are doing volume rendering, that functionality will presumably
>> be implemented in an igstk::ImageSpatialObjectRepresentation class.
> 
> 
> Well, I will probably have to inherit from igstkSpatialObject and  
> mirror some functionality from ImageSpatialObject. None of the  methods 
> in igstkImageSpatialObject is virtual.
> 
>>    Inside this class, you can have access to the vtkImageData.
>>
>> We should not expose image information outside of IGSTK components.
> 
> 
> AFAICS, RequestGetItkImage() and RequestGetVtkImage() is public in  
> igstkimageSpatialObject.
> (http://public.kitware.com/IGSTK/NightlyDoc/ 
> classigstk_1_1ImageSpatialObject.html)
> So, I would probably be able to do this outside of IGSTK if I really  
> wanted to?
> 
>> Do you have your volume rendering class in the IGSTK Sandbox ?
> 
> No, I am just using a modified version of the  
> igstkImageSpatialObjectVolumeRepresentation from the DeckOfCardRobot  
> example.
> 
>> We could guide you on how to gain access to the vtkImageData,
>> and still remain inside the IGSTK walls. The process should be
>> very similar (if not identical) to what is done in the file
>>
>>    igstkImageSpatialObjectRepresentation.txx
> 
> 
> True, I had a look and I think I should be able to get access to what  I 
> wanted.
> 
> Btw, looking through the igstkImageSpatialObjectRepresentation class,  I 
> see that all images are converted to unsigned char because of a  
> restriction in vtkImageActor. Next, a vtkImageMapToColors is used to  
> set window width and level. Could it be something here that results  in 
> the problems we have getting good representation of MR images? CT  
> images are looking good. ( Attached a screenshot. igstk application  to 
> the left, osirix to the right. Window level 1011, window width:  2319 in 
> both applications.)
> 
> Regards,
> 
> Torleif
> 
> ------------------------------------------------------------------------
> 
> 
> ------------------------------------------------------------------------
> 
>  
>