Hi Luis,<br><br>Everything runs smoothly now with the latest changes. Thanks again for being so expeditive.<br><br>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.<br>
<br>Regards<br><br>Iván<br><br><br><div class="gmail_quote">2009/2/22 Luis Ibanez <span dir="ltr"><<a href="mailto:luis.ibanez@kitware.com">luis.ibanez@kitware.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Hi Ivan,<br>
<br>
This problem has now been fixed in the following way:<br>
<br>
The ImageFileReader when encountering that the image<br>
in the file has a number of dimensions larger than the<br>
image type (e.g. loading a 3D image into an itkImage<char,2><br>
will set the direction cosines to a set of defaults defined<br>
by the ImageIO class responsible for reading the image.<br>
<br>
The default set of direction cosines is defined in the<br>
ImageIOBase class, and it is set to an Identity matrix.<br>
<br>
This Default is modified in the AnalyzeImageIO class<br>
in order to fit in the three types of orientations<br>
supported by Analyze.<br>
<br>
<br>
---<br>
<br>
The challenge here is that the solution must be an<br>
N-Dimensional one. The reasoning should hold for<br>
reading a 3D image out of a 4D sequence as well.<br>
<br>
If you want to treat a DICOM slice as a 3D image, then<br>
you should simply instantiate it as a 3D image from the<br>
beginning. In this way you will have a 3x3 Direction<br>
cosines matrix.<br>
<br>
The scenario that you describe, where you are combining<br>
multiple slices in 3D, should indeed be using 3D images<br>
of 1-slice each, instead of using 2D images. Mathematically<br>
2D images *do not* have a 3D thickness. They don't even<br>
exist in 3D space.<br>
<br>
----<br>
<br>
With the current fix, your DICOM images can be read into<br>
2D images, and their 2x2 direction cosines will be set<br>
to an identity matrix.<br>
<br>
Again, if you really want to consider this information<br>
in 3D, then you should load this image into a 3D instance<br>
of the itk::Image class.<br>
<br>
After the modifications we can read the two DICOM slices<br>
that you sent, into a 2D instance of the itk::Image.<br>
<br>
<br>
If you have a chance, please give it a try to a CVS<br>
updated checkout and let us know if you see any problems,<div class="im"><br>
<br>
<br>
<br>
Thanks<br>
<br>
<br>
Luis<br>
<br>
<br>
--------------------<br>
Ivan Macia wrote:<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi Luis,<br>
<br><div class="im">
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).<br>
<br>
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.<br>
<br>
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.<br>
<br>
In any case, thanks in advance for looking into this.<br>
<br>
Iván<br>
<br>
<br></div>
2009/2/22 Luis Ibanez <<a href="mailto:luis.ibanez@kitware.com" target="_blank">luis.ibanez@kitware.com</a> <mailto:<a href="mailto:luis.ibanez@kitware.com" target="_blank">luis.ibanez@kitware.com</a>>><div><div>
</div><div class="h5"><br>
<br>
<br>
Hi Ivan,<br>
<br>
Thanks for pointing this out,<br>
and thanks for sharing your images.<br>
<br>
<br>
As described in the bug report, the offending code is in the<br>
ImageFileReader.<br>
<br>
We are looking at options that would result in a reasonable<br>
behavior.<br>
<br>
The challenge is that:<br>
<br>
<br>
a) When reading 3D Direction cosines into a 2D image,<br>
we only keep a 2x2 matrix. This matrix doesn't really<br>
map to 3D space<br>
<br>
b) The current code manually modify the matrices to<br>
satisfy the restrictions of the Analyze file format,<br>
but it doesn't address all the cases<br>
<br>
c) The naive solution of setting the directions to an<br>
identiy will result in an orientation that is not<br>
supported by Analyze.<br>
<br>
<br>
We are looking into this...<br>
<br>
<br>
Thanks<br>
<br>
<br>
Luis<br>
<br>
<br>
------------------<br>
Ivan Macia wrote:<br>
<br>
Hi Luis, all,<br>
<br>
I dont know if this could be an outstanding issue or we are<br>
doing something wrong but for us it is. Since version ITK-3.10<br>
and on, we are not able to load ANY coronal or sagittal slice<br>
with a simple itk::ImageFileReader for a 2D image. An exception<br>
is always thrown in<br>
itk::ImageBase::ComputeIndexToPhysicalPointMatrices()<br>
complaining about the direction matrix being singular. This<br>
prevents us to switch to ITK-3.10 or future ITK-3.12 since our<br>
ITK-based software stopped working correctly.<br>
<br>
This was posted in the developers list some time ago but<br>
unfortunately got no answer this time :(<br>
See detailed description here.<br>
<br>
<a href="http://public.kitware.com/Bug/view.php?id=8470" target="_blank">http://public.kitware.com/Bug/view.php?id=8470</a><br>
<br>
Can anyone please try to reproduce this error? You may used<br>
attached Dicom files to this email, one is coronal and one is<br>
sagittal. I tried with ImageReadWrite example in ITK-3.10.1.<br>
This works in ITK-3.8.0.<br>
I have set ITK_USE_ORIENTED_IMAGE_DIRECTION ON in CMake, but I<br>
think this should still work with this setting isn't it?<br>
<br>
Thanks in advance for your help<br>
<br>
Ivan<br>
<br>
<br>
<br>
2009/2/20 Luis Ibanez <<a href="mailto:luis.ibanez@kitware.com" target="_blank">luis.ibanez@kitware.com</a><br></div></div>
<mailto:<a href="mailto:luis.ibanez@kitware.com" target="_blank">luis.ibanez@kitware.com</a>> <mailto:<a href="mailto:luis.ibanez@kitware.com" target="_blank">luis.ibanez@kitware.com</a><div class="im"><br>
<mailto:<a href="mailto:luis.ibanez@kitware.com" target="_blank">luis.ibanez@kitware.com</a>>>><br>
<br>
<br>
<br>
Just to let you know that the release of ITK 3.12<br>
is scheduled for Feb 28.<br>
<br>
During the following week we will be cleaning up<br>
the Dashboard.<br>
<br>
If you see any outstanding issue,<br>
please let us know,<br>
<br>
<br>
Thanks<br>
<br>
<br>
Luis<br>
<br>
<br>
_____________________________________<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a> <<a href="http://www.kitware.com" target="_blank">http://www.kitware.com</a>><br>
<<a href="http://www.kitware.com" target="_blank">http://www.kitware.com</a>><br>
<br>
<br>
Visit other Kitware open-source projects at<br>
<a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Please keep messages on-topic and check the ITK FAQ at:<br>
<a href="http://www.itk.org/Wiki/ITK_FAQ" target="_blank">http://www.itk.org/Wiki/ITK_FAQ</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://www.itk.org/mailman/listinfo/insight-users" target="_blank">http://www.itk.org/mailman/listinfo/insight-users</a><br>
<br>
<br>
<br>
</div></blockquote>
<br>
</blockquote></div><br>