Getting the paths to the original DICOM files

[Esadruhn]

I am converting DICOM files into NIfTI that have annotations (rtstruct, SEG formats).
In the annotation file, I got the path to the DICOM slice and must find the corresponding slice in the NIfTI scan. Some metadata from the slice is also required, like ImagePositionPatient.
As is, I can parse the verbose to try and get the paths to the slices but it does not work if there are several scans and the paths are not ordered.

Could you add a feature to get the ordered list of paths to the slices in the json after conversion ?

[neurolabusc]

You may want to fork the project and try several solutions yourself. I think a generalized solution that will work with huge multi band datasets, enhanced DICOM, etc. might get unwieldy as a generic solution. It might be something best suited to a forked adaptation for your dataset. A simple local modification would be to just have the function nii_loadImgXL() report each file as it is loaded. If you use Matlab, you may also want to look at dicm2nii which saves a lot of conversion details in a. Mat file and is easy to adapt to special use cases.

Another simple option would be to simply rename your DICOMs into a nice file naming structure that is easy to parse. For example, if you have well behaved DICOMs where the instance number corresponds to the slice position, you could rename your images by time, series/protocol, and instance number:

dcm2niix -r y -f %t/%s_%p/%4r.dcm ~/DICOMs/

[Esadruhn]

Thank you,

Do you have an example where having nii_loadImgXL report each file could fail ? Or would it presumably work for all cases ? I am trying to get into the code but not a C expert.

My dataset has weird and special cases unfortunately, I cannot trust the instance numbers.

I am also trying to see how else to parse SEG and RTSTRUCT formats, for now I do not see any other solution than knowing which slice in the NIfTI corresponds to which DICOM file or SOPInstanceUID

[neurolabusc]

Please see the latest developmental commit. Defining myReportSliceFilenames during compilation will create a version that will report the filenames and their order to the terminal. These lines are delimited with the pipe symbol | so you can parse them easily.

A minimal compile would be

g++ -I. main_console.cpp nii_foreign.cpp nii_dicom.cpp jpg_0XC3.cpp ujpeg.cpp nifti1_io_core.cpp nii_ortho.cpp nii_dicom_batch.cpp -o dcm2niix -DmyDisableOpenJPEG -DmyReportSliceFilenames

When you run this variant, you get a listing of the file order, indexed from 0:

|0|/Users/c/dcm_qa/In/Orientation/ax/axasc35/MR.1.3.12.2.1107.5.2.32.35131.2014031012493950715786673
|1|/Users/ch/dcm_qa/In/Orientation/ax/axasc35/MR.1.3.12.2.1107.5.2.32.35131.2014031012494230872886774
Convert 2 DICOM as /Users/chris/tmp/dcm_qa_ax_asc_35sl_20140310133834_6 (64x64x35x2)

[Esadruhn]

Thank you for the feature !
I had a weird behaviour in a LIDC CT scan, see this example for reproducibility.

On an example of 4 slices, the output of dcm2niix is:

|4|correct/000241.dcm
|3|correct/000173.dcm
|2|correct/000241.dcm
|1|correct/000218.dcm

But the correct order (see the link for the test) is:

['000173.dcm', '000241.dcm', '000218.dcm', '000001.dcm']

In the output, it adds a slice that is elsewhere in the scan in first position (000241.dcm) and does not print the last slice (000001.dcm).

EDIT: Sorry if this is not the right place to mention this, should it be a separate issue ?

[Esadruhn]

Perfect, thanks !