[Insight-users] Changing itk.Examples.Registration.Translation1.cs to work with 3d images
Luis Ibanez
luis.ibanez at kitware.com
Thu Apr 15 21:05:47 EDT 2010
Hi Carl,
Thanks for posting the information about your images.
As you describe it, the image size (in bytes) is consistent
with the image size in pixels and the pixel type.
---
Regarding the pixel type: ITK readers will convert the
pixel type of the input image into the pixel type of the
image type that you use for instantiating the reader.
For example, if you have an image of pixel type
unsigned char
and you load it into an image of pixel type float,
then the reader with cast the pixel values from
unsigned char to float by using the default casting
rules of the C Language.
Note that this also applies if the image file is of
pixel type float, and the image type is unsigned char,
with the standard problem that the float numbers will
be truncated to unsigned char (and in many cases
precision will be lost).
If you have an image file of pixel type unsigned short,
and you load it into an image of pixel type unsigned
char, then you only capture the lower byte of every
pixel. Therefore you will end up with a corrupted
image.
If you want to preserve the original image information
you MUST load the image using a reader instantiated
using an image type that matches *exactly* the pixel
type of the image contained in the file.
Regards,
Luis
---------------------------------------------------------------------
On Mon, Apr 12, 2010 at 6:49 AM, Carl Bateman <Carl.Bateman at icr.ac.uk>wrote:
> Hi Luis,
>
> the raw file is 4096KB.
>
> This is the input header:
> NDims = 3
> DimSize = 128 128 128
> ElementType = MET_USHORT
> ElementSpacing = 1 1 1
> Offset = 0 0 0
> ElementByteOrderMSB = False
> ElementDataFile = Normalised_MRI.I33
>
>
> The output file is 2048KB
>
> This is the output header:
> ObjectType = Image
> NDims = 3
> BinaryData = True
> BinaryDataByteOrderMSB = False
> CompressedData = False
> TransformMatrix = 1 0 0 0 1 0 0 0 1
> Offset = 0 0 0
> CenterOfRotation = 0 0 0
> AnatomicalOrientation = RAI
> ElementSpacing = 1 1 1
> DimSize = 128 128 128
> ElementType = MET_UCHAR
> ElementDataFile = normalised_mri_REGISTERED.raw
>
>
> If short = 16bits and char = 8bits then the file sizes are correct, so
> confusion on my part.
>
> However, I'm still left with the question why is the ElementType changed?
> The imagetype used is itkImage_UC3, does that have something to do with it?
> Is the raw file data converted to unsigned char as it's read in? Is it
> possible to preserve the original data format?
>
> Regards,
>
> Carl
>
>
>
> >>> Luis Ibanez <luis.ibanez at kitware.com> 10/04/2010 14:58 >>>
> 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/20100415/651f84a1/attachment.htm>
More information about the Insight-users
mailing list