[Insight-users] Changing itk.Examples.Registration.Translation1.cs to work with 3d images

Fri Apr 9 07:20:09 EDT 2010

Hi Luis,

Thanks for getting back to me.

I don't know whether it's me or ImageJ or what...

Yet further investigation shows that the source image has:
ElementType = MET_USHORT

While the resulting  "_FIXED", "_MOVING" and "_REGISTERED" images have:
ElementType = MET_UCHAR

ImageJ reads the source as 16-bit and the resulting images as 8-bit.

Paraview displays the files correctly and identifies the source as unsigned short and the resultants as unsigned char.

Incidentally the source file is 4,096KB, while the resulants are 2,048KB.

Does this mean that 
MET_USHORT == unsigned char
MET_UCHAR == unsigned short ???

And why does itk.Examples.Registration.Translation1.cs change the data type?

All a bit confusing.

Regards,

Carl Bateman

>>> Luis Ibanez <luis.ibanez at kitware.com> 08/04/2010 19:28 >>>
Hi Carlos,

Yes, that the output that I was suggesting you to post.

However, before you focus on the registration process,
you must first solve the process of reading images.

The error message that you are getting:

>  MetaImage: M_ReadElements: data not read completely
>     ideal = 8388608 : actual = 4194304

Indicates that you are promising and image larger than
the content of the file that you are passing as input.

There is no point in looking at the registration until
you make sure that the input images are read correctly.
(without error messages).

You can verify the correctness of the input image
by using

1) Slicer  (www.slicer.org)

 or

2) Paraview (www.paraview.org)

to load the MetaImage.

       Regards,

               Luis

--------------------------------------------------------------
On Wed, Apr 7, 2010 at 11:22 AM, Carl Bateman <Carl.Bateman at icr.ac.uk> wrote:
> Hi Luis,
>
> thanks for getting back to me. Do you mean this?
>
> START: [007.00, 012.00, 000.00]
> 000:   [005.10, 009.41, -002.39]
> 001:   [003.95, 006.69, 000.30]
> 002:   [001.88, 004.75, -002.52]
> 003:   [-000.29, 002.16, -000.38]
> 004:   [-002.46, -000.96, 000.86]
> 005:   [-003.21, -002.80, -002.61]
> 006:   [-003.55, -004.41, -001.47]
> 007:   [-004.40, -004.95, 000.26]
> 008:   [-004.78, -005.75, -000.19]
> 009:   [-005.28, -006.60, -000.02]
> 010:   [-005.41, -007.59, -000.06]
> 011:   [-005.49, -008.59, -000.01]
> 012:   [-005.53, -009.59, -000.02]
> 013:   [-006.09, -010.41, -000.02]
> 014:   [-006.97, -010.89, -000.05]
> 015:   [-007.02, -011.89, 000.02]
> 016:   [-006.82, -012.83, -000.23]
> 017:   [-006.96, -012.46, 000.07]
> 018:   [-007.02, -012.01, -000.14]
> 019:   [-007.00, -012.01, 000.11]
> 020:   [-007.00, -012.01, -000.01]
> 021:   [-007.00, -012.00, 000.05]
> 022:   [-007.00, -012.00, 000.02]
> 023:   [-007.00, -012.00, -000.02]
> 024:   [-007.00, -012.00, 000.00]
> END:   [-007.00, -012.00, 000.00]
>
>
>
> Actually, after further investigation it looks as though there's some confusion over the raw data format. I changed the DimSize in the mhd from
>  DimSize = 128 128 128
> to
>  DimSize = 256 256 128
>
> and the code *seems* to work correctly, although it does generate the message:
>  MetaImage: M_ReadElements: data not read completely
>     ideal = 8388608 : actual = 4194304
>
> also, after applyiing the found parameters the resulting image seems pixelated (see attached png).
>
> Is there something wrong with the Read method? Is the image type incorrect? Or could it be the header file? (ImageJ reads the raw file correctly with 128, 128, 128.)
>
> Regards,
>
> Carl
>
>
>>>> Luis Ibanez <luis.ibanez at kitware.com> 07/04/2010 14:43 >>>
> Hi Carl,
>
> Thanks for the detailed description of what you are doing.
>
> You changes to the code look reasonable.
>
> The fact that the fixed image has a different number of
> slices than the moving image shouldn't be a problem,
> *as long as* both images have the correct values of
> pixel spacing.
>
> I would have expected the "registered" image to have the
> same image grid as the "fixed" image, since it is usually
> generated by mapping the intensity values of the moving
> image into the image grid of the fixed image.
>
> How does the current setup behaves when you run the
> registration ?
>
> Can you please post to the list the values of the Metric,
> and the transform parameters at every iteration of the
> registration process ?
>
>
>    Thanks
>
>
>         Luis
>
>
> ------------------------------------------------------------
> On Tue, Apr 6, 2010 at 12:34 PM, Carl Bateman <Carl.Bateman at icr.ac.uk> wrote:
>> I'm trying to change itk.Examples.Registration.Translation1.cs to work with 3d images.
>>
>> I've changed the existing using statements to:
>>  using ImageType = itk.itkImage_UC3;
>>  using InterpolatorType = itk.itkLinearInterpolateImageFunction_IUC3D;
>>  using TransformType = itk.itkTranslationTransform_D3;
>>  using ResampleType = itk.itkResampleImageFilter_IUC3IUC3;
>>  using MetricType = itk.itkMeanSquaresImageToImageMetric_IUC3IUC3;
>>  using OptimizerType = itk.itkRegularStepGradientDescentOptimizer;
>>  using RegistrationType = itk.itkImageRegistrationMethod_IUC3IUC3;
>>
>> and the transform.Translate lines to:
>>  transform.Translate(new itkVector(7.0, 12.0, 0.0));
>> and
>>  transform.Translate(new itkVector(0.0, 0.0, 0.0));
>>
>>
>> I'm using a raw image with a mhd header as input.
>>
>> The original image has 128 slices, but the "_FIXED", "_MOVING" and "_REGISTERED" images only have 64 slices.
>>
>> Additionally, the "_MOVING" and "_REGISTERED" images have a white cross through them (see attached png).
>>
>> I suspect that the problem lies in the transformation, as
>>  transform.Translate(new itkVector(7.0, 0.0, 0.0));
>> gives a horizontal line, while
>>  transform.Translate(new itkVector(0.0, 12.0, 0.0));
>> gives a vertical line.
>>
>>
>> Is it the transformation? And if so how should it be used correctly?
>>
>> Any help appreciated.
>>
>> Carl Bateman

The Institute of Cancer Research: Royal Cancer Hospital, a charitable Company Limited by Guarantee, Registered in England under Company No. 534147 with its Registered Office at 123 Old Brompton Road, London SW7 3RP.

This e-mail message is confidential and for use by the addressee only.  If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer and network.