[Insight-users] DeformableRegistration7.cxx gives worse results

Luis Ibanez luis.ibanez at kitware.com
Wed Aug 8 12:45:14 EDT 2007



Hi Emma,


1)    Yes, you are doing something wrong.

    You should *not* reduce a CT scan
    from "signed short" to "unsigned char".


    BTW:What version of ITK are you using ?

    In the CVS version the pixel type of the
    DicomSeriesReadImageWrite*.cxx examples
    is "signed short". You should have obtained
    a .mha file with pixel type = Signed Short...



2) ITK will do a casting based on C-language conversions.
    If you are passing "signed short" to "unsigned char"
    then ITK (actually, C) will take the lower byte of the
    signed short.

    You should read the CT using an image type that matches
    the native pixel type of the image. (signed short).


    After reading the image, than you can reduce the pixel
    representation by using filters such as:

       RescaleIntensityImageFilter
       IntensityWindowingImageFilter
       SigmoidImageFilter

    All of them described in detail in the ITK Software Guide

        http://www.itk.org/ItkSoftwareGuide.pdf



3) ITK does not handle this conversions.
    It is *your responsibility* to handle the conversion.

    ITK is this way, simply because there are too many
    different ways to do the conversion and the correctness
    depend on the final application of your code.


    The premise of ITK is that you are managing *MEDICAL*
    images, and therefore *you* (as the responsible developer
    of a software application that is going to process
    patient information) will pay the utmost attention to
    the implications of pixel data conversions, algorithmic
    effects, and software quality of your application.


    As a developer, before you even write any code, you should
    draw a block diagram of the processing pipeline that you
    intent to implement, and in that block diagram you should
    ponder the consequences of data conversion at each stage
    of the processing.


              That is not a trivial exercise.


    Converting pixel data incorrectly can make the difference
    between detecting a tumor or not detecting a tumor.


    It is not a decision to be taken lightly.



      Regards,


         Luis


----------------
Emma Ryan wrote:
> Hello Luis,
> 
>    Thank you again for your reply. I have a few more questions based on 
> your reply.
> 1. I use Dicom CT images. The 30 odd slices are read as a dicom series 
> as 'sighed short'    using the program DicomSeriesReadImageWrite.cxx   
> in the ITK examples with appropriate modifications for CT modality. The 
> single 3D file that is output is '.mha'. This is 'unsigned char'. Hence, 
> my deformableRegistration program uses 'unsigned char' as the pixel type.
> 
> Am I doing something wrong here ?
> 
> 2. Does ITK, by default take the lower 8 bits when doing a type cast ?
> 
> 3. How does ITK handle all the conversions once the user decides that he 
> wants to read in dicom slices but output jpg slices instead ?
> 
> Please let me know.
> 
> Thank you,
> Emma
> 
> 
>  
> 
> ----- Original Message ----
> From: Luis Ibanez <luis.ibanez at kitware.com>
> To: Emma Ryan <eryanvtk at yahoo.com>
> Cc: Insight Users <insight-users at itk.org>
> Sent: Saturday, August 4, 2007 6:05:19 PM
> Subject: Re: [Insight-users] DeformableRegistration7.cxx gives worse results
> 
> 
> Hi Emma,
> 
> 
> 1) Thanks for uploading the "Before/After" images.
> 
>     You seem to have a pixel type problem.
> 
>     The images are probably 16-bits in its original form,
>     and in the code you are loading them in 8bits (unsigned char)
>     pixel type. You end up with the lower bits of the actual image.
> 
>     You *MUST* start by fixing the pixel type problem.
>     No registration method will work by feeding it with the
>     noisy lower bits of the pixel values.
> 
>     If your image is from a CT scan, you probably should use
> 
>          typedef    signed short      PixelType;
> 
>     instead of
> 
>          typedef    unsigned char     PixelType;
> 
> 
> 
> 2) Yes, the bulk transform is available.
> 
>     Please, please, please if you report an error, be kind
>     and include the *EXACT* error message in your email.
> 
>     Just saying that the program gives you an error,
>     doesn't help us much.
> 
> 
>              Did it failed to compile ?
>              Did it failed to link ?
>              Did the program crash ?
>              Did it throw an exception ?
> 
> 
>      Please let us know what error message you get.
> 
> 
> 3) Thanks for posting the code.
> 
>        Please start by changing the PixelType.
> 
> 
> 4) If you continue experiencing problems,
>     it will be useful if you upload the Fixed and Moving
>     images that you are trying to register.
> 
> 
> 
>    Thanks
> 
> 
>       Luis
> 
> 
> 
> ---------------
> Emma Ryan wrote:
>  > Hello Luis,
>  >
>  >       Just wondering if you got the images I uploaded to the server ?
>  >  
>  >    I had another question about bulk transform.  Is it really available
>  > ?  As I mentioned earlier, I see it in the header file, but when I try
>  > to use in in my program it gives an error.
>  >
>  >  I am also appending my program so you can have a better idea of what I
>  > am doing.  It is essentially the same as deformableRegistration7.cxx.
>  > The only difference is a few minor additions for output, like the time,
>  > checkerboard images and deformation vector output in x, y, z format.
>  >
>  > Emma
>  >
>  >
> 
> 
> ------------------------------------------------------------------------
> Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge 
> <http://us.rd.yahoo.com/evt=47093/*http://tv.yahoo.com/collections/222>to 
> see what's on, when.


More information about the Insight-users mailing list