Hi Bastian,
Thank you for checking my issue. I do not receive any error messages, I just
had some problems reading the .nrrd file that I just created and realized the
strange values in the file header.
This is my test code:
mitk::DataNodeFactory::Pointer dataNodeFactory = mitk::DataNodeFactory::New();
dataNodeFactory->SetFileName("../../Data/MR Philips Intera PERFUS._2/MR Philips
Intera PERFUS._2 001.dcm");
dataNodeFactory->Update();
mitk::DataNode::Pointer node = dataNodeFactory->GetOutput();
mitk::Image::Pointer image = dynamic_cast<mitk::Image*>(node->GetData());
mitk::Vector3D spacing1 = image->GetGeometry()->GetSpacing();
std::cout << spacing1[0] << "; " << spacing1[1] << "; " << spacing1[2] << "; "
<< spacing1[3] << std::endl;
CommonFunctionality::SaveImage(image,"D:/tmp/test.nrrd",false);
mitk::DataNodeFactory::Pointer dataNodeFactory2 = mitk::DataNodeFactory::New();
dataNodeFactory2->SetFileName("D:/tmp/test.nrrd");
dataNodeFactory2->Update();
mitk::DataNode::Pointer node2 = dataNodeFactory2->GetOutput();
mitk::Image::Pointer image2 = dynamic_cast<mitk::Image*>(node2->GetData());
mitk::Vector3D spacing2 = image2->GetGeometry()->GetSpacing();
std::cout << spacing2[0] << "; " << spacing2[1] << "; " << spacing2[2] << "; "
<< spacing2[3] << std::endl;
It gives the following console output:
1.99; 1.99; 4.00; -107374176.00
107374168.00; 107374168.00; 107374176.00; -107374176.00
As you can see, in my case accessing spacing[3] does not return 0, but a
meaningless (arbitrary?) value of -107374176.00 which mixes up the spacing
information written to the .nrrd file and causes problems, when you try to read
the file again.
The header of the produced .nrrd file looks like this:
NRRD0004
# Complete NRRD file format specification at:
# http://teem.sourceforge.net/nrrd/format.html
type: unsigned short
dimension: 4
space dimension: 4
sizes: 128 128 30 50
space directions:
(1.9883025649472899,0.12435464321394196,0,-107374179.23759747)
(-0.12435464321394196,1.9883025649472899,0,-107374179.23759747)
(0,0,4,-107374176) (0.12435464117797324,0,-118.14811307501077,-107374176)
kinds: domain domain domain domain
endian: little
encoding: raw
space origin:
(-118.14810943603516,-139.08045959472656,-42.880729675292969,-107374176)
The 4th value of space directions and space origin are not set to 0, but to the
meaningless value received when accessing spacing[3]. Manually tweaking the
.nrrd file to these values:
space directions: (1.9883025649472899,0.12435464321394196,0,0)
(-0.12435464321394196,1.9883025649472899,0,0) (0,0,4,0) (0,0,0,1)
space origin: (-118.14810943603516,-139.08045959472656,-42.880729675292969,0)
solves the problem and the data is imported with correct spacing information.
Regards,
Andreas
From: Graser, Bastian [mailto:b.gra...@dkfz-heidelberg.de]
Sent: Mittwoch, 15. August 2012 15:46
To: Hussong, Andreas; mitk-users@lists.sourceforge.net
Subject: AW: Writing 3d+t data to .nrrd
Hi Andreas,
I just checked your issue. The code indeed does not look so nice there. But it
works apparently. When trying to access the 4th element of the Vector3D or
Point3D a 0 is returned. So Origin and Spacing of the 4th element is zero here.
The resulting behavior is correct.
For the moment MITK does not permit a spacing of "time". Also the origin can by
definition not have a 4th coordinate.
I tried loading a from QLabs as DCM exported 3D+t ultrasound image (and other
4D images) and saved it as NRRD. It worked for me. Do you get any error
messages?
Regards,
Bastian
Von: Hussong, Andreas [mailto:andreas.huss...@philips.com]
Gesendet: Mittwoch, 15. August 2012 12:04
An: mitk-users@lists.sourceforge.net
Betreff: [mitk-users] Writing 3d+t data to .nrrd
Hi,
I wonder if I found a bug in the WriteByITK() method of the mitk::ImageWriter
class regarding spacing and origin for 4 dimensional (3d+t) data. Could someone
please check and verify this?
I tried to save some 3d+t data to .nrrd format and found some weird "space
directions" and "space origin" information in the output file.
In mitk::ImageWriter::WriteByITK(...) there is a for-loop setting spacing and
origin information for each dimension to the itk image IO object:
[...]
for(unsigned int i=0; i<dimension; i++)
{
imageIO->SetDimensions(i,dimensions[i]);
imageIO->SetSpacing(i,spacing[i]);
imageIO->SetOrigin(i,origin[i]);
[...]
}
The attributes "spacing" and "origin" are mitk::Vector3D and mitk::Point3D
objects. If dimension is 4 (as in my case) the loop addresses spacing[3] and
origin[3] which are not defined, producing corrupt spacing and origin
information.
A somehow related bug is filed in the bug tracker: "NRRD format does not save
4D images" (Bug 8211). But it is closed and marked as "resolved fixed"...
Best regards,
Andreas
________________________________
The information contained in this message may be confidential and legally
protected under applicable law. The message is intended solely for the
addressee(s). If you are not the intended recipient, you are hereby notified
that any use, forwarding, dissemination, or reproduction of this message is
strictly prohibited and may be unlawful. If you are not the intended recipient,
please contact the sender by return e-mail and destroy all copies of the
original message.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
mitk-users mailing list
mitk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mitk-users
