-
Notifications
You must be signed in to change notification settings - Fork 130
RF "IntendedFor" handling to allow flexible customization? #589
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
The issue of needing to assign |
Hi -- I don't want to clutter your brain dump, this seemed like a good place to chime in on some flexibility for the "IntendedFor" setting. I'm trying to use the "Shims" as the matching_parameters, but that isn't working for my data. I wonder if it's even possible with multiband or multiecho data (or sequences involving GRAPPA) because I think the scanner re-shims before each acquisition. Here's what my shim settings look like for my dataset:
We have some cases where the participant has to get out of the scanner in the middle of scan, and those cases understandably seem to be the cases where the ShimSetting is most different since the positioning is different. I wonder if there could be an added option for specifying some degree of accepted deviation from the ShimSetting? Thanks! |
I guess the only way would be some callback configuration which would allow anyone to decide the degree and ways on how to shoot them into the foot ;-) probably some like def is_compatible_for_fieldmap(meta:dict, fmap_meta: dict) -> bool
"Callback to go through the metadata fields (like `ShimSetting`) to make decision on either
current volume with `meta` is compatible with fieldmap givens its metadata in `fmap_meta`. someone would need to look at what metadata we have access at the point of doing all this logic... |
Just a brain dump:
In #554 @neurorepro is coming up with annotation within
reproin
sequence naming heuristic to identify "fieldmap ID" and "use this fieldmap ID" entities, @mirestrepo mentioned B0FieldIdentifier now present in BIDS, and currently in @pvelasco implementation we allow heuristics to define which of the supported "extracts" from DICOMs would constitute "an internal B0FieldIdentifier" record which then compared for exact match so no fancy shim values comparison is done/possible via allowing heuristics to definePOPULATE_INTENDED_FOR_OPTS
attribute within the heuristic listing the fields to take and how to resolve whenever multiple fieldmaps would match, e.g.So, I am thinking that we should allow for smth like
infotob0ident(info_record)
(we really need to streamline naming here ;)) which given an output frominfotodict
would output "something" which could be compared (now we are comparing thosematching_parameters
) , and possibly even has ad-hoc comparison implemented (so heuristics could provide some approximate matching to Shims values if so desired).The text was updated successfully, but these errors were encountered: