Status of BEP014 regarding spaces and mappings

[ghisvail]

As part of our efforts to improve Clinica's standardization towards BIDS, we are in a need for an update on where BEP014 is at and whether the proposed naming scheme will be subject to changes.

From what I understand there is a separate effort to propose a common file format for all transforms (X5 I believe?), which BIDS might standardize on. Since tooling (like FSL or ANTs) will take time to catch on (if ever), we would likely keep storing transforms in their native formats for now.

Could you please confirm whether BEP014 can be considered stable enough as it is (modulo the work on X5)?

[sappelhoff]

According to https://bids.neuroimaging.io/get_involved.html @oesteban leads this effort.

[oesteban]

Could you please confirm whether BEP014 can be considered stable enough as it is (modulo the work on X5)?

BEP014 currently provides a naming scheme that has been used successfully with fMRIPrep for about five years now. Meaning, it seems that the from-, to- and mode- entities have been pretty successful in unambiguously identifying transforms within the scope of medium-scale complexity workflows. That is, without X5, therefore using the original software file formats.

From what I understand there is a separate effort to propose a common file format for all transforms (X5 I believe?), which BIDS might standardize on. Since tooling (like FSL or ANTs) will take time to catch on (if ever), we would likely keep storing transforms in their native formats for now.

This is correct. We have been piloting this with the NiTransforms project, which is scheduled to be integrated within NiBabel at some point before the end of next Summer. At the moment of writing, the support of nitransforms is quite wide in terms of existing software support (i.e., virtually all linear transforms for volumes and a good bunch of nonlinear transforms -- FSL and ITK displacements fields, ITK B-Splines fields). NiTransforms oughts to support X5 but development there is lagging.

So, if you could help in any capacity to step NiTransforms forward, that would be awesome and bring the time when we can write clean X5 transforms ahead. If that's not possible or the plan, then, I guess we can call BEP014 as mature enough to store existing software files.

[ghisvail]

So, if you could help in any capacity to step NiTransforms forward, that would be awesome and bring the time when we can write clean X5 transforms ahead. If that's not possible or the plan, then, I guess we can call BEP014 as mature enough to store existing software files.

I like the goal for a unified format for storing arbitrary transforms. However, Clinica remains reliant on third-party tooling each with their own specifications for transformations files (you've named them already).

I guess supporting X5 via nitransforms would mean prefixing and postfixing each call to FSL or ANTs with an appropriate conversion step ? If so, that would be rather impractical for us as of today.

I guess we can call BEP014 as mature enough to store existing software files.

Are there any plans to submit BEP014 for existing file formats, and later introduce X5 as the recommended standards once ready?

[oesteban]

I like the goal for a unified format for storing arbitrary transforms. However, Clinica remains reliant on third-party tooling each with their own specifications for transformations files (you've named them already).

Perhaps my answer was not clear. Currently, X5 is not an option because it is planned for implementation within NiTransforms but definitely not done. Anyone joining this effort would be great to push it forward.

What I meant is that, if your project must start writing these files as they come from software (instead of X5) today, then the only option is following BEP014 as it stands now - which has been sufficient for fMRIPrep at least.

Are there any plans to submit BEP014 for existing file formats, and later introduce X5 as the recommended standards once ready?

The final reading will likely allow existing file formats but strongly recommend X5. This is to say, implicitly, at the moment the BEP had some traction we understood that a pilot of the X5 was necessary to go along with the BEP to be approved. So I guess, the answer would be now, the plan was to push altogether as a whole (i.e., including X5 and a pilot implementation to make it realizable).