bids-specification
bids-specification copied to clipboard
bids-standard
[ENH] Add coil entity for uncombined MR data
Closes #370. This adds a new entity to distinguish coil-wise MRI data (i.e., data which have not been combined across coils).
An equivalent coil entity is already proposed in BEP-004, but applies to more than SWI, as pretty much any data acquired on a multichannel coil could be reconstructed without being combined across coils.
Also in BEP004, coil is used with an index (01, 02, 03, ...) thus not even taking advantage of available coil names etc (placing CoilName into .json is not yet suggested). So effectively it is merely a "disambiguation" index and not necessarily referring to a specific coil.
@yarikoptic Would you prefer to use the actual label from CoilString in the entity? I don't know how Philips or GE scanners disambiguate channels, but the Siemens CoilStrings are pretty short and to-the-point, as far as I can tell (e.g., H1, H2).
Also in BEP004, coil is used with an index (01, 02, 03, ...) thus not even taking advantage of available coil names etc (placing CoilName into .json is not yet suggested). So effectively it is merely a "disambiguation" index and not necessarily referring to a specific coil.
@yarikoptic Would you prefer to use the actual label from
CoilStringin the entity? I don't know how Philips or GE scanners disambiguate channels, but the Siemens CoilStrings are pretty short and to-the-point, as far as I can tell (e.g.,H1,H2).
I have no experience working with such data, so "not sure". To me it makes sense to use short label if such are available. Like we are not using _task-1 etc, but rather use descriptive label. I do not have data to check but I guess it would make sense to see H1, H2, ..., N1, N2 for head/neck coils. Then it would become obvious by simply looking at the files, which correspond to what elements in the coil.
I have no experience working with such data, so "not sure". To me it makes sense to use short label if such are available. Like we are not using _task-1 etc, but rather use descriptive label. I do not have data to check but I guess it would make sense to see H1, H2, ..., N1, N2 for head/neck coils. Then it would become obvious by simply looking at the files, which correspond to what elements in the coil.
Okay. It seems like something the BEP004 folks should weigh in on then. It would also be good to know what the labels for GE and Philips scanners tend to look like.
I left an additional pointer to this PR in BEP004 google doc, hopefully they would chime in. Meanwhile IMHO we should decide either to have _ch-<index> or _ch-<label>. Based on comments above, at least on Siemens label seems to be more preferable. Also, as far as I see it index wouldn't be strictly a channel index, since there could be none (like on Siemens where it could be label based). So I see label as a superset here and probably the one to go after.
FWIW, I have inquired some friendly tech/physicists on Philips scanner -- I was told that there is (currently) no way to export DICOMs per each channel. It is possible to export raw uncombined data but in "raw formats" (.list/.data format, or .raw/.lab/.sin format)... and I said them to not bother.
Given that label would make it easier to support either _ch-combined or _ch-total (not sure which is best) in addition to the channel identifiers, I am happy to switch away from index.
hm, isn't the file without _ch- assumed to be "combined"? I would not come up with "combined" values for the label, should be really corresponding to an individual channel otherwise confusion would arise.
@effigies @sappelhoff @robertoostenveld and @bids-standard/bep_leads -- what do you think about this PR?
If we cannot make decisions on individual small changes to BIDS like this one, it would be impossible to make conscious decisions and provide good analysis of large(er) PRs introducing full BEPs into the text base, thus only introducing more of the hidden gems like _part- ;)
@tsalo -- btw travis isn't happy yet:
src/04-modality-specific-files/01-magnetic-resonance-imaging-data.md
24:1085-24:1086 warning Misaligned table fence table-pipe-alignment remark-lint
As "co-lead" of BEP-001, I think this looks great. @yarikoptic, I agree that ch- might be more appropriate than coil-.
If we cannot make decisions on individual small changes to BIDS like this one, it would be impossible to make conscious decisions and provide good analysis of large(er) PRs introducing full BEPs into the text base, thus only introducing more of the hidden gems like _part- ;)
Sorry, but not 100% sure why you bring up part- here. Do you mean it got into the standard without much feedback and has an unfortunate name?
Re _part - yes, please see https://github.com/bids-standard/bids-specification/issues/429 and now "competing" #424 and #460
hm, isn't the file without _ch- assumed to be "combined"? I would not come up with "combined" values for the label, should be really corresponding to an individual channel otherwise confusion would arise.
That's true, but I thought folks might want the ability to be explicit. If it would just cause confusion, then we don't need to have it. I won't allow "combined", but I will switch from index to label.
I won't allow "combined", but I will switch from index to label
I wouldn't explicitly disallow anything, +1 on switching to label (which who knows, might be combined if scanner gets a channel with such odd label ;-))
Re _part - yes, please see #429 and now "competing" #424 and #460
just as an update: 424 and 460 are no longer competing - if everything goes smoothly we'll free up "part" in a couple of hours and start using "split",
I'm still somewhat confused on the coil/channel terminology (e.g., why is it a 32-channel head coil if there are apparently 32 coils and 64 channels?), but I think most folks will be happy with coil. Regardless, the PR has been updated with the schema changes, so I think this is ready for another round of reviews.
Per today's BIDS maintainer's call, I'd like to ping anyone who is involved in a BEP that includes uncombined MR data. AFAIK, the only applicable BEP is BEP 004 (SWI) (for which the lead is Fidel Alfaro Almagro, whose GitHub username I don't know), but please correct me if I'm wrong. BEP 022 (MRS) does mention real and imaginary channels, but I'm not sure it's related to this PR.
The main point of discussion is still "coil" vs. "channel". I have switched from channel (ch) to coil based on @tiborauer's comments, but I want to make sure that everyone involved has a chance to rebut the change if they want. I believe that the folks who argued for channel are @Gilles86 and @yarikoptic. Do either of you have major concerns with the change?
Recently, there was some interest in this PR on Twitter, so I'd like to try to make progress on it. Does anyone have any issue with the proposed changes?
CoilString is not in the schema, so it's not being rendered in the table. Is this a common term, by the way? I'm interpreting "string" as a type, which we don't generally put in the field name.
CoilStringis not in the schema, so it's not being rendered in the table. Is this a common term, by the way? I'm interpreting "string" as a type, which we don't generally put in the field name.
Good catch @effigies. I completely forgot to define CoilString in the schema. I believe that Coil String is the actual name in the DICOM Tag, but I think it's vendor-specific and is not part of the DICOM specification.
We should probably find out what different vendors use to label individual coils... Siemens data is the only one I have access to, and that's where Coil String comes from. If the others use the same name, I would go with that. Otherwise, I agree that a more descriptive name like CoilIdentifier would be better.
@effigies I could maybe post in the BIDS Google Group asking for information about uncombined data across manufacturers?
EDIT: Awesome! Posted in https://groups.google.com/g/bids-discussion/c/CK2sXdPXomE
@yarikoptic Is your scanner a Philips?
sorry, spotted just now. Used to be, now just Siemens. @neurolabusc might know more about all the Coil's metadata across manufacturers and/or have some sample uncombined acquisitions?
Some Coil metadata are handled e.g. in https://github.com/rordenlab/dcm2niix//blob/HEAD/console/nii_dicom_batch.cpp .
BTW, there was some data shared in the course of https://github.com/nipy/heudiconv/pull/424#issuecomment-606616968 : http://datasets.datalad.org/?dir=/dicoms/umass-philips/Zheng_Test_03302020 but not sure if it has it anyhow uncombined
This one kind of languished, it seems due to a lack of multi-scanner exemplar data. Any thoughts on how to move forward @tsalo @yarikoptic?
If there are any BIDS contributors who are able to generate or share some uncombined data, that would be really helpful. Unfortunately, I just don't have that ability at the moment.