-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Fix and enhanced documentation #211
Comments
Regarding the interop with KomaMRI. @Stockless is currently working on incorporating parallel imaging (https://github.com/orgs/MagneticResonanceImaging/discussions/208), so we will definitely have examples of "simulationg with Koma" -> "Estimate coils sens from raw data (BARTIO/MRICoilSensitivities)" -> "Reconstruct with MRIReco" in our docs, but we are happy to put something in MRIReco as well. We could contribute a Literate or Pluto notebook example. Now that I saw We might want to include this in MRIBase? |
For flags, I have implemented them in uint64 no ? https://github.com/MagneticResonanceImaging/MRIReco.jl/blob/master/MRIBase/src/Datatypes/Flags.jl
|
Yes, but I think the problem is that the flags do not necessarily correspond to the required UInt64 mask if you do it like that (if I remember correctly). # "My method"
julia> const b64 = UInt64(1)
0x0000000000000001
julia> const ISMRMRD_ACQ_USER8 = 1b64 << ( 64 - 1 )
0x8000000000000000
# MRIReco
julia> flag::UInt64 = 64 # ACQ_USER8 in https://magneticresonanceimaging.github.io/MRIReco.jl/latest/acquisitionData/#flags
64
julia> flag
0x0000000000000040
julia> flag == ISMRMRD_ACQ_USER8
false Let me quickly check. |
The interface for flag is supposed to be with head = AcquisitionHeader()
traj = Matrix{Float32}(undef,0,0)
dat = Matrix{ComplexF32}(undef,0,0)
p = Profile(head,traj,dat)
const b64 = UInt64(1)
const ISMRMRD_ACQ_USER8 = 1b64 << ( 64 - 1 )
MRIBase.flag_set!(p,64)
p.head.flags == ISMRMRD_ACQ_USER8 Returns true. I don't know if we can force the user to not mess directly with the flags : |
Oh ok, didn't know My suggestion was to predefine the flags as the bit mask ( Edit: I guess this is copying how they do it in the ISMRMRD packages, at least a different |
It is something I have done last week. I can make the modification before we perform a release. Do you have a preferences between In ismrmrd the implementation is closer to and in gadgetron-matlab gadgetron.jl users flagsets.jl ... https://github.com/gadgetron/Gadgetron.jl/blob/main/src/Acquisition.jl and ismrmrd-python : https://github.com/ismrmrd/ismrmrd-python/blob/b93bc1bf351bfd949a73343da3547be58922b819/ismrmrd/constants.py#L21 |
We could keep both interfaces and add some type checking/sanity checks. Or we can just do the sanity checks. Since we defined the head type we can define our own setters for it. function setproperty!(head::AcquisitionHeader, name::Symbol, value)
if name == :flags
throw(TypeError("Flags can only be directly set with UInt64 or with `flag_set!", UInt64, value))
else
setfield!(head, name, convert(fieldtype(head, name), value))
end
end
setproperty!(head::AcquisitionHeader, name::Symbol, value::UInt64) = setfield!(head, name, convert(fieldtype(head, name), value)) I don't have a strong preference between If we go with both interfaces, we could also add a utility function for |
To fix :
To add :
Do you have more ideas ?
Should we try to run most of the example during the CI and perform a doctest if it fails ?
The text was updated successfully, but these errors were encountered: