Doubt about GUI from the plugin perspective.

[yjmantilla]

Hi @marcelzwiers , I dont know if you remember me. I'm the GSOC student from neurostars

Again, sorry for the late reply. I didn't have the general notifications activated so I only got notified if I was mentioned.

I'm evaluating the possibility of SOVABIDS (the project which is the MEG/EEG bids conversion backend) to have an API that plugs into BIDSCOIN PLUGIN API . I think it may be possible (details at yjmantilla/sovabids#1 (comment) )

Lets say I make an API that is compatible with your API and the plugin would be a wrapper around SOVABIDS backend. Given this:

• How is are the plugins connected for example to the GUI Editor?
• How would the GUI part of the software work? Is it already abstracted away for the plugins or what?
• Considering that these are EEG/MEG metadata and data fields, wouldn't the GUI need significant changes?

[marcelzwiers]

Hi Yorguin,

Yes, in the last couple of months I put quite a bit of work in making the bidseditor (the GUI) independent of DICOM / dcm2niix (I put all that in a plugin of my own). The bidseditor is expecting a certain structure in the bidsmap.yaml file (which is the heuristics file that it is editing), but that's all, you can just add a EEG/MEG section (with the same structure) and the bidseditor will understand it out of the box. Plugins are not connected to the bidseditor (except for some plugins settings that you can put there), but a plugin is used by the bidsmapper (to scan the data) and by the bidscoiner (to convert the data to BIDS). I am planning to do a hackathon session in the upcoming BrainHack to integrate bidscoin with phys2bids (from physiopy), i.e. write a phys2bids plugin for bidscoin.

[marcelzwiers]

Maybe, if you are interested, we can do a second hackathon session, to write a sovabids plugin for bidscoin as well :-)

p.s. it is one way to think of sovabids as a bidscoin plugin, you can also put the other way around and way think of bidscoin as a front-end for sovabids. It's the same thing, but it sounds differently :-)

https://ohbm.github.io/hackathon2021/

[marcelzwiers]

Here's a post about it from the brainhack physiopy-channel (that's on MatterMost), in which you can see how I added a stub phys2bids section to the bidsmap.yaml file and how that looked in the bidseditor (i.e. without their being a phys2bids plugin yet):

Hi all, with my recent bidscoin plugin development, I've separated the data mapping and GUI from the data format and conversion. I had a look at phys2bids and I think I it shouldn't be much work to write a little wrapper around it so that it can work as as bidscoin plugin. The bidscoin plugin API requires a few functions:

1. A routine to assess whether the file is of a valid dataformat for this plugin
2. A routine for reading an attribute from a sourcefile
3. A routine that can be called by the bidsmapper to make a bidsmap of the source data
4. A routine that can be called by the bidscoiner to convert the source data to bids

I suppose (1) and (2) can be easily done with phys2bids -info and (4) can be done with phys2bds as well, probably with a bit more work. And (3) is not hard to do, it's just interfacing with bidscoin to build the bidsmap. I can start a github branch if any one of you are interested in giving it (another) try to get bidscoin GUI / mapping frontend working for phys2bids (as opposed to setting up your heuristic file in the way you do now). I contacted you (@stefano Moia (he/him) ) in the past about this as well but I only now, with the plugin refactoring, layed the groundwork to really make it possible (I did the eat-your-own-dogfood thing). A phys2bids-mapping would/could look like this (it took me less than an hour to get this working in the GUI 🙂):

Physio:
# --------------------------------------------------------------------------------
# Physio key-value heuristics (phys2bids -info data) that are mapped to the BIDS labels)
# --------------------------------------------------------------------------------
  subject: <<SourceFilePath>>     # <<SourceFilePath>> extracts the subject label from the source directory during bidscoiner runtime
  session: <<SourceFilePath>>     # <<SourceFilePath>> extracts the session label from the source directory during bidscoiner runtime

  beh:        # ----------------------- All behavioural runs --------------------
  - provenance:                   # The fullpath name of the source file from which the attributes are read. Serves also as a look-up key to find a run in the bidsmap
    filesystem:                   # This is what you are using now (well, part of it)
      path:                       # File folder, e.g. ".*Parkinson.*" or ".*(phantom|bottle).*"
      name:                       # File name, e.g. ".*fmap.*" or ".*(fmap|field.?map|B0.?map).*"
      size:                       # File size, e.g. "2[4-6]\d MB" for matching files between 240-269 MB
      nrfiles:                    # Number of files in the folder that match the above criteria, e.g. "5/d/d" for matching a number between 500-599
    attributes:                   # The matching (regexp) criteria for the phys2bids -info data go in here
      Trigger:
      CO2:
      O2:
      Pulse:
    bids:
      task:
      acq:
      recording:
      run: <<1>>                  # This will be updated during bidscoiner runtime (as it depends on the already existing files)
      suffix: physio
    meta:                         # This is an optional entry for meta-data dictionary that will be appended to the json sidecar files produced by dcm2niix
      SamplingFrequency:
      StartTime:
      Trigger: <<Trigger>>
      Columns:
  - provenance:                   # The fullpath name of the source file from which the attributes are read. Serves also as a look-up key to find a run in the bidsmap
    filesystem:                   # This is what you are using now (well, part of it)
      path:                       # File folder, e.g. ".*Parkinson.*" or ".*(phantom|bottle).*"
      name:                       # File name, e.g. ".*eye.*" or ".*(iEEG|MEG).*"
      size:                       # File size, e.g. "2[4-6]\d MB" for matching files between 240-269 MB
      nrfiles:                    # Number of files in the folder that match the above criteria, e.g. "5/d/d" for matching a number between 500-599
    attributes:                   # The matching (regexp) criteria for the phys2bids -info data go in here
      Trigger:
      CO2:
      O2:
      Pulse:
    bids:
      task:
      acq:
      recording:
      run: <<1>>                  # This will be updated during bidscoiner runtime (as it depends on the already existing files)
      suffix: stim
    meta:                         # This is an optional entry for meta-data dictionary that will be appended to the json sidecar files produced by phys2bids
      SamplingFrequency:
      StartTime:
      Trigger: <<Trigger>>
      Columns:

[marcelzwiers]

[yjmantilla]

Man that yaml-way of abstracting the GUI is amazing. I'm really impressed. So, it seems that after all such integration should be possible in the future.

Many thanks for your time to provide the example.

Maybe, if you are interested, we can do a second hackathon session, to write a sovabids plugin for bidscoin as well :-)

That would be awesome. Sadly I'm not sure we will have our backend ready for June 16 )the hackaton). But in case we have that would be a really good idea. In any case, once the backend is ready I think it would be worthwhile trying to set up bidscoin as a front-end.

I will close this for now since my doubt is pretty much resolved.

Again, many thanks!

[yjmantilla]

@marcelzwiers Hi Marcel, just wanted to let you know I ended up registering at the OHBM Brainhack. The idea is to contribute to bidscoin to learn more about it and if all goes well maybe working on sovabids.

[marcelzwiers]

Nice, so you would join the phys2bids <> bidscoin hackathon or do you want your own sovabids hackathon?

[marcelzwiers]

ohbm/hackathon2021#12

[yjmantilla]

@marcelzwiers I would join the phys2bids hackathon, I would be a bit overwhelmed to propose my own hackaton hehe

[marcelzwiers]

You can already design the SOVABIDS plugin, the interface at least, without the back-end being ready. You can do so in the phys2bidscoin hackathon

[yjmantilla]

yeah, lets see how that goes!