Native Siemens Reader

[tknopp]

During the restructuring (#72) I am looking a little bit how much effort it would be to read siemens files natively.

There seem to be the following packages:

https://github.com/ismrmrd/siemens_to_ismrmrd
https://github.com/wtclarke/pymapvbvd

Does anybody know, which of the ones has more functionality, i.e. less limitations? I lean towards the siemens_to_ismrmrd since it basically gives us for free the ability to derive a proper RawAcquisitionData. Played around a little bit with it on the SplitPackage branch:
https://github.com/MagneticResonanceImaging/MRIReco.jl/tree/SplitPackage/MRIFileIO/src/Siemens
Nothing serious yet, just playing around.

Making a rather mechanical translation of siemens_to_ismrmrd would have the side advantage that one can compare codes later on and fix bugs in both projects.

(ping @JakobAsslaender since you raised interested in a native siemens reader)

[JakobAsslaender]

Wow, thanks for starting to look into this! There is also the package

https://github.com/pehses/twixtools

It is written by @pehses, who also wrote the Matlab toolbox mapVBVD, which is arguably the most-used package to read Siemens twix files. I cannot comment on siemens_to_ismrmrd, but both pymapvbvd and twixtools have two essential features:

1. load the entire header as a struct / dictionary
2. allow for slicing, i.e. to load only part of the data

I guess the way to store the header information is very language specific. If there is some searchable format in Julia? Comparing pymapvbvd and twixtools, the former seems to be faster--no idea why. In Julia, we can maybe use

https://github.com/BioJulia/BufferedStreams.jl

which substantially sped up the loading of some NMR data in some rudimentary code I once wrote; especially when loading from a network drive.

[tknopp]

Very interesting. Is sliced loading an important design criterion? We do this in our sister package MPIFiles.jl but right now MRIFileIO.jl is not designed to work like this. However, this is not set in stone and can be fixed, if there are use cases for it. If we tackle that, then for all files, not just siemens.

(In MPIFiles.jl we are using mmap for this purpose and it works like a charm. Both with BrukerFiles and our HDF5-based MPI file format (MDF). So technically this is straight forward, it is rather an interface question to be sorted out.)

[JakobAsslaender]

I personally don't use it a lot since I am a 3D kinda guy. But in particular if you do multi-slice imaging and have limited memory / don't want to wait forever, it is very useful if you can just load the data that you need--which can be at the order of 1% of the total file size.

[alexjaffray]

sliced loading would be very helpful, especially for diffusion imaging. At the moment, I actually work around the lack of this feature in our reconstruction pipeline with @mrikasper by manually adjusting the acquisitionData structure to only contain a single slice.

[mrikasper]

Thanks for looping me in, @alexjaffray , I agree with you that sliced loading would be very helpful, also to get a basic reconstruction up and running, where one typically uses a single slice to test things.

Being new to the Siemens world, I can second @JakobAsslaender in that mapVBVD seems to be ubiquitous and much more widespread in use than siemens_to_ismrmrd. But maybe @gadgetron people have more insight here, or companies who use it: see, e.g., https://github.com/SkopeMagneticResonanceTechnologies/siemens_to_ismrmrd, which has branched off quite a bit from the initial ISMRMRD converter, it seems. Chris Mirkes would know more (@cmirkes).

There are some idiosyncrasies in the siemens_to_ismrmrd code that wouldn't warrant a mechanical translation, e.g., when a trajectory is specified as "spiral", it automatically re-calculates the nodes of the trajectory given a specific parameterization of variable density spirals (based on Brian Hargreaves' work) that is implementation-dependent on the pulse programming side, but not standard Siemens.

All the best,
Lars