You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@neurolabusc (Chris Rorden hiding behind his "company" name ;) ) has developed a great collection of DICOMs he uses to ensure correct operation of dcm2niix. I wondered if it could/should be used here even if just for a smoke test to ensure that highdicom can read all that zoo of files and potentially actually for various other testings (reading specific metadata fields, edits if it can etc)
You can discover more about it from the recent publication
Rorden, C., Béranger, B., Cheng, H. et al. DICOM datasets for reproducible neuroimaging research across manufacturers and software versions. Sci Data 12, 1168 (2025). https://doi.org/10.1038/s41597-025-05503-w
Thanks @yarikoptic indeed we have actually been considering this already and @mccle may be working on it soon
Although I will note that this will involve a careful assessment of scope. I gave highdicom the ability to read in volumes from multiframe or single frame series so that you could propagate the spatial information through basic processing steps to the derived images you would want to produce (DICOM Segmentations and Parametric Maps basically) without having to track all this yourself or use other libraries (ITK) for what should be simple tasks. However, it is not really my intention for highdicom to work around the large variety of manufacturer-specific quirks that I know dcm2niix deals with. If this is needed, you should probably stick to using a dedicated DICOM-to-NIfTI conversion tool such as dcm2niix, dicom2nifti, etc. So I don't think we will ever be at a point where highdicom can read everything in that repo in the way dcm2niix would. Nevertheless, there are certainly useful test files that cover situations we would want to test for
And I think in that context it is important to consider that at least some of the vendor-specific attributes can be harmonized into standard ones available in the multiframe enhanced family of objects. And that is highly relevant to this PR under active development: #388. It would be an interesting exercise for someone knowledgeable about neuroimaging and motivated to look into DICOM capabilities to see how much of the vendor-specific stuff can be mapped to the standard attributes. And that should be greatly facilitated by Claude Code, who (in my personal experience) has no fear of DICOM standard ;-)
Are there any other packages/tools that use those samples for regression testing? If yes - how do they implement data access?
frankly I don't know :-/ IIRC I used those collections at times to see how some particular DICOM field used (or not) across manufacturers. Note that the paper/official dataset composition is recent - so it is up to us to bring up its usage ;)
However, it is not really my intention for highdicom to work around the large variety of manufacturer-specific quirks that I know dcm2niix deals with. If this is needed, you should probably stick to using a dedicated DICOM-to-NIfTI conversion tool such as dcm2niix, dicom2nifti, etc.
Roger that! and I guess in my case I just wondered overall in relation to
as whenever I get time to (re)work heudiconv basic metadata reading, so we could figure out how to group and what to give to dcm2niix for actual processing. I guess it might be valuable for me to go through some of those and see how/where/if highdicom blows up or not, and whether it would be more than what we would crash on now with whatever cocktail we use there from nibabel.nicom.dicomwrapper, pydicom, and dcmstack.
Activity
CPBridge commentedon Mar 23, 2026
Thanks @yarikoptic indeed we have actually been considering this already and @mccle may be working on it soon
Although I will note that this will involve a careful assessment of scope. I gave highdicom the ability to read in volumes from multiframe or single frame series so that you could propagate the spatial information through basic processing steps to the derived images you would want to produce (DICOM Segmentations and Parametric Maps basically) without having to track all this yourself or use other libraries (ITK) for what should be simple tasks. However, it is not really my intention for highdicom to work around the large variety of manufacturer-specific quirks that I know dcm2niix deals with. If this is needed, you should probably stick to using a dedicated DICOM-to-NIfTI conversion tool such as dcm2niix, dicom2nifti, etc. So I don't think we will ever be at a point where highdicom can read everything in that repo in the way dcm2niix would. Nevertheless, there are certainly useful test files that cover situations we would want to test for
fedorov commentedon Mar 23, 2026
@yarikoptic can you confirm
dcm2niixitself is using those samples? I do not see it from the workflow, but I only took a quick glance.Are there any other packages/tools that use those samples for regression testing? If yes - how do they implement data access?
I understand those samples are available in https://zenodo.org/records/15310934. Is this the only place where one can find them?
Fetching anything of non-trivial size from Zenodo will not be fast, since its purpose is to facilitate archival - not production access.
fedorov commentedon Mar 23, 2026
I completely agree with @CPBridge here.
And I think in that context it is important to consider that at least some of the vendor-specific attributes can be harmonized into standard ones available in the multiframe enhanced family of objects. And that is highly relevant to this PR under active development: #388. It would be an interesting exercise for someone knowledgeable about neuroimaging and motivated to look into DICOM capabilities to see how much of the vendor-specific stuff can be mapped to the standard attributes. And that should be greatly facilitated by Claude Code, who (in my personal experience) has no fear of DICOM standard ;-)
yarikoptic commentedon Mar 23, 2026
reordered/groupped questions:
They are all git repos of @neurolabusc org https://github.com/neurolabusc?tab=repositories&q=dcm_&type=&language=&sort= , so I know that dcm2niix uses at least some of them by including as submodules : https://github.com/rordenlab/dcm2niix/blob/master/.gitmodules and we ran (when I was young and had plenty of time ;) ) tests while building neurodebian package for it against them: https://github.com/neurodebian/dcm2niix/blob/debian/debian/run_tests . I hope @neurolabusc could fill in more adequate info.
frankly I don't know :-/ IIRC I used those collections at times to see how some particular DICOM field used (or not) across manufacturers. Note that the paper/official dataset composition is recent - so it is up to us to bring up its usage ;)
Re @CPBridge earlier
Roger that! and I guess in my case I just wondered overall in relation to
as whenever I get time to (re)work heudiconv basic metadata reading, so we could figure out how to group and what to give to dcm2niix for actual processing. I guess it might be valuable for me to go through some of those and see how/where/if highdicom blows up or not, and whether it would be more than what we would crash on now with whatever cocktail we use there from
nibabel.nicom.dicomwrapper,pydicom, anddcmstack.