I’m an MD/PhD student working on MRS research. I had learned about BIDS several months ago and was interested in working on this. It’s nice to see that you all have started, I’d love to get involved.
Good to see you @bsoher!
2 Likes
To pick this up after the understandable ISMRM lull I propose that we try to have a meeting to try and thrash out what seems to be the two key points around the data format.
-
What should we include in any standard format? To @bennyrowland’s point should we have formats for results, fits etc.
-
Is NIFTI the right format? I think the alignment to existing tools is compelling for the actual data, but I’m open to discussion and there might well be better formats for some of the items in point 1.
I’ll email around those who have been involved in this thread, but if anyone else would like to be included please say so here or contact me privately.
A proposed agenda can be found here.
1 Like
Basis spectra are NOT always spectra. Sometimes they are described as a collection of resonance lines taken from a simulation’s TransitionTable, ie. a list of lists of [area, phase, ppm] values. These can be reconstituted into spectra, but can also be stored in a more compact and universal form.
Agreed. I almost stored the FSL-MRS basis spectra as density matrices so that they could be easily generated at any bandwidth with any number of points. However this then clashes with how you might store MM…
I think basis spectra are the tricky bit here, we are going to have to think how to capture all of these methods of definition.
Hi Will (et.al.),
I had time to browse the most recent add-ins to the BIDS MRS doc and added my thoughts. And decided to summarize them here to add to the community discussion. I’ll probably add a few responses to threads from July and Aug as well …
-
Re. concern about pixdim header value being sufficient for Spectral Width value … if we go with NIfTI2 format, then that uses double floats rather than NIfTI1’s float values, so that should be enough.
-
I’m not sure if I agree with having an mrs_level_0 conformance. It does not provide Center Frequency, which is an essential value for MRS data provenance. I’d rather support a format that enforces some minimal level of provenance. Which is also part of the reason that I really support requiring that the JSON ‘sidecar’ info has to also be in a NIfTI header extension.
-
In the optional data dimensions, I think we should add a tag for DIM_MEASUREMENTS as some scanners allow multiple repeats of same acquisition over time. On Siemens, these are stored in same twix file and Series rather than in multiple twix files or series.
-
Re. conformance levels … I’m not a fan of ‘sublevels’ like 2A and 2B. Too confusing. Would prefer to just see mrs_level_2, mrs_level_3, mrs_level_4 etc. Also level_2A does not require that any data be added to the JSON header. Just that if you add header values, that you use standard tags (best as possible). This could just be added to mrs_level_1. Then mrs_level_2B could just become mrs_level_2 …
-
Re. Why Bother Making Another Format - sorry Assaf, just got back to this. Bottom line is that no one format is well defined for MRS, so there is still ‘room’ to do this. And double down with the fact that manufacturers all still put data out in their own formats. So, some sort of conversion is ALWAYS being done at some point in moving data from the scanner to usable ‘research study statistics’. It would be nice to have that conversion step be supported by the community rather than having each of ‘us’ (software developers) have to do it when manufacturer versions change.
-
Re. How to Support Processing Provenance in the JSON. Well, some programs keep a complete provenance in XML or JSON already. That could just be included in it’s own section. You could even just include the XML provenance in the JSON as one long string
. Beyond that we would have to suggest some sort of organization, but still within it’s own JSON section. If a program uses a ‘preset file’ or a ‘batch file’ to do processing, these could be included in a JSON ‘ProcessingProvenance’ section as subsections called ‘ProcessingStep01’ then ‘ProcessingStep02’. This keeps it very generic. Really just gives a time-order of processing steps. But, I think that we could go down a rabbit hole if we try to get more specific than that. -
Hi Zander! @ZanderGiuffrida welcome to the Yabber.
-
Re. MRSI Parameter Maps a.k.a. Derived Results - I think that by the time we get to MRSI parameter maps, we are no longer strictly in the MRS data domain. Parameter maps by definition have reduced the data dimensionality back into a visual representation of some sort of an analysis of the MRS data - ie. fitting. So this is now an ‘imaging’ modality, and should use the NIfTI format as it is intended to be used for images. It then becomes the project level organization’s responsibility (ie. BIDS, or XCEDE) to track where this NIfTI file is and what MRS NIfTI file it relates to.
-
Just to give a Use Case - I have no need to store both MRSI data and MRSI parameter maps in the same file. I just need them (maybe) in the same directory or directory hierarchy, and either named usefully, or organized in a BIDS (or something) sidecar to let me know where to find them and how to access them. This is how the MIDAS EPSI package has organized MRI/EPSI/ParameterMaps data and results for years using an XML schema of project.xml and subject.xml files to track all the patients and studies in a project.
Right, enough typoing. See you all next week!
Brian.
Hi Brian,
Some nice thoughts here, thanks for moving the discussion forward. I would like to add some comments:
-
+1 on NIfTI2
-
+1 on requiring JSON in the header extension and not accepting data which is not minimally compliant.
-
The list of dimension labels is an interesting topic, particularly if we want to create automated converters for manufacturer formats. I think this needs more discussion in the live meetings.
-
+1 for simplifying the conformance levels. I think you may be reversing 2A and 2B here. 2A just means that the transform in the main header is valid, which is also specified by setting the header field q_form > 0, so I agree that 2A is unnecessary, but also agree that 2B just means that there might be some additional MRS parameters set, but no specific ones are required for any particular case. I don’t know that there is a hierarchy of non-essential parameters that would allow for different conformance levels which required providing all the parameters up to a particular list, they seem more orthogonal than that to me e.g. I could give TE/TR for relaxation correction in quantification, or I could give sequence details for basis set calculation, but neither requires the other to be present. I would therefore propose that we only have one conformance level, what is currently level 1, and then just maintain the set of parameters proposed for 2B as specifications for optional parameters i.e. if you do include the parameters, this is the format to use. The list of reasonable parameters to be specified is a separate discussion topic for live meetings I think.
-
+1
-
I think it would be nice to have a field in the JSON which is basically a list of processing steps, each time a .nii file gets loaded, processed and downstream files saved they should persist the previous list and add on a new element describing the processing performed at this step, however I don’t think we can prescribe a specific format for that, there are too many variables, particularly with interactive processing tools.
-
Always nice to welcome new people to the discussion.
-
I agree that MRSI maps could be allows to recede back into standard NIfTI without extension but this does mean that some useful parameters get left behind, meaning that the map is not complete without the associated MRS NIfTI file, which is both more painful for software to handle loading correctly, and makes it harder to share. The most obvious example is the excitation box, and potentially chemical shift artefact and direction which are not part of a standard image, but there are probably others. While you could argue that the name of the metabolite/ratio could be stored in the filename alone it might be nice to include that in the header information, and we could also imagine having a set of maps in a single file for convenience, and a header labelling them. I agree that it would be nice to structure the file so that it “just works” as an image for tools which don’t speak NIfTI MRS, but adding a header extension with some nice to have information for tools in the know would be preferable to doing nothing, IMO. This could either be achieved through a separate extension code for MRSMap, or (if we do away with conformance levels as proposed above) by using the NIfTI header intent_name to store either
mrs_dataormrs_map(and then perhapsmrs_basisor whatever else should come up). -
+1
Ben
Hi all,
right off the bat, I have to appreciate @wclarke for creating this topic.
I would start by mentioning that a part of my Ph.D. topic is creating a vendor-independent format for MRSI data. So, it is a while I am studying different formats.
Before stating technical issues, I am really thrilled with what you have done, and because my Ph.D. topic is in this field, I would like to actively contribute to this project.
Currently, I am in Roland Kries Lab, and I am working on development an internal format for exchanging simulated basis set for 1D and 2D-NMR. This internal format is based on nifti (extended version). I was wondering whether data or source code could be useful or not for this project. There is a draft for this format.
Besides, I am working on Bruker MRS/MRSI data conversion to nifti. I have access to Bruker and GE data (MRS/I) and I can implement the format in real world project. However, I have been struggling with storing region of interest. Appreantly, it has not defined yet in your NIFTI MRS format specification. I have some ideas but it would be really great to use your experience for evaluating them.
I read your format specification, i was wondering if it is possible to put comment in this google doc or not.
1 Like
Hi @amirshamaei,
Very exciting that you have found your way to this thread. As far as I understand, the current working copy of the NIfTI MRS specification is editable and commentable by anyone, so I suggest you log in with your Google account and comment where you would like. If you’re interested in joining the conversation right away, @wclarke can probably also send you the invitation to your next working group meeting.
Best,
Georg
Hi @amirshamaei,
Thanks for adding your comments to the documentation. You’ve picked out a few things we’ve missed (or that have got lost along the way).
I’ll send you an email about our next meeting on Wednesday afternoon. You are very welcome to join.
Will
Thank you for this excellent discussion and the work you guys have done so far! I would like to get everyone’s input on an upcoming need in our multi-site project: We are required to share single voxel MRS data collected as part of a multi-modal protocol (anatomic, diffusion, resting state, MRS) with the NIMH Data Archive (NDA). All other modalities will be shared in NIFTI format and for consistency it makes sense to also share the MRS data in NIFTI. You have made great progress with the MRS NIfTI specification. The question is when do you think it will be ready for prime time and how useful would the data be for interested third parties if we go ahead and shared it in NIfTI now?
A second and more practical question relates to NIfTI conversion: We were able to convert our locally acquired Siemens DICOM data to NIFTI format using spec2nii (thanks Will!), however our multi-site data are de-identified and many fields (like Device Serial #) that spec2nii requires have been stripped off from the data. Due to increasing privacy concerns, this is likely to be the case for other projects also. Will, do you have any plans to modify spec2nii to make it compatible with de-identified data?
Thanks in advance for any help and suggestions you may provide,
1 Like
Hi @GulinOz, thanks for posting! I’m tagging @wclarke here so he sees your question with regard to letting spec2nii handle de-identified files (I imagine it’s quite easy to loosen which fields it expects to be filled).
We plan to present the latest iteration of the NIfTI MRS specification to the community soon, and designate a time window during which community members can submit feedback and suggestions. Once this feedback is incorporated, there shouldn’t be many roadblocks left. Do you have a deadline for making the data available at NDA?
Hi @GulinOz,
Thanks for the encouragement! I’m optimistic that the specification we have currently is not going to change for the more standard acquisition protocols such as SVS. However, as @admin says, we need a level of community agreement that what we have is fit for purpose - so there is always a chance we’d need to change something.
Is it ready for the prime time? I think the best way to find out is to test it with a real use case - so your timing is good! So far we have 8 software packages agreeing to support the format with maybe half that actually having a working NIfTI MRS import code at the moment.
It’s important to note that you’d be an early adopter and there are bound to be teething issues (thanks for spotting the de-identified data issue!) - however there is a strong will (no pun intended :)) to sort these things out quickly.
Ideally we will try to have just one conversion tool (spec2nii), but in the meantime I have code to perform the conversion for Siemens data and don’t mind taking a look if Will is unable to update spec2nii and you need something ASAP.
Martin
1 Like
Hi everyone and especially @GulinOz,
It’s great to hear that we already have some interest for this project. As far as the de-identification problem goes, that is an easy fix. I’m currently re-writing the spec2nii code to actually produce data in the provisional standard (rather than something I cobbled together for FSL-MRS). The provisional standard makes nearly all fields optional so it is appropriate that I change the conversion tool to cope with anonymised data. I will have a go at this tomorrow and I think it’s likely that I will push out a new version this week or next week. It will also be possible to try the new version straight from Github even if I don’t get it up on conda-forge yet.
With respect to whether the standard is ready, as Martin says it would be great to have a real world case to try it out on and with that, some feedback on what is important to capture for the data sharing use case. I think that as long as the data is relatively ‘normal’ e.g. 1H SVS/MRSI then I don’t expect the standard to change much. I suspect the issues we are going to have to iron out will be around more exotic data and for some of the meta-data that people may want to carry with it.
Will
1 Like
Thank you all for your fast responses!
@admin, our first NDA deadline is very soon, on January 15, but my plan is to request an exception for submission of the MRS data. The next deadline is in July and it seems we may be ready for submission of MRS data in NIfTI format by then.
@wclarke, we’ll be happy to try your new version as soon as you feel it is ready for testing. Our data is indeed relatively normal SVS, saved in single shots. Please contact me off-line once the new version is ready and I’ll connect you to our data management team. Thank you for your work on this!
1 Like
@martin, happy to provide the real use case. Great news that already 8 software packages have agreed to support the format!
1 Like
So good to see this work happening _ and a lot of thought has gone into it already. I wonder if there is scope to add the MRSinMRS checklist parameters in some fashion to the BIDS .json sidecar? A lot of the parameters are likely already included (field strength, frequency, voxel size etc), but if there is some way to include, or generate the checklist (or most of it) from the .json it would be very useful to authors, and would seem to fit with the intent of BIDS. (IMHO). Still getting to grips with using the MRS hub forum, so don’t quite see how to add a word document with the MRS checklist table to this conversation. @admin any helpful tips Georg?
1 Like
Agreed, @PGMM. I hope to dedicate some time this month to resurrecting the BIDS MRS Extension Proposal. The MRSinMRS checklist will certainly inform on the specification significantly.
Actually I think @wclarke may already be thinking about this as I shared a preprint of the MRSinMRS paper with him a little while back to make sure the nifti conversion got some if not all, the parameters we included.
Will, sorry for not remembering that earlier.
Hi @PGMM ,
Yes, you are right about that. I’d like to cover those parameters that are easily extractable from raw data formats into the NIfTI-MRS standard and spec2nii conversion tool. Plus, those which aren’t so easily to automate we can define the meaning of the standard. The NIfTI-MRS group are having a meeting about this (and other things) next week on Wednesday at 4pm. If you’d like to join you would be very welcome.
Hi @PGMM, I’ve just changed some settings that should now allow Word documents (.doc, .docx) to be uploaded here.
For everybody reading this thread, here is the link to the MRSinMRS paper:
Cheers,
Georg