[Insight-users] ITK 3.12 : Scheduled for Feb 28 2009
Luis Ibanez
luis.ibanez at kitware.com
Sun Feb 22 13:06:56 EST 2009
Hi Ivan,
This problem has now been fixed in the following way:
The ImageFileReader when encountering that the image
in the file has a number of dimensions larger than the
image type (e.g. loading a 3D image into an itkImage<char,2>
will set the direction cosines to a set of defaults defined
by the ImageIO class responsible for reading the image.
The default set of direction cosines is defined in the
ImageIOBase class, and it is set to an Identity matrix.
This Default is modified in the AnalyzeImageIO class
in order to fit in the three types of orientations
supported by Analyze.
---
The challenge here is that the solution must be an
N-Dimensional one. The reasoning should hold for
reading a 3D image out of a 4D sequence as well.
If you want to treat a DICOM slice as a 3D image, then
you should simply instantiate it as a 3D image from the
beginning. In this way you will have a 3x3 Direction
cosines matrix.
The scenario that you describe, where you are combining
multiple slices in 3D, should indeed be using 3D images
of 1-slice each, instead of using 2D images. Mathematically
2D images *do not* have a 3D thickness. They don't even
exist in 3D space.
----
With the current fix, your DICOM images can be read into
2D images, and their 2x2 direction cosines will be set
to an identity matrix.
Again, if you really want to consider this information
in 3D, then you should load this image into a 3D instance
of the itk::Image class.
After the modifications we can read the two DICOM slices
that you sent, into a 2D instance of the itk::Image.
If you have a chance, please give it a try to a CVS
updated checkout and let us know if you see any problems,
Thanks
Luis
--------------------
Ivan Macia wrote:
> Hi Luis,
>
> IMHO direction should be a 3x3 matrix, since a slice has an orientation
> in 3D space that for example is specified in the DICOM (DICOM also
> specifies Image Position too). For example, we use a cache strategy that
> allows us to load slices of a volume for visualization on demand. At the
> time of reconstructing the volume, we use this 3D direction in order to
> generate the volume (3D ITK image).
>
> There are times that a DICOM Series mixes images with different
> orientation where this information would be useful. For example, there
> are series that consist of a reformatted volume, let's say in axial
> orientation, whose first image is a coronal screenshot that represents
> the reconstructed area of the reformatted volume that follows. It seems
> reasonable to me to keep this information without having to recur to the
> DICOM metadata. The same argument could be applied to the image
> position, which is also 3D.
>
> But probably there are other considerations, such as the Analyze format
> you mention and other requirement or implementation issues that I am not
> aware of.
>
> In any case, thanks in advance for looking into this.
>
> Iván
>
>
> 2009/2/22 Luis Ibanez <luis.ibanez at kitware.com
> <mailto:luis.ibanez at kitware.com>>
>
>
> Hi Ivan,
>
> Thanks for pointing this out,
> and thanks for sharing your images.
>
>
> As described in the bug report, the offending code is in the
> ImageFileReader.
>
> We are looking at options that would result in a reasonable
> behavior.
>
> The challenge is that:
>
>
> a) When reading 3D Direction cosines into a 2D image,
> we only keep a 2x2 matrix. This matrix doesn't really
> map to 3D space
>
> b) The current code manually modify the matrices to
> satisfy the restrictions of the Analyze file format,
> but it doesn't address all the cases
>
> c) The naive solution of setting the directions to an
> identiy will result in an orientation that is not
> supported by Analyze.
>
>
> We are looking into this...
>
>
> Thanks
>
>
> Luis
>
>
> ------------------
> Ivan Macia wrote:
>
> Hi Luis, all,
>
> I dont know if this could be an outstanding issue or we are
> doing something wrong but for us it is. Since version ITK-3.10
> and on, we are not able to load ANY coronal or sagittal slice
> with a simple itk::ImageFileReader for a 2D image. An exception
> is always thrown in
> itk::ImageBase::ComputeIndexToPhysicalPointMatrices()
> complaining about the direction matrix being singular. This
> prevents us to switch to ITK-3.10 or future ITK-3.12 since our
> ITK-based software stopped working correctly.
>
> This was posted in the developers list some time ago but
> unfortunately got no answer this time :(
> See detailed description here.
>
> http://public.kitware.com/Bug/view.php?id=8470
>
> Can anyone please try to reproduce this error? You may used
> attached Dicom files to this email, one is coronal and one is
> sagittal. I tried with ImageReadWrite example in ITK-3.10.1.
> This works in ITK-3.8.0.
> I have set ITK_USE_ORIENTED_IMAGE_DIRECTION ON in CMake, but I
> think this should still work with this setting isn't it?
>
> Thanks in advance for your help
>
> Ivan
>
>
>
> 2009/2/20 Luis Ibanez <luis.ibanez at kitware.com
> <mailto:luis.ibanez at kitware.com> <mailto:luis.ibanez at kitware.com
> <mailto:luis.ibanez at kitware.com>>>
>
>
>
> Just to let you know that the release of ITK 3.12
> is scheduled for Feb 28.
>
> During the following week we will be cleaning up
> the Dashboard.
>
> If you see any outstanding issue,
> please let us know,
>
>
> Thanks
>
>
> Luis
>
>
> _____________________________________
> Powered by www.kitware.com <http://www.kitware.com>
> <http://www.kitware.com>
>
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the ITK FAQ at:
> http://www.itk.org/Wiki/ITK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.itk.org/mailman/listinfo/insight-users
>
>
>
More information about the Insight-users
mailing list