 |
Hi Andrey - Can you check and confirm that this is a duplicate of 0002945? If so, then it should be fixed by the patched in itk 4.4.1 Here's info from the slicer commit: https://github.com/Slicer/Slicer/commit/552f2cbe3b70321b3a3a6c63a104d10182acb0c9 And here's the ITK stuff: http://itk.org/gitweb?p=ITK.git;a=commit;h=9fa55c414d9000e467a57415329436e76356bebb http://itk.org/gitweb?p=ITK.git;a=shortlog;h=refs/tags/v4.4.1 |
 |
I confirm this remains a problem with Slicer r22251, ITKv4 35b90133a793ffd884820e499175db19366fe627. Attached is the screenshot of the volume orientation for the original nrrd dataset (also attached) and the exported DICOM series (also attached). |
2013-07-31 06:11
|
Screen Shot 2013-07-31 at 10.06.11 .png (103,112 bytes) |
|
2013-07-31 06:11
|
Screen Shot 2013-07-31 at 10.06.31 .png (122,792 bytes) |
|
2013-07-31 06:12
|
DCEFrame.nrrd (1,084,490 bytes) |
|
2013-07-31 06:12
|
DCEFrameDICOMExport.zip (853,898 bytes) |
|
|
Can also confirm this is not fixed. I have built with the updated ITK version. |
|
|
Reminder sent to: hjmjohnson, millerjv Has anyone single stepped through this to figure out what's happening? The ITK issue fixed by Hans was apparently not the cause of this issue. |
 |
I don't think the issue is #if ITK_VERSION_MAJOR >= 4 The orientations should be being pulled from the MetaDataDictionary. |
|
|
The third component of the direction cosines (first two vectors) is being set to zero somewhere. GDCM is then complaining that the direction cosines are invalid (probably because they are no longer orthogonal) and defaults back to the identity. |
|
|
itkGDCMImageIO is inconsistent as to whether the itkImage parameters of Origin and Direction are written to DICOM files or whether DICOM tags for these same variables in the MetaDataDictionary are written to DICOM files. For Origin, preference is given to the DICOM tag in the MetaDataDictionary over the ITK_Origin tag in the MetaDataDictionary. For DIrection, the opposite is the case. Preference is given to the ITK_Direction tag in the MetaDataDictionary over the DICOM tag in the MetaDataDictionary. CreateADICOMSeries writes each slice individually (as opposed to passing a volume to GDCM or using the ImageSeriesWriter to manage the conversion from a volume to a series of slices). As such, the ITK_Origin and ITK_Direction are really 2D and we need to rely on the DICOM tags in the MetaDataDictionary to provide the proper values. A patch to ITK has been submitted to gerrit http://review.source.kitware.com/#/c/12177/ If approved, this patch could be moved to the branch of ITK that Slicer uses. |
|
|
@Jim: We discussed on the slicer hangout and with Kent's negative review and the lack of a test this may not get into ITK for a while. Can this be worked around at the slicer level? |
|
|
I am trying to convince Kent :) We might be able to work around at the Slicer level by using the ImageSeriesWriter<3D,2D> and not using DICOM fields in the meta data for origin and direction. |
|
|
This has been merged into ITK. |
 |
Earlier this evening I tested the release branch of ITK and it doesn't compile ... seems to be a problem that occured when backporting commits. This is discussed here: http://www.itk.org/pipermail/insight-developers/2013-August/023102.html I also proposed a patch that should fix the problem. |
|
|
Fixed in r22355 |
|
|
Reminder sent to: fedorov, hjmjohnson, millerjv, pieper One last question, now the issue is resolved ... is the following statement still required: extract->SetDirectionCollapseToGuess(); // ITKv3 compatible, but not recommended |
|
|
Fix committed to 2145-support-for-installing-extension-from-file branch. |
- Anonymous
