Code/pipeline review #9
Conversation
| @@ -146,6 +147,7 @@ def process_run(name_source, layout, run_data, out_dir, temp_dir): | |||
| concat_ihmt_file = os.path.join(temp_dir, f'concat_{name_base}') | |||
| concat_ihmt_img.to_filename(concat_ihmt_file) | |||
|
|
|||
| # How many volumes are in ihmt? | |||
There was a problem hiding this comment.
There are five volumes with different contrasts. I took the dwidenoise step from ihmt_proc.
| # There is a final step here that has to happen, which is you average together | ||
| # all the transforms and apply the inverse to the template. | ||
| # This prevents the template from drifting. | ||
| # See https://github.com/PennLINC/qsiprep/blob/c74ff2f041a9ff6121042d30b5467af6082be85f/qsiprep/workflows/dwi/hmc.py#L273 |
There was a problem hiding this comment.
Could you expand on this? I think this might be one spot where QSIPrep's approach and ihmt_proc's differ. The template is only recalculated with a voxel-wise average, so I don't think there's any opportunity for it to drift.
There was a problem hiding this comment.
It currently won't be an issue here because you're only doing a single iteration. If there were multiple iterations, it's possible that the template brain will move around in the FOV. The workflow in qsiprep is based on the antsMultivariateTemplateConstruction.sh script, where a couple iterations are always used. If there is a lot of motion the first average won't look very good, so the registrations to it will still have some error. Over the multiple iterations the template starts to converge to something nice.
I'm not sure if multiple iterations is overkill here. It would depend on how much motion you expect over these volumes.
There was a problem hiding this comment.
The method in ihmt_proc only runs it once. I think it should be fine, but we can revisit and apply a multi-iteration method if it doesn't work well.
| # What do you think about making a project-wide setting for what to do with calculations that | ||
| # involve division? It's an unstable operation and we should handle it consistently. |
There was a problem hiding this comment.
One of the problems with T1/T2 "myelin maps" is that if the denominator gets close to zero you get extreme numbers. I was imagining something like a config setting for what to do when there is a division and you see extreme values. For example, if some voxels are inf or extreme outliers, should they be capped? Or set to nan? Or should we leave them as is? It makes sense that if we offer this option for one of the calculations that we should offer it for all of them.
| # Is there an advantage to keeping ihmt_files_t1space as a list? | ||
| # It's less intuitive than using variables |
There was a problem hiding this comment.
I wanted to loop over the images, but there are more intuitive ways like you said. Maybe a dictionary so it's still easier to organize the image types in a single variable I can index?
I'm adding some comments for discussion