Open tknopp opened 2 years ago
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:
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.
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.)
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.
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.
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
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 properRawAcquisitionData
. Played around a little bit with it on theSplitPackage
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)