Skip to content
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

Feature Request: Add option to spatially normalize new input datasets to a given pre-existing mean DTI template #17

Open
rachelsteiner opened this issue Aug 30, 2017 · 0 comments

Comments

@rachelsteiner
Copy link

Feature Request: Add option to spatially normalize new input individual DTI datasets to a given pre-existing mean DTI template that was either constructed using the preexisting DTIAtlasBuilder output or given manually, such as when registering to a publicly available population template of interest.

I imagine this will take the form of adding a line below optional reference template image for inputing an optional pre-existing final atlas DTI. If working with DTIAtlasBuilder output directories that are pre-existing, the input for existing DTI template line could auto populate to the path to the final atlas DTI file automatically when loading GUI. Otherwise, if no preexisting final atlas DTI output in DTIAtlasBuilder directory, could input manually the path to a publicly available population template to spatially normalize the input DTI data into.

If working with previous run of DTIAtlasBuilder's output, loading the GUI will auto-populate the input to what files are in the existing DTIAtlasBuilderDataset.csv. I'd like to add new input DTI files (the remaining subjects DTI from the larger cohort) to the list in in the first tab's GUI - not for constructing a new atlas or overwriting currently existing DTIAtlas output - but for requesting registration of the new input DTI files to the final atlas space. So can you limit the spatial normalization to only the new input DTI (whatever files not already present in the DTIAtlasBuilderDataset.csv file or where the tool's checkImage results in "originalDTI file does not exist!")?

The new input DTI data that will be selected for the processing option of "spatial normalization to preexisting DTI template only" will go through the same pre-processing so that all subjects will have the case*croppedDTI.nrrd as their original DTI handled the same way before registration to atlas: 1. filtering DTI with ResampleDTIlogEuclidean then 2. CropDTI for padding/cropping of the filtered DTI file. Next, I assume, would be to skip atlas building steps and probably just skip to re-running the "Second Resampling ... " with DTI-Reg to be run on the new input DTI data treated as moving volume (cases where the check for files indicates FinalTensors or FinalDeformations do not exist!) with fixed volume = pre-existing FinalAtlasDTI.nrrd from the current DTIAtlas output FinalAtlas directory. This would certainly benefit a large group analysis in terms of consistency in handling all individual DTI data preprocessing and in creating global displacement fields; outputting files with same naming conventions and image dimensions if CropDTI=1 will give original DTI files consistency in image sizing.

If working with a dataset that I wish to register to a publicly available DTI template, as one would with DTI-Reg, I would like to give the path to the pre-existing DTI file, then select an option to spatially normalize the new input DTI files to the given DTI template. (Filter the input DTI files, CropDTI the input files, then original DTI becomes case*croppedDTI.nrrd the same as in the current DTIAtlasBuilding workflow. Next, run DTI-Reg with fixed volume = to given population DTI template. Output is the concatenated aff + warp from Ants created by ITKTransformFields, just as the current pipeline works in the Second Resampling step.) Would this be a lot of work?

I was unsure if I should request a new tool to be developed for a GUI specialized for registering individual DTI data to a pre-existing DTI atlas within the UNC UTAH NAMIC Framework, but I thought it may be worthwhile to see if there was a natural way to fit the option within the pre-existing source code so my feature request comes from what may be a simple adaptation of pre-existing lines within the current ScriptWriter.cxx file. My goal is to have this potentially available for a technical report submission in October. Let me know how I can help.

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

1 participant