[BEP014] Open questions to resolve

[oesteban]

These questions were written on BEP014 before our conference call on 09/28/2018. Some of them were addressed in that call, and some may still be open. This ticket is here just to keep track of that conversation and open the contents of the call to the community:

Caveat to Spaces: Many software packages change the order of voxels or resolution of the standard templates. When the Space keyword refers to a key, it simply means that Questions to resolve:

1. Should we drop XXX before CoordinateSystem and CoordinateSystemUnits? It sounds like this is helping group some information. It would be useful to chat about this.
2. How should multiple coordinate systems associated with a file be represented? (e.g., NifTI, CIFTI, EEG + MEG) 2a. We discussed the idea of lists within spaces as example above
3. Should the CoordinateSystem key be mandatory?
4. How will CoordinateSystem metadata be represented, when a custom coordinate system is used?

[yarikoptic]

is BEP014 "merged"/DONE? google doc seems to say nothing about that, and I fail to find a PR mentioning BEP014

[effigies]

It has not been merged, although portions may have been covered in common derivatives or may need to be updated.

As I understand it, the main effort toward BEP014 for now is nitransforms, implementing the X5 transform format and providing converters for other tools. Once that's done, BIDS can standardize on X5. That's been on the back burner in recent months, but should pick back up next month as we start effort on the CZI grant.

[yarikoptic]

yet to look into X5, but just a note that transformations could be very much relevant virtually for any other modality (thus ni in nitransforms might need to "go"). In particular today the question came up in the scope of the microscopy BEP031: individual "chunks" (could be "slices" or "slabs" or just "3D blocks") might need to be accompanied with transformation into the "sample" (tissue sample of a particular subject) space. Those samples might later need to have transformation into the "subject" space. attn @jcohenadad @bids-standard/bep031 (TODO: https://github.com/bids-standard/bids-specification/issues/732)

[oesteban]

Sure, I'm not very concerned about branding (although, the first prototype of this tool was planned to go into nibabel - I doubt you want to suggest making it just babel).

In the future, this will probably require splitting cross-sectional elements (i.e., generalizable across modalities, specimens, populations, etc) and domain-specific.

X5 and transforms manipulation would pretty much be cross-sectional, but the I/O layer (i.e., opening and writing out from/to other formats - usual suspects, AFNI, ANTs/ITK, FS, FSL, SPM, etc) is pretty specific of the "ni" domain (with the exception of ITK via ANTS).

[yarikoptic]

I want to mention/back-reference related effort within OME-Zarr community:

• https://github.com/ome/ngff/issues/94 initiated by @bogovicj and with participation of our own @satra .

[oesteban]

@yarikoptic @satra how "chains" of transforms are defined in zarr? is it as flexible as HDF5?

[satra]

let me first clarify this is not zarr, but ome zarr. and given some of the types of data, this is a specification for zarr metadata to represent transforms rather than a container of transforms. in fact some of the nonlinear stuff was considered a link to an external store (could be another zarr file). i can't remember where the difference between sets (just named transforms) and chains (could be applied sequentially) lie (and of course their combination). pinging @josh-moore in case he remembers - but i don't think we got that far.