I am having an issue where I have exported a volume as a DICOM file from Slicer. I then import this same DICOM file into Materialise Mimics and am getting completely different scalar values. I was wondering if anyone had any thoughts on this??
What values do you get if you load the exported files into Slicer or ITK-snap?
Within slicer I’m getting the proper HU range for bone. However within Mimics I get highly negative density values. I was wondering if you knew what could change ?
Please try with a couple of other software as well and see if they can load the image correctly.
We can investigate your finding if you can reproduce it with a data set that you can share with us (for example, data sets in Sample Data module or from open data repositories, such as TCIA).
So, I imported a sample DICOM set from Slicer’s Tutorial page to Mimics and it worked fine. I think I am exporting my image data (volume node) as a DICOM incorrectly. I was wondering if you could take a look at my data, and my exported DICOM?
Sincerely,
Asees Kaur
Yes, sure you can upload the dataset somewhere and post the link here. Make sure you don’t disclose any patient information.
Yes, I have included my original image data file (linear_mesh_8_FINAL.vtk) and the DICOM file I exported from it (Scalar_Volume_9.zip) within the OneDrive link.
https://onedrive.live.com/?id=9088EDA038297212%211452&cid=9088EDA038297212
Thank you very much.
@issakomi you are an expert in this field. Could you have a look at the exported DICOM data set to see if something is wrong with how the values are scaled?
Thank you. Unfortunately the link doesn’t work for me. “This item might not exist or is no longer available”
Here @issakomi this link should work, https://1drv.ms/u/s!AhJyKTig7YiQiyyPr_Z-1sc3dgkt?e=oOCwzb
Thank you I appreciate your help!
Thank you.
Negative values are from original VTK file, -10000 for background (padding ?) probably. There is some loss in precision at export (original data is float, exported is signed short).
linear_mesh_8_FINAL.vtk (float)
397 x 220 x 163
min. -10000, max. 1549.63000488281
DICOM (signed short)
397 x 220 x 163
min. -10000, max. 1549
I can only guess about Materialize, i don’t have the software, re-scale intercept is 1, slope is 0, so Modality LUT can not be a problem. May be Materialize doesn’t like signed scalars in CT, not sure, in DICOM files Pixel Presentation (0x0028,0x0103) value is 1 (signed, 2’s complement), it is valid too. So far DICOM export was not bad, IMHO. Geometry is correct too.
The scalar range is large, to visualize details window width / level could be adjusted, e.g. (threshold off, s. histogram, width, level)
1 Like
Thank you.
Is there any way to export it as a float as opposed to signed short?
Additionally, when I import the DICOM file I have created I receive this:
My DICOM file also imports in looking like this:
Window width/level unfortunately vary for different slices in exported DICOM, in fact 0/-10000 (it is bug, width can not be 0) in IMG0163.dcm (last one, it was applied), e.g. 10311/-4844, in IMG0001.dcm not available. But anyway full range or approximately full range is bad for particular case.
I see, so the error is caused by the varying window with/level for the slices. What tends to cause this, and is there a way to export a DICOM without this happening? Also, is this a major problem for the DICOM file?
probably not a very big problem, it is visualization issue, may be you can adjust window/level in Materialize. Different values for slices are rather common in original MR data sets. Honestly i don’t know, may it is possible to control it somehow during Slicer export, not sure.
Thank you for your assistance! I appreciate it, this helped clarify a lot!
1 Like
@issakomi Thanks a lot for your help with this.
@Asees_Kaur Recommended window width/level value in exported DICOM images were improved a few weeks ago in Slicer, so if you use latest Preview Release then the default window/level values may be more meaningful. But as @issakomi wrote above, it is just a display issue, you should be able to set your preferred window/level value in Mimics anyway. By the way, if you already use Slicer, why do you need to export to Mimics? Is there anything that you miss from Slicer that Mimics can do?
1 Like
@issakomi, so I found my Pixel representation is 1, meaning our data is represented at signed. However all attributes to do with image representation (group 0028 in metadata) are encoded as unsigned. So even though the pixel representation signifies that the data is signed, on displaying the DICOM image it is being incorrectly displayed as unsigned. is there a way within Slicer of exporting a DICOM with Pixel representation as unsigned.
Here is the metadata of a DICOM file that works well
Here is my file that does not work well
In fact, most original CT data sets use PixelRepresentation 0 (unsigned) and Modality LUT (re-scale intercept/slope) with negative RescaleIntercept to bring data into Hounsfield Units range (RescaleType=“HU”), as in your example above. But, AFAIK, signed is valid too, should work, s.
Tried to open the series in several DICOM viewers, seems to work (the only viewer failed to open the series at all, was Inobitec, don’t know why). May be (just guessing) it were better to skip DICOM export and create e.g. binary image or STL file in Slicer, if the purpose is 3D printing or mesh, may be it is possible to post-process or improve the file in Mimics later, not sure, of course.
Below screenshots (window level/width adjusted)
