Closed ckolbPTB closed 2 months ago
Coverage Report
Tests | Skipped | Failures | Errors | Time |
---|---|---|---|---|
762 | 0 :zzz: | 0 :x: | 0 :fire: | 1m 10s :stopwatch: |
Coverage Report
Tests | Skipped | Failures | Errors | Time |
---|---|---|---|---|
751 | 0 :zzz: | 0 :x: | 0 :fire: | 1m 9s :stopwatch: |
My idea was to keep these somewhat simple and opinionated, as there is always the possibility to just the the reconstruction manually.
Also, the reconstruction can be initiated using the init with any csm.
I would oppose to having a if switch in from_kdata. Either do dependency inversion and allow to supply the CSM function somewhere. I would like to not have string literals to switch between different functionality.
Or just use the init, and have from_kdata choose some sensible defaults.
This PR moves in the wrong direction imho, as it blurs the lines between the different "levels" of how to do the reconstruction with mrpro.
Gesendet von Outlook für Androidhttps://aka.ms/AAb9ysg
From: Christoph Kolbitsch @.> Sent: Friday, August 2, 2024 9:03:57 PM To: PTB-MR/mrpro @.> Cc: Subscribed @.***> Subject: [PTB-MR/mrpro] Adapt it sense functions (PR #379)
Here I changed the from_kdata such that also a CsmData can be provided and it is more flexible how the CsmData is calculated (assuming we will have espirit, inati... in the future). Especially for IterativeSENSE we probably will calculate the CSM before calling from_kdata.
I also separted the forward from creating H and b. Having one single function which returns (H, b) together would save a bit of duplicate code. Not sure which version I prefer...
You can view, comment on, or merge this pull request online at:
https://github.com/PTB-MR/mrpro/pull/379
Commit Summary
File Changes
(2 fileshttps://github.com/PTB-MR/mrpro/pull/379/files)
Patch Links:
— Reply to this email directly, view it on GitHubhttps://github.com/PTB-MR/mrpro/pull/379, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABH3DVZLFEFJIZJDX6R5SA3ZPPJZ3AVCNFSM6AAAAABL5B4JNCVHI2DSMVQWIX3LMV43ASLTON2WKOZSGQ2DKNJZGQ4DGMY. You are receiving this because you are subscribed to this thread.Message ID: @.***>
Also, the reconstruction can be initiated using the init with any csm.
True, but I find from_kdata
a very useful function and I would like to utilise it also as best as possible for the iterative reconstructions. Especially as we will also have to add CartesianSamplingOp
the __init__
of each reconstruction if we want to enable Cartesian reconstructions.
One other option would be to leave DirectReconstruction.from_kdata()
as it was before and change IterativeSENSEReconstruction.from_kdata(kdata: KData, csm: CsmData | None, noise: KNoise | None, n_iteartions: int)
, i.e. CSM needs to be provided. IMO this is the most useful case for this iterative recon.
Just to summarize the discussion: The init should now have an additional argument kdata. If kdata is specified and none of the other arguments are specified, the former from_kdata logic should apply and everything should be estimated from kdata. If, for example, a fourieroperator is given, it will be used instead. If neither kdata nor a fouriroperator is given, an error is raised.
(I think @ckolbPTB already implementedthis in the last commits..)
Here I changed the
from_kdata
such that also aCsmData
can be provided and it is more flexible how theCsmData
is calculated (assuming we will have espirit, inati... in the future). Especially for IterativeSENSE we probably will calculate the CSM before callingfrom_kdata
.I also separted the
forward
from creatingH
andb
. Having one single function which returns(H, b)
together would save a bit of duplicate code. Not sure which version I prefer...