Pass different arguments to spec2nii plugin depending on run item

[schorschinho]

Is your feature request related to a problem? Please describe.
Different MRS acquisitions may require passing optional arguments to the spec2nii plugin:

Two optional arguments are available for the SPAR/SDAT pathway:
-t/--tags allows the user to specify the dimension tags for each of the higher dimensions (up to three).
-s/--shape allows the user to perform numpy style reshaping of multiple transients. By default (without specifying a shape) all transients will be listed in a single 5th dimension.
(https://github.com/wtclarke/spec2nii)

For example, some spectral editing (or other multi-dimensional) data may require the transients to be reshaped with the -s flag.

Describe the solution you'd like
I'd like to be able to pass arguments to the spec2nii plugin depending on the run item.

Describe alternatives you've considered
I could probably design two different bidsmaps that specifically pick up the different MRS data types, and specify options separately.

[marcelzwiers]

Do you mean you want to pass the -s argument for certain series only? Because the way it is now is that the args string is passed to spec2nii every time...

See:
https://bidscoin.readthedocs.io/en/stable/options.html#spec2nii2bids-plugin

[schorschinho]

Yes, exactly. I would love to be able to pass different values for the -s argument for different MRS series (but within the same session).

Example:
sub-001_acq-mega-press_svs.nii -> needs an -s [64 4] argument
sub-001_acq-press_svs.nii -> does not need an -s argument at all.

Until then, would you agree that setting up two different bidsmaps for the two types of series could work, where each bidsmap has the required set of spec2niibids plugin options (one with -s argument, one without)?

[marcelzwiers]

Ok, I never thought about such a use case. It seems a bit tricky to implement in a consistent / friendly way, but I'll think about it

[schorschinho]

Thank you so much for the quick response and engagement!

[marcelzwiers]

Two bidsmaps would work, but it is a bit clumsy / unhandy (you need to exclude part of the data in one bidsmap, and the other part in the other bidsmap)

[marcelzwiers]

What would work better is to add an 'Options' table next to the meta table, but that quite a rewrite of code

[schorschinho]

Thanks! I agree that an Options table would be the perfect solution to set arguments specific for particular run items, but I understand that would be substantial amount of work.

I'm reluctant to mess with the bidscoin code, so I think I'll just set up two bidsmaps (one exclusively for the MEGA-PRESS data) and deal with the clunkiness of it. I don't mind calling bidscoiner twice in a script. :)

[marcelzwiers]

Btw, I don't have much knowledge of or experience with MRS data, I just wrote the spec2nii plugin for a colleague of mine, who was pooling Twix, SPAR/SDAT and P-file data. The spec2nii app, however, supports more datatypes, and I guess I could easily add those to the plugin, if anyone is interested

[marcelzwiers]

If -s [64 4] is in any way stored in the header, I could perhaps make the options dynamic (i.e. reading the values from the header on the fly)

[schorschinho]

Thank you for offering. I'd be very interested in the data/list and various DICOM flavors that spec2nii supports, too.

Dynamic header reading would be absolutely outstanding, but I don't think you want to open that can of worms. For starters, MRS header fields are not standardized across vendors at all (which is why NIfTI-MRS was developed in the first place). The fields relevant to pass to the -s flag are particularly all over the place, and frequently the necessary information is not even present in the header at all, and needs to be inferred from the filename or, worse, user input. See the decision trees in our TWIX loader (https://github.com/schorschinho/osprey/blob/develop/libraries/FID-A/inputOutput/io_loadspec_twix.m)... and that's only Siemens data!

[marcelzwiers]

I would leave it up to the user to add the dynamic field. For instance, it could look like this (FieldOfView is just a random fieldname):

args: -s <<FieldOfView>>

Or even:

args: -s <<filename:sub-acq(.*?)>>

Where the regexp (.*?) could be any expression to extract the desired substring (e.g. 64 4)

(see also: https://bidscoin.readthedocs.io/en/stable/bidsmap.html#special-bidsmap-features)

[schorschinho]

That would be fantastic!

[marcelzwiers]

It is not trivial to implement run-specific plugin options, and I think the complications for both myself and the users would not be worth it. I am willing to make the plugin options dynamic, that would be easier, but I would first like to know if that would solve real-world use cases. Feel to re-open this issue if you have such a use case or if you have another suggestion

[marcelzwiers]

I have re-opened this old issue because the architecture of bidscoin has improved significantly in the last year, allowing me to implement your feature request with much less effort. So my question to you is, is it still relevant/needed or?