Dear Sam, The native images live in one space (typically anisotropic), whereas the recon-all-clinical files always live in their own 1x1x1mm isotropic grid (which is the whole point!). I am not familiar with the Enigma QC procedure but I wouldn’t be surprised if it’s not compatible with these variable image spacings. As a hack, you could maybe try running mri_convert native.mgz native.resampled.mgz -rl aseg.mgz, to obtain a (resampled) input scan in the same voxel space as the outputs? Cheers, /Eugenio
-- Juan Eugenio Iglesias http://www.jeiglesias.com From: freesurfer-boun...@nmr.mgh.harvard.edu <freesurfer-boun...@nmr.mgh.harvard.edu> on behalf of Sam Sievertsen <sam...@uw.edu> Date: Friday, April 5, 2024 at 11:43 AM To: freesurfer@nmr.mgh.harvard.edu <freesurfer@nmr.mgh.harvard.edu> Subject: [Freesurfer] Recon-All Clinical Stream: Image Output Observations in Creating ENIGMA QC Images External Email - Use Caution Good Afternoon, I hope this email finds you well! My name is Sam Sievertsen, the research coordinator for Dr. Jennifer Forsyth at the University of Washington. We are utilizing the recon-all clinical processing stream from FreeSurfer 7.4.1 on Rocky Linux (within our institutions HPC environment) to process subjects with decreased T1 image quality, and for whom previously processing with the standard recon-all pipeline resulted in missed grey matter during segmentation. Per recommendations in the bug reporting page, I have attached an example recon-all clinical log from this processing in case it is helpful. Following the recon-all clinical processing of these subjects, we are using an existing (ENIGMA cortical QC) pipeline to take screenshots of the external cortical reconstruction<https://secure-web.cisco.com/19i9TSlgNlNnONXLIpqTWX3BCSsnOf-EugV08XsKq72OGsXI7OeYZPf6CqMrvDWAtomUiRFZispIdIZdo9F9SRO3vZL2DV1TkzQpfw6DjK0e7JR8mz4AoTR-papqbzRrkdgPbPDqF2uoVbzJ0L42bCbyFrsf3aIEqbZXVMVFiDooF-J1jxxtF9_dfZFzE0jCwDqb4fw9c-Ls2LJMzqTriaB0ra6YwyMhWrnMB5p0zH0oUUjH6EVuvKf5QGukFG_JWwNBN6egozwsfQLYhSj_2V_loamyo3Q9IbxaTFpbPGg17GYxj276uYTJC7wEaCx_JhhnbRJl7OvgVZc_g_n-_sQ/https%3A%2F%2Fgithub.com%2FENIGMA-git%2FENIGMA-FreeSurfer-protocol%2Fblob%2Fmain%2FENIGMA_QC%2FFS_external_QC.m> / aparc+aseg segmentation overlaid on internal images<https://secure-web.cisco.com/13TQ3PwQQ9BI4s2aBpZBhunwgJsJT6-yH3IIqx3cliLqe4_j1r1TZqHTHUdMnnYC23aHf7OClxHdaKsQpsGu25-Suf2wTo6iSj05UvMg4l1dgJFNKkQ9LZlEoNktxRPcD7f88KnWtK5W32jCoCfjgsQOPkdQJU90XrFfd8epMu37q0oRors8xn8f_kjzhE90k3SGE8TOmrckpzoi8YmLW6fYzEHg0Yq4ExvKaTwRMlagWQDkrPu5cCD9--5hMIDrrNmuJeUT95LLohgPHnZDBnRARyjosNkxkisaDxndE-HR9Bv24P2K88Mclo062Ethd18652PaqOOJ7dDKAxgXxyA/https%3A%2F%2Fgithub.com%2FENIGMA-git%2FENIGMA-FreeSurfer-protocol%2Ftree%2Fmain%2FENIGMA_QC>. We are able to successfully generate external (reconstruction) cortical QC images using the recon-all clinical output, but encounter an error when attempting to generate the internal (T1 with aparc+aseg.mgz overlay) QC images. Specifically, there is a conditional check within the internal QC image generation script linked above that halts the process if the Nx*Ny*Nz dimensions in the T1 image and the Nx*Ny*Nz dimensions in aparc+aseg.mgz do not align, which is where our process is throwing the error. Manual examination of the recon-all clinical image output (e.g., "native.mgz", "synthSR.norm.mgz", and "aparc+aseg.mgz") suggests that the aforementioned dimensions are all different in those images. Conversely, the dimensions in the processed images and segmentations (e.g., "orig_nu.mgz", "aparc+aseg.mgz") from the standard recon-all pipeline appear to be uniform (256) for those same subjects we are processing in this cohort. To hopefully assist with clarity, I have attached the script we are using ("func_make_corticalpngs_ENIGMA_QC.m") to construct these internal QC images, and example output files from the same subject using the standard recon-all pipeline output ("internalQC_standard_recon_all.txt") and recon-all clinical pipeline output ("internalQC_recon_all_clinical.txt"), which show a discrepancy in the aforementioned dimensions. Following up on the above information, I am wondering if "SynthSeg: to obtain a volumetric segmentation and linear registration to Talairach space"on the recon-all clinical page<https://secure-web.cisco.com/1ysMZeQggBLaLzKrZvbENqA_ienVNIRzPan5TKDtzxTjvk1NcXUtXEaFDTgh8vL6P2wf45rocLhoqBQg5KZ5-5dIbF8E6BYxv7fSXMYNrqG7nxwL7YMX9gRhEQf2MmbnM71j_ru-KHFNjoON70LDVAgGbxFZDRA_KWZjdPAahINoi4PkjjHOhCJ4wStvfqj-b2oQyrgw5E2iQMrj3SVy4mHFy8iwKYp7ul_PIvECdpjQIdZtaVLwAfNDaiaQXIzg2EG9_qlV1g1LKp92qpcp5bX2ZgcVIWPwG3HxbxzTheR4_R-1l06hjz4DLYeej2_lcJs7L5ZF_3kesE5QAToBiaQ/https%3A%2F%2Fsurfer.nmr.mgh.harvard.edu%2Ffswiki%2Frecon-all-clinical> about registration to talairach space implies that the recon-all clinical output should have uniform dimensions, or if I am misunderstanding that and there is anything that stands out from this description that we may be doing incorrectly/that other users have encountered as well? Would also be very appreciative of any other suggestions you may have for attempting to troubleshoot this issue, thank you very much in advance for your time! Happy to answer any resulting questions or follow up with additional information should it be helpful. All the best, Sam Sievertsen Research Coordinator I Department of Psychology, GRaND Lab [Image removed by sender. logo] [Image removed by sender.]
_______________________________________________ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Mass General Brigham Compliance HelpLine at https://www.massgeneralbrigham.org/complianceline <https://www.massgeneralbrigham.org/complianceline> . Please note that this e-mail is not secure (encrypted). If you do not wish to continue communication over unencrypted e-mail, please notify the sender of this message immediately. Continuing to send or respond to e-mail after receiving this message means you understand and accept this risk and wish to continue to communicate over unencrypted e-mail.