Page MenuHomePhabricator

3D+T 4D nrrd image writing creates strange values
Closed, ResolvedPublic

Description

From: Kislinskiy, Stefan [mailto:s.kislinskiy@Dkfz-Heidelberg.de]
Sent: Donnerstag, 16. August 2012 09:53
To: Hussong, Andreas; mitk-users@lists.sourceforge.net
Subject: AW: Writing 3d+t data to .nrrd

Hi Andreas,

I just had a quick look on your issue but accessing a 4th element in a three-dimensional vector is a bug of course. Thank you for reporting. We will have a look on it at the next bug squashing party (Wednesday).

Regards,
Stefan

Von: Hussong, Andreas [mailto:andreas.hussong@philips.com]
Gesendet: Mittwoch, 15. August 2012 18:29
An: Graser, Bastian; mitk-users@lists.sourceforge.net
Betreff: Re: [mitk-users] Writing 3d+t data to .nrrd

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

  1. Complete NRRD file format specification at:
  2. 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.graser@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.hussong@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" (T8211). 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.

Event Timeline

Fixed it.

Due to the itk templating we are forced to set a 4D spacing, 4D origin and 4x4 direction matrix when saving a 4D image.

However in mitk spacing, origin and direction are limited to 3D.

This was not considering in the writign procedure and the non-existent 4th component of 3D vectors was accessed, creating random values.

With the fix we are now introducing valid standard values to the 4th dimension

User graser has pushed new remote branch:

bug-12953-writing4Dimages

[931490]: Merge branch 'bug-12953-writing4Dimages'

Merged commits:

2014-03-05 16:11:49 Bastian Graser [f14ec8]
Added a 4th component to spacing, origin and direction matrix to support 4D images correctly