BIDscoin spec2nii2bids plugin development

[marcelzwiers]

This is not really an issue but an open invitation for anyone interested in participating in (or taking over if you like) the development of the spec2nii2bids plugin in BIDScoin. This plugin is merely a wrapper around spec2nii, to abstract away the file format specifics for BIDScoin. In this way, MRS data for BIDScoin is like any other data, allowing it to do automatic data discovery and present a GUI to the user for further editing of the BIDS output (if desired).

The reason I'm reaching out here is that I myself don't have any experience with / much knowledge about MRS, and I just wrote the plugin to help out with a multi-site project (LEAP) of one of my colleagues. For that, I only implemented support for SPAR, Twix, and Pfile data (i.e. the data formats collected in the project). Of course, it would be nice to extend that to all the formats supported by spec2nii, but I don't have access to nor experience with all those formats.

If you are interested, here's the plugin (adding a data format is very easy):
https://github.com/Donders-Institute/bidscoin/blob/master/bidscoin/plugins/spec2nii2bids.py

And here is the template bidsmap (adding a new data format section here isn't hard, but it contains prior knowledge for all the BIDS data types, so it is a bit long):
https://github.com/Donders-Institute/bidscoin/blob/master/bidscoin/heuristics/bidsmap_dccn.yaml

That's all there is to it. For more info about BIDScoin, see the (latest) docs:
https://bidscoin.readthedocs.io/en/latest/

Cheers,
Marcel

[wtclarke]

Hi @marcelzwiers,

This is a very cool tool. I enjoyed your presentation at the MRI Together conference. I'm happy to work to make any interface between spec2nii and BIDscoin work better, and include more options. However, I don't particularly have time right now to put lots of effort in.

A couple of other thoughts:
@markmikkelsen do you think we could have a sweep over this tool in the process of getting MRS integrated into BIDs? Or @schorschinho do you think there is any scope of integrating this into the pre-ismrm hackathon?

[markmikkelsen]

Hi @wtclarke,

Certainly, I can look through the aforementioned plugin to ensure it aligns with the integration of MRS into the BIDS standard.

[marcelzwiers]

I'm happy to work to make any interface between spec2nii and BIDscoin work better, and include more options.

That would be great, even if it's not tomorrow :-). One thing that would help the plugin a lot is if spec2nii had a generic interface to read / return a MRS header object, e.g. in a similar fashion as nibabel does (nibabel.load(sourcefile).header). Or is there already something in place for that?

[marcelzwiers]

Certainly, I can look through the aforementioned plugin to ensure it aligns with the integration of MRS into the BIDS standard.

You can't see that from the plugin because BIDS compliance is implemented more centrally using the bids schema files (i.e. this is taken care of by BIDScoin itself, plugins only need to convert the data, ideally with valid json sidecar files).

[wtclarke]

One thing that would help the plugin a lot is if spec2nii had a generic interface to read / return a MRS header object, e.g. in a similar fashion as nibabel does (nibabel.load(sourcefile).header). Or is there already something in place for that?

I'm not entirely sure what you mean. Are you suggesting such a thing for files once converted to NIfTI(-MRS)? If so there is the nifti-mrs package. Which uses the FSL image class to provide an interface like a nibabel nifti class object.

Or are you suggesting that there is an interface that uses some heuristics to try and figure out what sort of file it is and then load the data? If so I'm less keen on that because there are so many different types and many need a bit of extra information or guidance from the user.

[marcelzwiers]

The latter, some probing to see what the file format is and then read the header

[marcelzwiers]

Why not give the heuristics a try and give the user the option to skip that by passing the format him/herself (as is done now)

[wtclarke]

I could try to make something like spec2nii auto FILE with a big caveat emptor warning.

[markmikkelsen]

Certainly, I can look through the aforementioned plugin to ensure it aligns with the integration of MRS into the BIDS standard.

You can't see that from the plugin because BIDS compliance is implemented more centrally using the bids schema files (i.e. this is taken care of by BIDScoin itself, plugins only need to convert the data, ideally with valid json sidecar files).

Ah, I see. That makes things easier, then. I assume BIDScoin is synced with the master branch of bids-standard/bids-specification/?

[marcelzwiers]

@markmikkelsen Yes, though I review the changes myself before I copy them over to bidscoin (to avoid things breaking on my side), see here:
https://github.com/Donders-Institute/bidscoin/tree/master/bidscoin/schema

[markmikkelsen]

@markmikkelsen Yes, though I review the changes myself before I copy them over to bidscoin (to avoid things breaking on my side), see here: https://github.com/Donders-Institute/bidscoin/tree/master/bidscoin/schema

@marcelzwiers Got it. I was aware of BIDScoin before, and it's great to see it extended to include MRS data. I'll look through it and the plugin as soon as possible.

[wtclarke]

I could try to make something like spec2nii auto FILE with a big caveat emptor warning.

I had a quick go at this, it's now in version 0.6.4 (published imminently). Call spec2nii auto FILE. It should work for Twix, rda, SPAR/SDAT, GE p-file, DICOM (Siemens, UIH and Philips).

[marcelzwiers]

Wow, that was quick :-). I'll try to update the spec2nii2bids plugin accordingly later this week. To support MRS data format, I could use some suggestions for good header attributes to pick for my template bidsmap. But that will be later

[marcelzwiers]

Is there any spec2nii python module that I could use to read MRS header attributes?

[wtclarke]

In the converted files?

[marcelzwiers]

No, the source header(s). I currently use this for Twix (and comparable functions for other formats):

  from mapvbvd import mapVBVD

  twixObj = mapVBVD(twixfile, quiet=True)
  if isinstance(twixObj, list):
      twixObj = twixObj[mraid - 1]
      hdr = twixObj['hdr']

But I rather not do this myself if spec2nii already has functions for it

[marcelzwiers]

I also use:

  from spec2nii.philips import read_spar

  hdr = read_spar(sparfile)

But I need to know first what format the file is

[wtclarke]

What info are you after? The whole point of spec2nii is that the formats of all these proprietary formats (and the poorly conformed to DICOM standard) are a complete mess. That means the info in the headers is highly variable - from very detailed in twix - to basically absent in the Philips formats.

Could you do the conversion first then read from the standardised information? The NIfTI-MRS format has quite a bit in a nifti header extension.

[wtclarke]

Or constantly changing in GE

[marcelzwiers]

I do automatic data discovery (source data typing), based on the source data attributes and properties. So I need to read them (preferably in a unified way)

[marcelzwiers]

Then the user can edit the mapping from the source datatypes to the BIDS datatypes, then I do the conversion

[marcelzwiers]

It doesn't matter if the attributes are constantly changing, then I (or the user) only need to adapt some names in the template bidsmap. Moreover, the template bidsmap can (should) contain only the more stable ones

[wtclarke]

Ah, got it.

Ok, I'll have a think how best to handle this. At the moment spec2nii is completely coded for command line use. Obviously you can call individual functions but there is no coherent API.

[marcelzwiers]

I like how nibabel handles this :-)

[marcelzwiers]

I think that in the problem space of writing code that uses spec2nii to process (external) shared data collections, even when spec2nii is called from a shell, many programmers would like to probe a source file first to see what it is (i.e. read attributes) before converting it with spec2nii. Spec2nii is different from dcm2niix here, because dcm2niix basically only deals with one input format (ok, a bit of old PAR/REC legacy code), and more like nibabel, which deals with many input formats. I assume in your codebase, you converge to a shared code path at some point, so for maintainability, it is also good to have that convergence point as early as possible?