Wow! - Thank you! I have two topogram folders:
│ ├── 04-
│ │ ├── 002-Topogram 1.0 Tr20
│ │ │ ├── EE6130EB
│ │ │ └── EE6B049D
and I’ve attached the second as an image because when pasted as text here it looks like its in the wrong place
The topograms below to sessions 4 and 6, respectively.
You could perhaps try it out (I don’t have the data to test it myself) by installing the latest code from GitHub? The code should now be resilient against your DS_Store files, so you should run it on your original data (i.e. without deleting anything)
python -m venv bidscoin_dev
source bidscoin_dev/bin/activate
pip install "git+https://github.com/Donders-Institute/bidscoin"
bidsmapper sourcedata BIDS_new -s -n 'patient-' -m '*'
bidscoiner sourcedata BIDS_new
Hi Marcel,
Thank you for your help so far - really appreciate it. In summary, it works but only if I manually delete the radiology report files.
Interestingly, at first, it picks up only ses-4 and ses-6 (see screenshot). It appears that the 5 radiology report files (which are missing ‘SeriesDescription’) are blocking it from creating subfolders:
2025-03-19 18:12:06 - ERROR | Cannot create subfolders, aborting dicomsort()…
2025-03-19 18:12:06 - ERROR | Missing ‘SeriesDescription’ DICOM field specified in the ‘{SeriesNumber:03d}-{SeriesDescription}’ folder/naming scheme, cannot find a safe name for: /private/var/folders/ … sourcedata/patient-01/DICOM/0000AC37/AA740734/AAB9BE77/00007A3B/FFA7A389.
Does the above suggest that it’s not the DS_Store files which are causing the problem - instead the report files?
It also gives a BIDScoiner version difference, but I don’t think this is a problem: /Users/user/.bidscoin/4.5.2.dev0/templates/bidsmap_dccn.yaml was created with version 4.5.2.dev, but this is version 4.5.2.dev0. This is normally OK but check the Changelog — BIDScoin 4.5.2.dev documentation
The bidseditor GUI does not seem to have full functionality, e.g. sliding the column to expand the width under ‘Representative Sample’ as before. Is this intentional because it is a developer version or an error at my end?
So, I manually deleted the files which gave the error above, and re-ran the code. It was then able to work, including bidscoiner, which gave the following output (below).
I think the BIDS output structure looks correct, however, I had to manually delete the files in order for this code to work: bidsmapper sourcedata BIDS_new -s -n ‘patient-’ -m ‘*’
I have checked the radiology reports and they all have the dicom tag (0008,0104) CodeMeaning with value ‘Radiology Report’. Do you think the block comes from the radiology reports and is there a way to exclude them based on this in order to automate the process?
sub-01
├── ses-01
│ ├── extra_data
│ │ ├── sub-01_ses-01_mod-MagImages_echo-1_GR.json
│ │ ├── sub-01_ses-01_mod-MagImages_echo-1_GR.nii.gz
│ │ ├── sub-01_ses-01_mod-PhaImages_echo-1_part-phase_GR.json
│ │ ├── sub-01_ses-01_mod-PhaImages_echo-1_part-phase_GR.nii.gz
│ │ ├── sub-01_ses-01_mod-SWIImages_echo-1_GR.json
│ │ ├── sub-01_ses-01_mod-SWIImages_echo-1_GR.nii.gz
│ │ ├── sub-01_ses-01_mod-t1mp2ragesagp3isoINV1_echo-1_GRIR.json
│ │ ├── sub-01_ses-01_mod-t1mp2ragesagp3isoINV1_echo-1_GRIR.nii.gz
│ │ ├── sub-01_ses-01_mod-t1mp2ragesagp3isoINV2_echo-1_GRIR.json
│ │ ├── sub-01_ses-01_mod-t1mp2ragesagp3isoINV2_echo-1_GRIR.nii.gz
│ │ ├── sub-01_ses-01_mod-t1mpragesagp2isopost_echo-1_GRIR.json
│ │ ├── sub-01_ses-01_mod-t1mpragesagp2isopost_echo-1_GRIR.nii.gz
│ │ ├── sub-01_ses-01_mod-t1mpragesagp2isopre_echo-1_GRIR.json
│ │ ├── sub-01_ses-01_mod-t1mpragesagp2isopre_echo-1_GRIR.nii.gz
│ │ ├── sub-01_ses-01_mod-t2spcflairsag1mmiso_echo-1_SEIR.json
│ │ ├── sub-01_ses-01_mod-t2spcflairsag1mmiso_echo-1_SEIR.nii.gz
│ │ ├── sub-01_ses-01_mod-t2tsecor448_echo-1_SE.json
│ │ ├── sub-01_ses-01_mod-t2tsecor448_echo-1_SE.nii.gz
│ │ ├── sub-01_ses-01_mod-t2tsetra448_echo-1_SE.json
│ │ └── sub-01_ses-01_mod-t2tsetra448_echo-1_SE.nii.gz
│ └── sub-01_ses-01_scans.tsv
├── ses-02
│ ├── extra_data
│ │ ├── sub-01_ses-02_mod-pCASLBL1800PLD1500con_echo-1_EP.json
│ │ ├── sub-01_ses-02_mod-pCASLBL1800PLD1500con_echo-1_EP.nii.gz
│ │ ├── sub-01_ses-02_mod-pCASLBL1800PLD1500diff_echo-1_EP.json
│ │ ├── sub-01_ses-02_mod-pCASLBL1800PLD1500diff_echo-1_EP.nii.gz
│ │ ├── sub-01_ses-02_mod-pCASLBL1800PLD1500lab_echo-1_EP.json
│ │ ├── sub-01_ses-02_mod-pCASLBL1800PLD1500lab_echo-1_EP.nii.gz
│ │ ├── sub-01_ses-02_mod-ssTE00TI1700_echo-1_EP.json
│ │ └── sub-01_ses-02_mod-ssTE00TI1700_echo-1_EP.nii.gz
│ └── sub-01_ses-02_scans.tsv
├── ses-03
│ ├── dwi
│ │ ├── sub-01_ses-03_acq-DTI2x2x22Multishell20ch2020fftscale_sbref.json
│ │ ├── sub-01_ses-03_acq-DTI2x2x22Multishell20ch2020fftscale_sbref.nii.gz
│ │ ├── sub-01_ses-03_acq-DTI2x2x22Multishell20ch2020negpefftscale_sbref.json
│ │ ├── sub-01_ses-03_acq-DTI2x2x22Multishell20ch2020negpefftscale_sbref.nii.gz
│ │ ├── sub-01_ses-03_run-1_dwi.bval
│ │ ├── sub-01_ses-03_run-1_dwi.bvec
│ │ ├── sub-01_ses-03_run-1_dwi.json
│ │ ├── sub-01_ses-03_run-1_dwi.nii.gz
│ │ ├── sub-01_ses-03_run-2_dwi.bval
│ │ ├── sub-01_ses-03_run-2_dwi.bvec
│ │ ├── sub-01_ses-03_run-2_dwi.json
│ │ └── sub-01_ses-03_run-2_dwi.nii.gz
│ └── sub-01_ses-03_scans.tsv
├── ses-04
│ ├── anat
│ │ ├── sub-01_ses-04_acq-DEHeadAngio10Hr383F08_ct.json
│ │ ├── sub-01_ses-04_acq-DEHeadAngio10Hr383F08_ct.nii.gz
│ │ ├── sub-01_ses-04_acq-DEHeadAngio10Hr383F08_ct_ROI1.nii.gz
│ │ ├── sub-01_ses-04_acq-DEPPDEHeadAngio10Qr403A80kV_ct.json
│ │ ├── sub-01_ses-04_acq-DEPPDEHeadAngio10Qr403A80kV_ct.nii.gz
│ │ ├── sub-01_ses-04_acq-DEPPDEHeadAngio10Qr403BSn150kV_ct.json
│ │ ├── sub-01_ses-04_acq-DEPPDEHeadAngio10Qr403BSn150kV_ct.nii.gz
│ │ ├── sub-01_ses-04_acq-Monitoring100Br36_ct.json
│ │ ├── sub-01_ses-04_acq-Monitoring100Br36_ct.nii.gz
│ │ ├── sub-01_ses-04_acq-Monitoring100Br36_ct_ROI1.nii.gz
│ │ ├── sub-01_ses-04_acq-PreMonitoring100Br36_ct.json
│ │ ├── sub-01_ses-04_acq-PreMonitoring100Br36_ct.nii.gz
│ │ ├── sub-01_ses-04_acq-PreMonitoring100Br36_ct_ROI1.nii.gz
│ │ ├── sub-01_ses-04_acq-Topogram10Tr20_ct.json
│ │ ├── sub-01_ses-04_acq-Topogram10Tr20_ct.nii.gz
│ │ └── sub-01_ses-04_acq-Topogram10Tr20_ct_ROI1.nii.gz
│ ├── extra_data
│ └── sub-01_ses-04_scans.tsv
├── ses-05
│ ├── extra_data
│ │ ├── sub-01_ses-05_run-10_mod-OrthoSpine.json
│ │ ├── sub-01_ses-05_run-10_mod-OrthoSpine.nii.gz
│ │ ├── sub-01_ses-05_run-11_mod-OrthoSpine.json
│ │ ├── sub-01_ses-05_run-11_mod-OrthoSpine.nii.gz
│ │ ├── sub-01_ses-05_run-12_mod-OrthoSpine.json
│ │ ├── sub-01_ses-05_run-12_mod-OrthoSpine.nii.gz
│ │ ├── sub-01_ses-05_run-1_mod-OrthoSpine.json
│ │ ├── sub-01_ses-05_run-1_mod-OrthoSpine.nii.gz
│ │ ├── sub-01_ses-05_run-2_mod-OrthoSpine.json
│ │ ├── sub-01_ses-05_run-2_mod-OrthoSpine.nii.gz
│ │ ├── sub-01_ses-05_run-3_mod-OrthoSpine.json
│ │ ├── sub-01_ses-05_run-3_mod-OrthoSpine.nii.gz
│ │ ├── sub-01_ses-05_run-4_mod-OrthoSpine.json
│ │ ├── sub-01_ses-05_run-4_mod-OrthoSpine.nii.gz
│ │ ├── sub-01_ses-05_run-5_mod-OrthoSpine.json
│ │ ├── sub-01_ses-05_run-5_mod-OrthoSpine.nii.gz
│ │ ├── sub-01_ses-05_run-6_mod-OrthoSpine.json
│ │ ├── sub-01_ses-05_run-6_mod-OrthoSpine.nii.gz
│ │ ├── sub-01_ses-05_run-7_mod-OrthoSpine.json
│ │ ├── sub-01_ses-05_run-7_mod-OrthoSpine.nii.gz
│ │ ├── sub-01_ses-05_run-8_mod-OrthoSpine.json
│ │ ├── sub-01_ses-05_run-8_mod-OrthoSpine.nii.gz
│ │ ├── sub-01_ses-05_run-9_mod-OrthoSpine.json
│ │ └── sub-01_ses-05_run-9_mod-OrthoSpine.nii.gz
│ └── sub-01_ses-05_scans.tsv
└── ses-06
├── anat
│ ├── sub-01_ses-06_acq-HeadSpiral10AxBone_ct.json
│ ├── sub-01_ses-06_acq-HeadSpiral10AxBone_ct.nii.gz
│ ├── sub-01_ses-06_acq-HeadSpiral10AxHr383_ct.json
│ ├── sub-01_ses-06_acq-HeadSpiral10AxHr383_ct.nii.gz
│ ├── sub-01_ses-06_acq-HeadSpiral10AxHr383iMAR_ct.json
│ ├── sub-01_ses-06_acq-HeadSpiral10AxHr383iMAR_ct.nii.gz
│ ├── sub-01_ses-06_acq-HeadSpiralRTD_ct.json
│ ├── sub-01_ses-06_acq-HeadSpiralRTD_ct.nii.gz
│ ├── sub-01_ses-06_acq-Topogram10Tr20_ct.json
│ └── sub-01_ses-06_acq-Topogram10Tr20_ct.nii.gz
├── extra_data
└── sub-01_ses-06_scans.tsv
Thanks, that’s very useful feedback! Your 6 studies, have they been acquired in one session or did your patient really get in and out of the scanner 6 times? I’ll have a further look tomorrow to see if I can iron out the last issues…
The 6 studies happened on 3 separate dates. 4 of the studies happened on the same day, and of these, 3 studies happened at the same time (I’m basing this off the dicom metadata) which I assume means the patient the did not get out of the scanner for these 3 sessions. Is this an issue?
It’s not an issue, I was just wondering what exactly, in DICOM terms, was defining a “study” and how well this maps onto a BIDS session
Btw, I have no experience with CT, so I did not add all the CT metadata fields (from BEP024). And I suppose that dcm2niix hasn’t done that either, which means that to be BIDS compliant, you will have to fill out the metadata table yourself (sorry), either in the bidseditor, or preferably, in the template bidsmap. If you do the latter, perhaps then you can submit a pull request or send me your edits, to the benefit of everybody 
Thank you, I understand. I don’t have experience with CT either and have/am mainly using MRI scans, but would use CT for lead localisation, for example.
Ok, with the latest code you should not have any issues anymore, let me know if otherwise (including GUI regressions and, especially, the radiology report errors):
source bidscoin_dev/bin/activate
pip install --force-reinstall --no-deps "git+https://github.com/Donders-Institute/bidscoin"
bidsmapper sourcedata BIDS_new -s -n 'patient-' -m '*'
bidscoiner sourcedata BIDS_new
Thanks again for the feedback, I couldn’t have fixed this without your help
Hi, I’m afraid that, as before, it only picks up ses-04 and ses-06, seemingly related to 5 files lacking ‘SeriesDescription’. Here are the errors:
INFO | >> Sorting: /var/folders/d9/lz2pjlr50ygdpn7ddzp2fbc40000gp/T/tmpsnocgrnf/Users/ ... sourcedata/patient-01/01- (3908 files)
ERROR | Missing 'SeriesDescription' DICOM field specified in the '{SeriesNumber:03d}-{SeriesDescription}' folder/naming scheme, cannot find a safe name for: /private/var/folders/d9/lz2pjlr50ygdpn7ddzp2fbc40000gp/T/tmpsnocgrnf/Users/ ... /sourcedata/patient-01/DICOM/0000AC37/AA5C483A/AA5BB5F3/0000A3A7/FFD51A51
ERROR | Cannot create subfolders, aborting dicomsort()...
INFO | >> Sorting: /var/folders/d9/lz2pjlr50ygdpn7ddzp2fbc40000gp/T/tmpsnocgrnf/Users/ ... /sourcedata/patient-01/02- (217 files)
ERROR | Missing 'SeriesDescription' DICOM field specified in the '{SeriesNumber:03d}-{SeriesDescription}' folder/naming scheme, cannot find a safe name for: /private/var/folders/d9/lz2pjlr50ygdpn7ddzp2fbc40000gp/T/tmpsnocgrnf/Users/ ... /sourcedata/patient-01/DICOM/0000AC37/AAD32921/AA448862/0000730C/FF35FD2C
ERROR | Cannot create subfolders, aborting dicomsort()...
INFO | >> Sorting: /var/folders/d9/lz2pjlr50ygdpn7ddzp2fbc40000gp/T/tmpsnocgrnf/Users/ ... /sourcedata/patient-01/03- (729 files)
ERROR | Missing 'SeriesDescription' DICOM field specified in the '{SeriesNumber:03d}-{SeriesDescription}' folder/naming scheme, cannot find a safe name for: /private/var/folders/d9/lz2pjlr50ygdpn7ddzp2fbc40000gp/T/tmpsnocgrnf/Users/ ... /sourcedata/patient-01/DICOM/0000AC37/AA740734/AAB9BE77/00007A3B/FFA7A389
ERROR | Cannot create subfolders, aborting dicomsort()...
INFO | >> Sorting: /var/folders/d9/lz2pjlr50ygdpn7ddzp2fbc40000gp/T/tmpsnocgrnf/Users/ ... /sourcedata/patient-01/04- (884 files)
VERBOSE | Creating: /var/folders/d9/lz2pjlr50ygdpn7ddzp2fbc40000gp/T/tmpsnocgrnf/Users ... /sourcedata/patient-01/04-/501-Dose Report
ERROR | Missing 'SeriesDescription' DICOM field specified in the '{SeriesNumber:03d}-{SeriesDescription}' folder/naming scheme, cannot find a safe name for: /private/var/folders/d9/lz2pjlr50ygdpn7ddzp2fbc40000gp/T/tmpsnocgrnf/Users/ ... /sourcedata/patient-01/DICOM/0000AC37/AA140CCD/AABD7737/000098FB/FFBFB03E
ERROR | Cannot create subfolders, aborting dicomsort()...
INFO | >> Sorting: /var/folders/d9/lz2pjlr50ygdpn7ddzp2fbc40000gp/T/tmpsnocgrnf/Users/ ... /sourcedata/patient-01/05- (15 files)
ERROR | Missing 'SeriesDescription' DICOM field specified in the '{SeriesNumber:03d}-{SeriesDescription}' folder/naming scheme, cannot find a safe name for: /private/var/folders/d9/lz2pjlr50ygdpn7ddzp2fbc40000gp/T/tmpsnocgrnf/Users/ ... /sourcedata/patient-01/DICOM/0000AC37/AA5C6C3B/AA2EF4AD/000074A8/FFDF25C9
ERROR | Cannot create subfolders, aborting dicomsort()...
INFO | >> Sorting: /var/folders/d9/lz2pjlr50ygdpn7ddzp2fbc40000gp/T/tmpsnocgrnf/Users/ ... /sourcedata/patient-01/06- (744 files)```
The GUI, however, does seem to be working normally:That’s weird, since I filter out those files with:
# Skip radiology reports, as they have a very limited DICOM header
if get_dicomfield('CodeMeaning', dicomfile) == 'Radiology Report':
LOGGER.info(f"Skipping radiology report '{dicomfile}'")
continue
I’ve based this on:
I have checked the radiology reports and they all have the dicom tag (0008,0104) CodeMeaning with value ‘Radiology Report’.
Is this not true? Or are there multiple CodeMeaning fields in your report file?
Ah, forgive my error.
(0008,0104) CodeMeaning with the value Radiology Report belongs to the tag ConceptNameCodeSequence which is empty. There are actually multiple CodeMeaning tags across the dicom metadata, which I had not realised.
However, I think I’ve found a dicom tag that is common to all of the report files which also has a value in it. This is (0008,0060) ‘Modality’ which has the value ‘SR’ (standing for Structured Report document - clinical report). So I think this should be able to pick up the report files?
Can you perhaps open the bidseditor and go to the [Data browser] tab, navigate to your input data, and double click on a report file? Can you share a screenshot of that? (I presume there is no personal info in there)
p.s. You can do this everywhere in the GUI, double-click on filenames, but your report file is missing from the representative samples, hence the data browser
Ok, I’m filtering out the SR files now, same recipe as before:
source bidscoin_dev/bin/activate # If needed
pip install --force-reinstall --no-deps "git+https://github.com/Donders-Institute/bidscoin"
bidsmapper sourcedata BIDS_new -s -n 'patient-' -m '*'
bidscoiner sourcedata BIDS_new
Dear Marcel, the recipe works to a tee. I have tried it on another patient’s data as well. I can’t thank you enough for your help with this!
The only warnings now are these multiple warnings: WARNING | The referenced SOP Instance for the directory record at offset 3773042 does not exist: /private/var/folders/d9/lz2pjlr50ygdpn7ddzp2fbc40000gp/T/tmp5hggm9pt/Users/ … sourcedata/patient-01/DICOM/0000AC37/AA740734/AAB9BE77/00007A3B/FFA7A389
If I run the bidseditor on the data again, I can’t change the data-type but I have found your troubleshooting section Troubleshooting — BIDScoin 4.5.0 documentation. Out of interest, is the SOP warning above related to the data type issue?
Thank you again.
Good to hear. If BIDScoin needs to reorganize the data (for passing it to e.g. dcm2niix), it is doing so in a tmp-dir. After reading the attributes from the data in the tmp-dir it is readily deleted, which makes that you can’t re-read new attributes when editing the datatype. As you have seen in the troubleshooting guide, to make this possible, you can use bidsmapper’s -s option to store the representative samples (in bidsfolder/code/bidscoin/provenance) so that they can be re-accessed later (when editing the datatype). The reason this is not the default is that I don’t want users to unknowingly store raw (privacy-sensitive) data in the bids-folder.
This warning means that your DICOMDIR file contains a reference to a DICOM object that does not actually exist in your dataset. Essentially, there is a mismatch between what the DICOMDIR expects and what is present, e.g. due to missing or corrupted DICOM files. To investigate this in more detail it could be useful if at the start you set:
export BIDSCOIN_DEBUG=TRUE
Out of interest, is the SOP warning above related to the data type issue?
I wouldn’t expect that
Do you perhaps have any news on this? I’m asking because I’m about to publish a new bidscoin release and would like to include a fix for this if I can…
Do you know what kind of file it is? (sourcedata/patient-01/DICOM/0000AC37/AA740734/AAB9BE77/00007A3B/FFA7A389)
Edit: It seems to be one of your report files. Did you delete them? Anyhow, I think you can ignore the warning, and that I will go ahead with the new release.
Hi Marcel, FFA7A389 is a TextEdit.app Document (2kb) and, you’re correct that it is one of the report files. I hadn’t deleted the report files when I encountered the WARNING SOP.
However, the SOP WARNING has now disappeared after I ran the code afresh, so am not sure what the reason for it was! No bidscoin warnings or errors now.
MANAGED BY INCF