AFNI Message Board

Dear AFNI users-

We are very pleased to announce that the new AFNI Message Board framework is up! Please join us at:

https://discuss.afni.nimh.nih.gov

Existing user accounts have been migrated, so returning users can login by requesting a password reset. New users can create accounts, as well, through a standard account creation process. Please note that these setup emails might initially go to spam folders (esp. for NIH users!), so please check those locations in the beginning.

The current Message Board discussion threads have been migrated to the new framework. The current Message Board will remain visible, but read-only, for a little while.

Sincerely, AFNI HQ

History of AFNI updates  

|
October 17, 2014 02:35PM
Peter's suggestion to find out where you want to go to is a good one. Additionally, I think there are a couple issues that are confusing. First, a display program *could* do the equivalent of "3dWarp -card2oblique". That is, it could match the obliquity of some layer dataset to match the obliquity of another and display each voxel at the corresponding real location. Freesurfer might do that, and that may be why it looks okay there without going through the separate warping step. The afni GUI doesn't do that though. Instead the original data is shown as if it were acquired on the closest cardinal grid (RAI,LPI, LSA,...). Although the voxel sizes are right, the absolute x,y,z locations are not the true ones. The original locations are rarely used or even useful, so that's usually not too bad, but it can be confusing.

The NIFTI datasets keep all the information about the orientation and obliquity in either the sform_code or the qform_code, so that's probably where freesurfer is getting that information. Once all datasets are aligned, you may want to remove any obliquity information from the header and assume the nearest cardinal orientation grid. That operation is done with "3drefit -deoblique" and should be applied only to those datasets that are aligned, and you are certain you will not need that information for future processing. I suspect that a similar procedure is done here on the Connectome data for similar reasons:

https://wiki.xnat.org/pages/viewpage.action?pageId=15171618
Subject Author Posted

3dAllineate and oblique data

Bonnie January 24, 2008 12:41PM

Re: 3dAllineate and oblique data

Daniel Glen January 24, 2008 02:01PM

Re: 3dAllineate and oblique data

Bonnie January 24, 2008 03:02PM

Re: 3dAllineate and oblique data

Bonnie January 24, 2008 03:18PM

Re: 3dAllineate and oblique data

Daniel Glen January 24, 2008 03:28PM

Re: 3dAllineate and oblique data

Bonnie January 24, 2008 05:10PM

Re: 3dAllineate and oblique data

Daniel Glen January 24, 2008 05:18PM

Re: 3dAllineate and oblique data

Bonnie January 28, 2008 04:38PM

Re: 3dAllineate and oblique data

Daniel Glen January 28, 2008 05:36PM

Re: 3dAllineate and oblique data

Bonnie January 29, 2008 03:26PM

Re: 3dAllineate and oblique data

Daniel Glen January 29, 2008 03:39PM

Re: 3dAllineate and oblique data

Bonnie January 30, 2008 03:35PM

Re: 3dAllineate and oblique data

Daniel Glen January 30, 2008 03:56PM

Re: 3dAllineate and oblique data

AjaySK October 17, 2014 01:56AM

Re: 3dAllineate and oblique data

Daniel Glen October 17, 2014 10:29AM

Re: 3dAllineate and oblique data

AjaySK October 17, 2014 11:41AM

Re: 3dAllineate and oblique data

AjaySK October 17, 2014 12:42PM

Re: 3dAllineate and oblique data

Daniel Glen October 17, 2014 02:35PM

Re: 3dAllineate and oblique data

AjaySK October 17, 2014 02:49PM

Re: 3dAllineate and oblique data

Daniel Glen October 17, 2014 01:30PM

Re: 3dAllineate and oblique data

Peter Molfese October 17, 2014 01:37PM

Re: 3dAllineate and oblique data

AjaySK October 17, 2014 02:46PM

Re: 3dAllineate and oblique data

Emmanuelle Renauld November 18, 2016 11:13AM

Re: 3dAllineate and oblique data

Daniel Glen November 29, 2016 03:10AM