Skip to content

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

Open
yarikoptic opened this issue Sep 1, 2022 · 3 comments
Open

RF "IntendedFor" handling to allow flexible customization? #589

yarikoptic opened this issue Sep 1, 2022 · 3 comments

Comments

@yarikoptic
Copy link
Member

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 define POPULATE_INTENDED_FOR_OPTS attribute within the heuristic listing the fields to take and how to resolve whenever multiple fieldmaps would match, e.g.

POPULATE_INTENDED_FOR_OPTS = {
    'matching_parameters': ['ImagingVolume', 'Shims'],
    'criterion': 'Closest'
}

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 from infotodict would output "something" which could be compared (now we are comparing those matching_parameters) , and possibly even has ad-hoc comparison implemented (so heuristics could provide some approximate matching to Shims values if so desired).

@yarikoptic
Copy link
Member Author

The issue of needing to assign B0FieldIdentifier (along with B0FieldSource? @dnkennedy said that he did not need it to get fmriprep/babies to work) came up also in dialog with @dnkennedy who had to assign it manually.

@DVSneuro
Copy link

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:


(base) tug87422@cla18994:/ZPOOL/data/projects/rf1-mbme-pilot/bids/sub-10363$ for j in `ls */*.json`; do python printShimSetting.py $j ; done
anat/sub-10363_T1w.json [1436, -7424, 6461, 226, -44, -221, -160, 47]
fmap/sub-10363_acq-bold_run-1_magnitude1.json [1435, -7406, 6461, 318, -30, 17, -154, 53]
fmap/sub-10363_acq-bold_run-1_magnitude2.json [1435, -7406, 6461, 318, -30, 17, -154, 53]
fmap/sub-10363_acq-bold_run-1_phasediff.json [1435, -7406, 6461, 318, -30, 17, -154, 53]
fmap/sub-10363_acq-bold_run-2_magnitude1.json [1435, -7406, 6461, 318, -30, 17, -154, 53]
fmap/sub-10363_acq-bold_run-2_magnitude2.json [1435, -7406, 6461, 318, -30, 17, -154, 53]
fmap/sub-10363_acq-bold_run-2_phasediff.json [1435, -7406, 6461, 318, -30, 17, -154, 53]
func/sub-10363_task-sharedreward_acq-mb1me1_bold.json [1434, -7403, 6464, 353, -38, 64, -160, 54]
func/sub-10363_task-sharedreward_acq-mb1me4_echo-1_bold.json [1434, -7402, 6466, 358, -44, 86, -162, 58]
func/sub-10363_task-sharedreward_acq-mb1me4_echo-2_bold.json [1434, -7402, 6466, 358, -44, 86, -162, 58]
func/sub-10363_task-sharedreward_acq-mb1me4_echo-3_bold.json [1434, -7402, 6466, 358, -44, 86, -162, 58]
func/sub-10363_task-sharedreward_acq-mb1me4_echo-4_bold.json [1434, -7402, 6466, 358, -44, 86, -162, 58]
func/sub-10363_task-sharedreward_acq-mb3me1_bold.json [1434, -7403, 6464, 353, -38, 64, -160, 54]
func/sub-10363_task-sharedreward_acq-mb3me1_sbref.json [1434, -7403, 6464, 353, -38, 64, -160, 54]
func/sub-10363_task-sharedreward_acq-mb3me4_echo-1_bold.json [1434, -7403, 6464, 353, -38, 64, -160, 54]
func/sub-10363_task-sharedreward_acq-mb3me4_echo-1_part-mag_sbref.json [1434, -7403, 6464, 353, -38, 64, -160, 54]
func/sub-10363_task-sharedreward_acq-mb3me4_echo-1_part-phase_sbref.json [1434, -7403, 6464, 353, -38, 64, -160, 54]
func/sub-10363_task-sharedreward_acq-mb3me4_echo-2_bold.json [1434, -7403, 6464, 353, -38, 64, -160, 54]
func/sub-10363_task-sharedreward_acq-mb3me4_echo-2_part-mag_sbref.json [1434, -7403, 6464, 353, -38, 64, -160, 54]
func/sub-10363_task-sharedreward_acq-mb3me4_echo-2_part-phase_sbref.json [1434, -7403, 6464, 353, -38, 64, -160, 54]
func/sub-10363_task-sharedreward_acq-mb3me4_echo-3_bold.json [1434, -7403, 6464, 353, -38, 64, -160, 54]
func/sub-10363_task-sharedreward_acq-mb3me4_echo-3_part-mag_sbref.json [1434, -7403, 6464, 353, -38, 64, -160, 54]
func/sub-10363_task-sharedreward_acq-mb3me4_echo-3_part-phase_sbref.json [1434, -7403, 6464, 353, -38, 64, -160, 54]
func/sub-10363_task-sharedreward_acq-mb3me4_echo-4_bold.json [1434, -7403, 6464, 353, -38, 64, -160, 54]
func/sub-10363_task-sharedreward_acq-mb3me4_echo-4_part-mag_sbref.json [1434, -7403, 6464, 353, -38, 64, -160, 54]
func/sub-10363_task-sharedreward_acq-mb3me4_echo-4_part-phase_sbref.json [1434, -7403, 6464, 353, -38, 64, -160, 54]
func/sub-10363_task-sharedreward_acq-mb6me1_bold.json [1435, -7406, 6461, 318, -30, 17, -154, 53]
func/sub-10363_task-sharedreward_acq-mb6me1_sbref.json [1435, -7406, 6461, 318, -30, 17, -154, 53]
func/sub-10363_task-sharedreward_acq-mb6me4_echo-1_bold.json [1435, -7406, 6461, 318, -30, 17, -154, 53]
func/sub-10363_task-sharedreward_acq-mb6me4_echo-1_part-mag_sbref.json [1435, -7406, 6461, 318, -30, 17, -154, 53]
func/sub-10363_task-sharedreward_acq-mb6me4_echo-1_part-phase_sbref.json [1435, -7406, 6461, 318, -30, 17, -154, 53]
func/sub-10363_task-sharedreward_acq-mb6me4_echo-2_bold.json [1435, -7406, 6461, 318, -30, 17, -154, 53]
func/sub-10363_task-sharedreward_acq-mb6me4_echo-2_part-mag_sbref.json [1435, -7406, 6461, 318, -30, 17, -154, 53]
func/sub-10363_task-sharedreward_acq-mb6me4_echo-2_part-phase_sbref.json [1435, -7406, 6461, 318, -30, 17, -154, 53]
func/sub-10363_task-sharedreward_acq-mb6me4_echo-3_bold.json [1435, -7406, 6461, 318, -30, 17, -154, 53]
func/sub-10363_task-sharedreward_acq-mb6me4_echo-3_part-mag_sbref.json [1435, -7406, 6461, 318, -30, 17, -154, 53]
func/sub-10363_task-sharedreward_acq-mb6me4_echo-3_part-phase_sbref.json [1435, -7406, 6461, 318, -30, 17, -154, 53]
func/sub-10363_task-sharedreward_acq-mb6me4_echo-4_bold.json [1435, -7406, 6461, 318, -30, 17, -154, 53]
func/sub-10363_task-sharedreward_acq-mb6me4_echo-4_part-mag_sbref.json [1435, -7406, 6461, 318, -30, 17, -154, 53]
func/sub-10363_task-sharedreward_acq-mb6me4_echo-4_part-phase_sbref.json [1435, -7406, 6461, 318, -30, 17, -154, 53]

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!
David

@yarikoptic
Copy link
Member Author

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...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants