-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enhanced dicom issues #44
Comments
@akhanf Regarding the naming of the tar file, there are two differences between the pre- and post-upgrade datasets:
|
Generally speaking, I think it's not a good idea to encode useful information in file names. The better approach is to open the DICOM files and examine their header attributes. I realize this may not be easy to implement at this point, but if you have to make major changes anyway, that would be a good opportunity to take another look at parsing/classifying DICOM datasets based on header contents. |
Thanks Igor -- I agree filename parsing is not the ideal approach but not looking to refactor this code, just wanting to get it functional again, and the changes to do that are pretty minor. Re: the date int he patient name, sorry I just copy-pasted a tarfile on our filesystem, and turns out someone had renamed it, the date indeed should still be in the filename, so thats not an issue: I've started a PR to fix the issues I brought up, this is in #45 |
Sorry for the late reply, I’m off work right now.
Regarding heudiconv, the time zone changes have been merged upstream.
nipy/heudiconv#780
The additional problem of filling the metadata sidecar file with 4d and 5d dicom metadata is not resolved upstream afaik. The problem needs to be addressed in one of heudiconv’s dependencies, dcmstack:
moloney/dcmstack#84
If none of our users are using the additional metadata, I would suggest using the official heudiconv repo and employing the minmeta option which will avoid the metadata bug until the changes in dcmstack have been merged.
Honestly, we may want to use minmeta by default even after upstream supports n-d enhanced dicoms. Heudiconv converts dicom to nifti using dcm2niix, but if minmeta is not used it will [convert the dicom to nifti a second time with dcmstack only for the purpose of concatenating dicom metadata for the bids sidecar file](https://github.com/nipy/heudiconv/blob/17fdfb47fe8d9d422ac914c5300ebe618f263178/heudiconv/dicoms.py#L683), which is inefficient especially for some of our larger datasets.
If users need more metadata than is provided with the minmeta option, we can always require them to extract it themselves using their heuristics file and defining a custom_callable function as done [here](https://github.com/khanlab/tar2bids/blob/bb1485d68041f7762cbbfef5acce0b5b45c70b44/heuristics/cfmm_bruker.py#L94-L106)
|
The use of --minmeta wasn't making a difference for me (ie it was still choking on the Bruker dicoms), and applying the commit you had (nipy/heudiconv@def8691) to the latest heudiconv doesn't fix things either, not sure if it is the same issue or a new one though..
I have this set-up in #45 (using this heudiconv fork: https://github.com/akhanf/heudiconv). |
@akhanf the above error is new and different from the metadata bug which is avoided by using the minmeta option. I opened an issue with nibabel for the new bug: |
With our recent Siemens software upgrade and move to enhanced dicoms we expected some issues, and here are the ones I've seen so far.
e.g. from:
Lau_NeuroAnalytics_20231218_SNSX_P145_1.350F466C.tar
to:
Lau_NeuroAnalytics_20241112_2024_11_12_209_8bee69a3-a558-44.25602A30.tar
The parsing in tar2bids is kludgy, so that will get a bit more awkward unless we move it to actual regex.. Not sure if the pattern (8hex-4hex-2hex?) will be consistent for different scans - @isolovey do you know?
however, it looks like using the latest heudiconv fixes this (I've confirmed that myself); looks like it might be related to having the latest nibabel version, as mentioned in this PR:
nipy/heudiconv#800
However, we are currently using a custom fork of heudiconv that has a fix for the Bruker dicoms -- @AlanKuurstra I wonder if this is still needed with the latest heudiconv/nibabel? Or do we just need to update our custom fork? I haven't looked into this yet..
The text was updated successfully, but these errors were encountered: