Closed ZhongkangLu closed 2 years ago
dcm2niix does leverage Image Position Patient (0020, 0032) as this is the most robust way to infer distance between slices.
Your description suggests that this is an enhanced DICOM image (multiple 2D slices stored in a single file) using the CT modality. I have only seen a handful of examples of enhanced CT DICOM, and only from a single manufacturer (Siemens). Note each manufacturer has interpreted DICOM differently). I do provide a validation dataset showing that dcm2niix extracts inter-slice distances correctly for enhanced DICOMs created by Canon, Philips, and Siemens.
Without a sample, I can not diagnose your issue. Does dcm2niix only generate a single image for this file, or is it segmenting these based on a difference in acquisition parameters (e.g. different exposures with interleaved slice locations). Feel free to share a sample dataset by sending a link to a dataset to the email address in my avatar, alternatively feel free to make a pull request to update the code.
Dear Rorden, Thanks for your prompt response! Due to copyright issue, I cannot share the data with you. You are right, it is an enhanced DICOM image (multiple 2D slices stored in a single file) using the CT modality. The DICOM image has a tag "Slice Thickness" = 0.5, and there is also an array of 512 "Per Frame Functional Groups Sequence" tags (512 slices). Each of them has an "Image Position Patient" tag. The interval of "Image Position Patient" tags is [0, 0, 0.25]. dcm2niix generated one single NIFTI image from the DICOM file. The NIFTI image has z resolution = 0.5, but the correct value should be 0.25. So, I think in dcm2niix "Slice Thickness" override "Image Position Patient". I hope the description may help you figuring out the issue. Best,Zhongkang On Tuesday, 2 November 2021, 09:17:50 pm SGT, Chris Rorden @.***> wrote:
dcm2niix does leverage Image Position Patient (0020, 0032) as this is the most robust way to infer distance between slices.
Your description suggests that this is an enhanced DICOM image (multiple 2D slices stored in a single file) using the CT modality. I have only seen a handful of examples of enhanced CT DICOM, and only from a single manufacturer (Siemens). Note each manufacturer has interpreted DICOM differently). I do provide a validation dataset showing that dcm2niix extracts inter-slice distances correctly for enhanced DICOMs created by Canon, Philips, and Siemens.
Without a sample, I can not diagnose your issue. Does dcm2niix only generate a single image for this file, or is it segmenting these based on a difference in acquisition parameters (e.g. different exposures with interleaved slice locations). Feel free to share a sample dataset by sending a link to a dataset to the email address in my avatar, alternatively feel free to make a pull request to update the code.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.
What is the manufacturer (Canon, GE, Philips, Siemens, UIH)? Can you or the manufacturer acquire data on a phantom that illustrates the issue? Again, the default behavior of dcm2niix is to use image position patient, so the behavior you describe is atypical. Without an exemplar, I am unable to give further advice.
The Scanner is Toshiba. I attached the header information in the email, which is generated by pydicom. Maybe I can send you a DICOM file with a all-zero image array, but it still needs a lot of administrative procedures. On Tuesday, 2 November 2021, 11:06:18 pm SGT, Chris Rorden @.***> wrote:
What is the manufacturer (Canon, GE, Philips, Siemens, UIH)? Can you or the manufacturer acquire data on a phantom that illustrates the issue? Again, the default behavior of dcm2niix is to use image position patient, so the behavior you describe is atypical. Without an exemplar, I am unable to give further advice.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.
(0018, 9326) CT Position Sequence 1 item(s) ---- (0018, 9313) Data Collection Center (Patient) FD: [0.0, 0.0, 1660.75] (0018, 9318) Reconstruction Target Center (Patie FD: [0.0, 0.0, 1660.75] (0018, 9327) Table Po
Toshiba Medical has been acquired by Canon.
Did the scanner create enhanced DICOM, or was the source data classic DICOM that was converted to enhanced DICOM using the PixelMed tools or another tool? If the latter, can you replicate the issue by converting an open source classic DICOM CT dataset through your pipeline?
You are correct. The DICOM image has been de-identified by a third-party software. Sorry that I don't have access to the software. The de-identified DICOM image can be correctly imported by all commercial software and some free software like itksnap, and 3D Slicer. On Wednesday, 3 November 2021, 02:56:45 am SGT, Chris Rorden @.***> wrote:
Toshiba has been acquired by Canon.
Did the scanner create enhanced DICOM, or was the source data classic DICOM that was converted to enhanced DICOM using the PixelMed tools or another tool? If the latter, can you replicate the issue by converting an open source classic DICOM CT dataset through your pipeline?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.
Yes, I am using the latest version, which is compiled from source code. So far I don't have any progress on the concrete exemplar. Hopefully I can go through the tedious administrative processes eventually. Thank you very much! On Wednesday, 3 November 2021, 07:17:31 pm SGT, Chris Rorden @.***> wrote:
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.
The single DICOM file, which contains multiple slices, has "SliceThickness = 0.5".
Some other tags are shown as following:
(0020, 9113) Plane Position Sequence 1 item(s) ---- (0020, 0032) Image Position (Patient) DS: [-45.473630, -85.473630, 1540.500000]
(0020, 9116) Plane Orientation Sequence 1 item(s) ---- (0020, 0037) Image Orientation (Patient) DS: [1.00000, 0.00000, 0.00000, 0.00000, 1.00000, 0.00000]
(0018, 9118) Cardiac Synchronization Sequence 1 item(s) ---- (0020, 9153) Nominal Cardiac Trigger Delay Time FD: 710.0
(0018, 9321) CT Exposure Sequence 1 item(s) ---- (0018, 9323) Exposure Modulation Type CS: 'ECG' (0018, 9324) Estimated Dose Saving FD: 92.08 (0018, 9328) Exposure Time in ms FD: 221.42857142857142 (0018, 9330) X-Ray Tube Current in mA FD: 420.0 (0018, 9332) Exposure in mAs FD: 93.0 (0018, 9345) CTDIvol FD: 13.7
(0018, 9326) CT Position Sequence 1 item(s) ---- (0018, 9313) Data Collection Center (Patient) FD: [0.0, 0.0, 1540.25] (0018, 9318) Reconstruction Target Center (Patie FD: [0.0, 0.0, 1540.25] (0018, 9327) Table Position FD: 127.625
(0020, 9111) Frame Content Sequence 1 item(s) ---- (0018, 9074) Frame Acquisition DateTime DT: '20150825100707.009' (0018, 9151) Frame Reference DateTime DT: '20150825100707.009' (0018, 9220) Frame Acquisition Duration FD: 350.0 (0020, 9056) Stack ID SH: '1_0724_00005' (0020, 9057) In-Stack Position Number UL: 511 (0020, 9128) Temporal Position Index UL: 1 (0020, 9157) Dimension Index Values UL: [1, 1, 511]
(0020, 9113) Plane Position Sequence 1 item(s) ---- (0020, 0032) Image Position (Patient) DS: [-45.473630, -85.473630, 1540.250000]
It can be seen that the interval between slices on z direction is 0.25. As a result, using "SliceThickness = 0.5" as the resolution on z direction is wrong. I hope dcm2niix team can solve the issue.