-
Notifications
You must be signed in to change notification settings - Fork 83
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
BIDS conversion of anatomical scans #693
Comments
Just noticed that perhaps #617 is related |
Running the conversion with example data, I realized that the only information being written to the
By now I also have realized that I need to run freesurfer anyway to get the surfaces and be able to produce the After being a bit more familiar with the matter, I see following things that could/should be done in the context of bidsifying anatomical data.
I believe i have read somewhere that writing
|
+1 to both your suggestions (especially the first one, which should be relatively straight forward) |
Chiming in here, +1 for both suggestions as well. Re adding more metadata from the Nifti file, that would be awesome. From my limited exp working with heudiconv, no package robustly extracts the BIDS metadata from a Nifti file (only from dicoms), so if we could have that as part of |
Cool.
Yup, I think so, too. The only thing that will be interesting is extracting the recording date, which might be a nice exercise to then also extract other information for the json sidecar.
Okay, I'll have a look into the options. But would adding |
Re heudiconv: I don't think we need as dependency. I suppose if possible, see how they extract metadata and what they extract to see if can just replicate that in I think there is some loss of info from .dicoms -> .nii though, so it might not be possible to do it for all types of data though... |
Updating
|
def update_sidecar_json(bids_path, entries, verbose=True): |
to also be able to update .tsv
files and not just .json
files. So, would it make more sense to first invest some time to add .tsv
support to that function, instead of diving straight into the specific write_anat
issue?
Indeed, the nifti header is much less comprehensive than the dicom header. Most relevant to this issue here, nifti headers don't seem to have information on acquisition time and date. Therefore, there is not much that can be done here with 1) process niftis and dicoms pros:
con:
2) only process dicoms pros:
cons:
3) only process niftis, and makes use of pre-bidsified anatomical images pros:
cons: 4) leave everything as is and pretend this issue never existed My preference is 3, 1, 4, 2 in that order. In any case, I think this issues deserves some additional information in the docs. Maybe as a info/warn box in the tutorial on how to write anatomical images. And maybe some nibabel-inspired disclaimer that this is experimental. |
Imo (not a strong opinion tho), 3) seems the most manageable and easiest solution. We should point to the relevant heudiconv documentation for going from:
However, if heudiconv goes from dicoms -> BIDS imaging folders... what's the point of |
For reference: #634 updating tsv is a can of worms :p, but if we can do it, I am very excited. |
haha, yeah, that will be fun. But well, depending on what we decide on regarding the dicom isse, it might not be necessary to mess with tsv files (at least for this issue) |
Right. Currently all that |
Hi,
I was trying to use
mne-bids
to BIDS-format anatomical scans and integrate it with the MEG part of the data set. In the process, I got a bit confused. My idea was to first create this bids dataset and later deal with the co-registration of head-, meg-, and mri spaces. So, basically, I expected to be able to produce anifti
file and associated side cars (scans.tsv
and asub-XX_T1w.json
), based on the header info. However,mne-bids
seems to produce only thenifti
without any sidecars, unless I provide transform and/or landmark information, right?I guess that makes sense from an MEG/MRI integrative point of view, but isn't it somewhat restricting to prevent all sidecars from being produced, because only some information are missing? I mean, all the MRI-related scanning parameters, as well as the
scans.tsv
should be independent from co-registration and could be processed regardless of whethertransform
info is present. In contrast, from your mri example, I get the impression that the only side cars that are produced in the mri-scan conversion are related to the co-registration, but maybe that is just for sake of illustration.Aside from that, I am also unsure whether this approach is completely in line with the BIDS derivative vs. raw principle. Isn't co-registration a preprocessing step that is done on raw data and its products (transform files, etc.) should therefore be a derivative? Admittedly, I have only a rough idea of the process of co-registration, so maybe I am talking nonsense.
Finally, I was also wondering whether it would make sense, to provide support to read
dicom
scans. Right now, I have to convert adicom
to anifti
before I can use it withmne_bids
. That extra step is a little awkward in the process. The api ofwrite_anat
says that the source image "Can be in any format readable by nibabel". Dicoms cannot directly be loaded with nibabel, but need some special treatment (see here). Not sure whether this can be integrated into themne-bids
framework?The text was updated successfully, but these errors were encountered: