View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0004056 | Slicer4 | Module DICOM | public | 2015-10-01 10:44 | 2018-05-31 10:00 |
Reporter | eliving159 | Assigned To | pinter | ||
Priority | normal | Severity | major | Reproducibility | always |
Status | closed | Resolution | unable to reproduce | ||
Product Version | |||||
Target Version | Fixed in Version | ||||
Summary | 0004056: Exporting DICOM series does not maintain information in original DICOM header | ||||
Description | After loading a DICOM set and doing something to it, like applying a transform for example, I try to export the adjusted volume as a new DICOM series. The new series is created, but the original header information is not passed through to the new series (either from the DICOM browser or the Create DICOM Series Module). Nor do the options to enter the RescaleSlope and RescaleIntercept tags (from the Create DICOM Series module) get honored upon export. | ||||
Tags | No tags attached. | ||||
Did you try the DICOM Export feature of the Nightly build? http://www.slicer.org/slicerWiki/index.php/Documentation/Nightly/Modules/DICOM Please use that and describe the exact steps and we can see if it's possible to replicate the issue. You should go through the Subject Hierarchy to associate the exported data with the study of interest. |
|
Ok, here goes. I'm including all steps leading up the dicom export. I updated to the latest nightly build before trying anything. I first selected the dicom module/browser and imported my volume. After the import was complete, I selected to 'metadata' to confirm the header was intact. It was. I then loaded the volume. I switched to the 'transforms' module and created a new linear transform. I selected my volume from the 'transformable' section and moved it to the 'transfomed' side. I selected a -3 degree PA rotation for testing. I then hardened the transform. I switched to the 'crop volume' module and created a new annotationROI. I adjusted it to the fit the volume, ticked the 'isotropic voxel' box and hit the crop button. I switched to the 'subject hierarchy' module and dragged the new volume into the hierarchy with the original volume. I opened the DICOM browser and hit the export button. I selected the transformed/cropped volume. At this point, the only information from the original header that is filled correctly is the PatientID and PatientName. This is also true if I select the original volume. I made sure the new volume was selected and clicked export. I selected the new DICOM series in the browser and viewed the metadata. Nothing was carried over from the original dicom header other than what was available for editing in the export dialog. |
|
Thanks eliving159 - that description helps a lot. @pinter what do you think? |
|
What metadata do you expect to carry over? When you say "nothing" was propagated, does that include one of the following? Only these tags are saved to the subject hierarchy nodes when loading a series to Slicer. Basically when you load it, then it stops being a DICOM object and becomes a Slicer volume, with some SH nodes containing tags for possible future use. |
|
By the way it does not matter what processing you do on the volume. If you don't do transformation and cropping, the same should happen. |
|
The tags you mention are propogated. I guess the two tags I'm most concerned with are RescaleIntercept (0028,1052) and RescaleSlope (0028,1053). They always end up set to 0 and 1, even if using the 'create dicom series' module and filling in the values manually. |
|
Those two tags describe the mapping from the pixel data representation to the real value. If you read the images back into slicer the in-memory numbers should be identical, it's just the numbers in the dicom object's pixel data that will be different. If that's the case then I'd say it is technically correct as is. If you want to manually change the slope/intercept and pixel data you can do that with a pydicom script (let me know if you want hints on that). |
|
I agree with Steve. Please compare the voxel density values when loading the original volume and when loading the re-exported volume. If for some reason propagating these tags is important, it will be the job of the DICOM scalar volume plugin. |
|
Ok, thanks. Within Slicer, I haven't really noticed any issues with the voxel density. The issue only arises (sometimes) when trying to take the transformed DICOM files to another program. Tips on using a pydicom script to change the tags would be appreciated. I have used another open-source program (MIPAV) to edit the tags in the past, but sometimes the volume would get corrupted in the process. When using the 'create dicom series' module rather than exporting from the DICOM browser, is there something I can do to force it to honor the input boxes for those (slope/intercept) tags in GUI? |
|
I think it is not enough alone to change the tags, because the already scaled voxel values will be scaled again. You'll need to apply the inverse of the slope/intercept parameters. Why do you think the exported DICOM volumes would be problematic in another program? If the result of the slope/intercept transform is the same, then the HUs will be the same. |
|
I have taken the exported DICOM sets into other programs, and the HU values have sometimes ended up off relative to the original DICOM set. I believe they were set based on a slope/intercept of 1/0, regardless of what is entered in the image parameters block of the 'create dicom series' tool. When taking individual HU values and scaling according the original slope/intercept, the values match up. This causes issues when trying to re-attach the bone density calibration of the original scan. I will pass through another attempt. I float between multiple computers and I may have been using an older version. |
|
@eliving159 Is this still an issue? If so, can you please provide us means to test this? Thanks! |
|
Further investigation would require feedback from the reporter. |
|
Date Modified | Username | Field | Change |
---|---|---|---|
2015-10-01 10:44 | eliving159 | New Issue | |
2015-10-01 10:44 | eliving159 | Status | new => assigned |
2015-10-01 10:44 | eliving159 | Assigned To | => pieper |
2015-10-02 09:28 | pieper | Note Added: 0013325 | |
2015-10-02 10:33 | eliving159 | Note Added: 0013326 | |
2015-10-02 10:34 | eliving159 | Note Edited: 0013326 | |
2015-10-02 10:39 | pieper | Assigned To | pieper => pinter |
2015-10-02 10:40 | pieper | Note Added: 0013327 | |
2015-10-02 11:52 | pinter | Note Added: 0013328 | |
2015-10-02 11:54 | pinter | Note Added: 0013329 | |
2015-10-02 12:01 | eliving159 | Note Added: 0013330 | |
2015-10-02 12:20 | pieper | Note Added: 0013331 | |
2015-10-03 06:40 | pinter | Note Added: 0013334 | |
2015-10-03 12:06 | eliving159 | Note Added: 0013335 | |
2015-10-03 14:58 | pinter | Note Added: 0013336 | |
2015-10-05 11:55 | eliving159 | Note Added: 0013337 | |
2017-10-06 11:41 | pinter | Status | assigned => feedback |
2017-10-06 11:41 | pinter | Note Added: 0015273 | |
2018-05-31 10:00 | lassoan | Status | feedback => closed |
2018-05-31 10:00 | lassoan | Resolution | open => unable to reproduce |
2018-05-31 10:00 | lassoan | Note Added: 0015862 |