Mutability of AcquisitionHeader

[alexjaffray]

Hi all,

Just wanted to start a small discussion as I am questioning why the AcquisitionHeader is immutable.

In our use case of MRIReco.jl, we are using it for reconstruction of non-cartesian data acquired from Siemens and Philips scanners. We convert the raw data to ISMRMRD in order to use MRIReco.jl, however during the conversion there are some header parameters which are set arbitrarily and need to be adjusted post-conversion (this is especially true for spiral acquisitions). I do this by locally editing my MRIReco.jl code currently, but would like to avoid this in the future.

If the conversion from raw data to ISMRMRD was precise and specific, I would understand the need for the headers to be immutable, however given that the conversion can introduce arbitrary header parameters itself, I think it would be useful to make the AcquisitionHeader mutable until we have a more robust raw data conversion tool.

Thoughts?

[tknopp]

Have you tried changing and looked if the tests are passing? I don’t see a reason right now why it would not work.

[alexjaffray]

I have tried it and my results mirrored your own, the HDF5 calls in testBrukerFile.jl fail.

[tknopp]

Ok, I found the reason, why I made it this way. The reason is that we need to exactly replicate the memory layout when writing it to the HDF5 file. I just tried making it mutable and that failed.

So I think we definitely should make it mutable for allowing the use case of changing data. But we need a workaround for writing. In the worst case we can have the same type twice and simply convert from the mutable into the immutable variant.

[tknopp]

Just read your comment which apparently was not there when I was responding: Do you really need the EncodingCounters to be mutable as well? I think that will be more difficult.

[alexjaffray]

Great!

Regarding EncodingCounters, their mutability is probably less important for the general user, so I think there would be no immediate rush to address it. I agree, it would be more difficult to implement mutability.

However, as an example of why one might need to adjust the encoding counters, for diffusion imaging on a Siemens machine, I need to adjust the encoding counters for the following reasons:

1. Each diffusion direction after conversion to ISMRMRD is encoded as a repetition. This has bad implications for reconstruction. So, I need to go through and adjust the encoding counters such that each diffusion direction is encoded as a contrast, so I can properly reconstruct each direction.
2. If I have a multi-slice dataset that I want to reconstruct only one slice of due to computational restrictions, I need to set the slice field of the encoding counter to 0 otherwise there is an error thrown.
3. If I want to reconstruct an image using a subset of interleaves for a multi-shot acquisition, I have to manually adjust the encoding counter for the first kspace encoding step to go from 0 to one less than the number of interleaves I am reconstructing with. (This is a fairly specific use case of mine)

[tknopp]

6d40ef7

[alexjaffray]

Can confirm that the master branch works with my code without requiring any local modifications. All tests for the package pass as well. Thank you so much for the quick response and the commit @tknopp

[tknopp]

Your welcome. Feedback like yours is essential. When I wrote the ISMRMRD stuff I actually had exactly your use case in mind. With our infrastructure we could implement a very powerful MRI data converter.