[Insight-users] ITK 3.12 : Scheduled for Feb 28 2009

Sun Feb 22 17:14:30 EST 2009

Hi Luis,

Everything runs smoothly now with the latest changes. Thanks again for being
so expeditive.

Regarding the image Direction what you comment makes sense. I simply forgot
that we could work with single-sliced 3D images. I think we can easily adapt
our cached loading using 3D single-sliced images instead of 2D images.

Regards

Iván

2009/2/22 Luis Ibanez <luis.ibanez at kitware.com>

>
> 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
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/pipermail/insight-users/attachments/20090222/fd1951a6/attachment-0001.htm>