[Insight-users] registration question

[Ken Urish]

> What I'm reading from your email is that the image
> origin and spacing got lost during the process of
> writing out the data to a DICOM file.
> Is that right ?

Yes. When I write the image using the series writer, the spacing and
origin for the z-axis were being thrown out. I found a way to fix the
problem although I do not know why it works. In my series writer (code
below), when I comment out:

//seriesWriter->SetMetaDataDictionaryArray(fixedReader->GetMetaDataDictionaryArray()
);

everything gets fixed and the origin and spacing are preserved. I
noticed this line of code is also in the registration/example7.cxx
file.
I am assuming that if it was in the example that it should be
important. Any thought on why it now is getting me in trouble? I am
running a cvs itk build from 04/08.

SeriesWriterType::Pointer seriesWriter = SeriesWriterType::New();
  fixedNamesGenerator->SetOutputDirectory(outputDirectory.c_str());
  seriesWriter->SetInput(caster->GetOutput() );
  seriesWriter->SetImageIO( gdcmIO );
  seriesWriter->SetFileNames( fixedNamesGenerator->GetOutputFileNames() );
  //seriesWriter->SetMetaDataDictionaryArray(fixedReader->GetMetaDataDictionaryArray()
);


I have one last question.

I have not worked with the image direction matrix before. I notice
that my output registered image has a new direction matrix as compared
to the fixed image:
1 0 0
0 1 0
0 0 1

The spacing and origin are otherwise identical and the images line up
perfectly when I put them through the checkerboard grid. I wanted to
make sure that its ok that the direction matrix is not the same and
that I am not putting my head in the sand on another big problem. If I
do use the resampler to make the output image have the same direction
matrix as the fixed image then it starts to screw w my spacing and
origin on my z-axis again.

I really appreciate your help.

Thanks
--Ken--


>
>
> You could make an additional verification by
> replacing the ImageSeriesWriter with an
> ImageFileWriter and saving the resampled moving
> image as a 3D single file, by using the MetaImage
> file format (.mhd), or Nrrd (.nrrd), or Nifti (nii).
>
> All of these file formats should preserve origin,
> spacing and orientation.   (DICOM should preserve
> it too... so.. once you run this verfication, we should
> go back an take a closer look at how you are writing
> out the DICOM series).
>
>
>      Regards,
>
>
>          Luis
>
>
> -------------------------------------------------------------------------
> On Fri, May 28, 2010 at 7:33 AM, Ken Urish <ken.urish at gmail.com> wrote:
>>
>> Luis
>>
>> Thanks for your response. Ive always been impressed by the excellent
>> support in the itk community.
>>
>> Indeed, you are right. My z-axis spacing and origin is getting lost.......
>> Im using dicom so I am surprised this is happening.
>>
>> When I look at the output of the registered and resampled output of
>> the moving image - the spacing and origin is identical to the input of
>> he fixed image. This is expected. I am doing a mattes registration so
>> my code is similar to the example itk code. I am using the verser
>> transform.
>>
>> When I take that identical output registered image and use it as input
>> for the checkerboard filter program the z-axis origin and spacing are
>> changed to 0 and 1 respectively.
>>
>> My registration output image info is collected from the resampled
>> image just before it is sent to the image series writer using gdcmIO.
>> The checkerboard input image info is collected just after the input
>> reader. Thus my registration output writer is somehow loosing this
>> z-axis info. Im keeping it in dicom so Im stuck on how Im loosing it.
>>
>> One solution would be to change the spacing and origin on my
>> checkerboard program. But I would be interested in having this fixed
>> on the initial registration program. Any thoughts on my error? I
>> appreciate the help. I included the specific output below.
>>
>> Thanks
>> --Ken--
>>
>>
>> Registration Fixed input image:
>>  Spacing: [0.3125, 0.3125, 3.48]
>>  Origin: [-18.1241, -60.8059, 58.0112]
>>  Direction:
>> -0.0348995 0 -0.999391
>> 0.999391 0 -0.0348995
>> 0 -1 0
>>
>> Registration Moving input image:
>>  Spacing: [0.364583, 0.364583, 0.7]
>>  Origin: [-3.39372, -70.4365, 70]
>>  Direction:
>> -0.0348995 0 -0.999391
>> 0.999391 0 -0.0348995
>> 0 -1 0
>>
>> Registration OUTPUT Image of the resampled moving image:
>>  Spacing: [0.3125, 0.3125, 3.48]
>>  Origin: [-18.1241, -60.8059, 58.0112]
>>  Direction:
>> 1 0 0
>> 0 1 0
>> 0 0 1
>>
>>
>> =====================================================================
>> Output of when the registered images are put straight through a checker
>> filter:
>>
>> Checker Input image of the registrated output moving image
>>  Spacing: [0.3125, 0.3125, 1]
>>  Origin: [-18.1241, -60.8059, 0]
>>  Direction:
>> 1 0 0
>> 0 1 0
>> 0 0 1
>>
>> Checker Input image of the fixed
>>  Spacing: [0.3125, 0.3125, 3.48]
>>  Origin: [-18.1241, -60.8059, 58.0112]
>>  Direction:
>> -0.0348995 0 -0.999391
>> 0.999391 0 -0.0348995
>> 0 -1 0
>>
>>
>> Checker Output with no resampling
>>  Spacing: [0.3125, 0.3125, 1]
>>  Origin: [-18.1241, -60.8059, 0]
>>  Direction:
>> 1 0 0
>> 0 1 0
>> 0 0 1
>
>