MRIQC in a non-bids compliant dataset

[zeit problem]

Hey all, 

I'd really like to use the great work you have done as part of my QC pipeline. Now the problem is that I'm working within an established project which uses a different folder structure. It is just not feasable to convert to bids at the moment. 

Is there a way to run MRI-QC without having a BIDS-compliant dataset? 

Best,

Ruben. 

[Zvi Baratz]

Hi Ruben,

I made a similar request some time ago (see  https://github.com/nipreps/mriqc/issues/898).

Personally, I would decouple BIDS from anything I can (not because I don't like BIDS, quite the opposite, I just like decoupling more), but I understand Oscar's argument. In any case, AFAIK, best solution might be to script something to create a BIDS-like directory of symlinks and use that if you can. 

Best,

Zvi

--
You received this message because you are subscribed to the Google Groups "mriqc-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mriqc-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mriqc-users/8ec6d94a-bb11-4192-ac84-a06f538315cbn%40googlegroups.com.

[zeit problem]

Hi Zvi,

Thanks a lot for the hint with the symlink. I'll try to work around with that. However, I agree that as much decoupling as possible is nice :) 

[Oscar Esteban]

Thanks, Zvi, for unearthing the issue I referred to.

I would argue that BIDS is indeed the interface definition that allows effective decoupling between MRIQC and the input data in the filesystem.

I'm all for decoupling too :)

To view this discussion on the web visit https://groups.google.com/d/msgid/mriqc-users/4b410145-56e3-4b04-9e46-1dde7beec6dbn%40googlegroups.com.

[Zvi Baratz]

Thank you for clarifying, Oscar, and sorry for the delayed response (traveling ATM with family, come discuss in Amsterdam if you dare!). No question regarding BIDS important role in enabling the validation and automation of this process. I think the question is whether it could be possible to benefit from that while still enabling users to provide explicitly declared paths or even simply data to use, if they choose. IMO even if 99% of users use the BIDS-mediated workflow, this would still be worthwhile if only just in terms of architecture and robustness. In any case, it's just a bird's eye opinion derived for my relatively superficial understanding of the library, I'm sure you have a far better comprehension of what it actually entails and the potential advantages and disadvantages. 

To view this discussion on the web visit https://groups.google.com/d/msgid/mriqc-users/CAAsFcgy05LHJDqtk0OEGv47o2Zqe84jtV6_SOv-ajTcjLLLhjg%40mail.gmail.com.

[Oscar Esteban]

 Sure, totally get why allowing the flexibility of by-passing BIDS has its usefulness (and the particular case you were dealing with, Zvi, seems very reasonable). I'm pointing out that by-passing BIDS would increase coupling instead of decreasing it.

[zeit problem]

Hi,

 

I guess decoupling and how much and what does the trick might yield room for endless, even philosophic discussions :D

 

However, I tried to create a bids Directory with symlinks and am running into some issues. MRIQC is complaining that the .json and .nii files are missing. I created physical directories and linked the files. If I copy files instead of making the symlink, everything works. However, this is not the ideal solution. Do you have experience with the symlink solutin? Would be great to get this up and running :)

 

Best,

Ruben.

[Oscar Esteban]

> I guess decoupling and how much and what does the trick might yield room for endless, even philosophic discussions :D

(de)coupling has a very specific definition in Software Engineering (https://en.wikipedia.org/wiki/Coupling_(computer_programming)), based on the interdependency of software modules.

If MRIQC stops using BIDS as its i/o contract, then it would depend on some new code/set-of-heuristics to help it find the inputs and associated metadata. The ways Zvi, Ruben or Roman (I think he actually was the first to suggest this idea) would implement a new input interface are likely to be very different and, whichever the solution is (i.e., a submodule within MRIQC or an external, more general module) would require some agreement as to how the input data is organized (which is the problem solved by BIDS, and the very reason for BIDS to exist).

Rather than a philosophical discussion, this boils down to the maintenance burden, which would exponentially grow by allowing non-BIDS inputs (because of increased coupling and ranging user expectations on the new file organization/interface).

> However, I tried to create a bids Directory with symlinks and am running into some issues. MRIQC is complaining that the .json and .nii files are missing.

If MRIQC is complaining about that, in the most likelihood, that is the case ;)

Cheers,

oe

[zeit problem]

I agree with the maintenance burden, which is even higher in open-source communities since regular contributors are seldom. In general, I think that standards often improve these situations, as BIDS does. Just sometimes frustrating when one is working on established projects that have curated their file structure over the years. 

>  If MRIQC is complaining about that, in the most likelihood, that is the case ;)

Mhm, if I use shutils.copy() instead of os.symlink, everything works just well :D Maybe I need to rename the original files...