[Insight-users] Changing itk.Examples.Registration.Translation1.cs to work with 3d images
Luis Ibanez
luis.ibanez at kitware.com
Sat Apr 10 09:58:56 EDT 2010
Hi Carl,
Well,.... let's go back to the basics:
What is the size of the raw file in Bytes ?
If the image is really of pixel size
256 x 256 x 128
with a pixel of 16 bits = 2 bytes,
then the raw file must have a size of
256 x 256 x 128 x 2 =
16777216 bytes
Please let us know what size in bytes do you
observe.
---
and, just to avoid confusion,
let me clarify:
MET_USHORT == unsigned short
MET_UCHAR == unsigned char
Thanks
Luis
--------------------------------------------------
On Fri, Apr 9, 2010 at 7:20 AM, Carl Bateman <Carl.Bateman at icr.ac.uk> wrote:
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/pipermail/insight-users/attachments/20100410/1f5fe0d4/attachment.htm>
More information about the Insight-users
mailing list