maintain crosshair in gui when switching between views (tlrc to orig)

AFNI version info (afni -ver): 24.0.01

In previous AFNI versions, I was able to toggle between the tlrc and orig views in the gui, as long as both the overlay and underlay had +orig and +tlrc datasets in the directory (i.e., MPRAGE_ns as both the overlay and the underlay, as there is a MPRAGE_ns+orig and MPRAGE_ns+tlrc), and the crosshairs would keep fixed on the same brain location. The purpose of this is to use InstaCorr to identify specific locations with robust seed-based connectivity, and then record both the tlrc and the orig coordinates. In this latest build, the crosshair changes to a totally new brain region when switching between tlrc and orig.

Is this "stabilized crosshair" feature lost with the newer AFNI builds?

Hmmm. If I open an afni controller with anat_ns and to go to tlrc view, and then open a "New" controller with the same underlay and run instacorr in it, the location is stable in the original "A" controller, but messed up in the "B" controller with instacorr.

We will have to ponder this. But you should at least be able to do what you want by using the non-instacorr controller to jump between the views.

Does that work?

Thanks,

  • rick

Cool - I'll play around with that suggestion.

Could it be related to whether or not the data is de-obliqued (and when, in the preprocessing)?

Thanks for your attention to this!

A few comments and suggestions regarding this issue:

  1. The automatic warp on demand capability applies only to data that has only been affine transformed. That requires an affine warp to be present in the header of the dataset. The warp comes from either the dataset itself or from the first anatomical dataset in the session directory that contains an anatomical warp.

  2. If the data has been processed with obliquity in a separate step, that won't be included in the warp in the header, I believe, so that functionality may not be useful for you.

  3. My quick testing found that InstaCorr works with some limitations. InstaCorr allows selection of datasets in the same view as the underlay. I didn't see a difference in A or B controllers. If the underlay is +orig, then the dataset selection must be +orig view also (or equivalent NIFTI sform/qform code); similiarly for +tlrc views. InstaCorr proceeds with normal interaction. Switching between orig and tlrc views does move the crosshairs using the affine warp in the header of the anat dataset, but InstaCorr is no longer updated with mouse clicks. Switching the view back allows for resetting the InstaCorr setup though. Normally, starting in a particular view and then going to InstaCorr setup will not allow a dataset selection if there is no valid dataset view of that view in the directory. However going back into the setup after switching views, unfortunately, allows it because the menu has already been populated with the dataset of the opposite view. Applying the wrong view then causes a crash.

  4. Nonlinear transformations. Nowadays, we typically recommend using nonlinear alignment. These are usually composed of a nonlinear warp transformation and an affine part. These are now slow to compute, so we don't have any warp-on-demand capability for that. Computing coordinates between orig native space and the template space can be done with 3dNwarpXYZ as in this example:

3dNwarpXYZ -nwarp ‘anatQQ.WARP.nii anatQQ.aff12.1D’  [-iwarp] testxyz.1D

where testxyz.1D has a list of xyz coordinates in RAI (DICOM order - right to left, anterior to posterior, inferior to superior). The -iwarp option can be added if if going from the native space to the standard space. Check the directions and the results by looking at the resulting locations on the anatomical data.

  1. Vecwarp works similarly for applying affine warps backward or forwards to sets of xyz coordinates.

Coordinate conversion between native and standard spaces has important uses in clinical and surgical applications, but you have to be very careful on how these are computed. Overall, the warp-on-demand feature is a little too mysterious, so I would avoid relying on it. Nonlinear alignment makes that feature less relevant to most processing pipelines, but scripting with 3dNwarpXYZ is a better alternative.

Hi Daniel,

The issue comes after running InstaCorr. The test (assuming say, you have run s05.ap.uber and have an FT.results output directory):

a. set Underlay to FT_anat_ns, and find some anatomically interesting landmark
b. switch between Talairach and Original Views - all is well, we are still ~at the landmark
c. open a new 'afni' session or even a "New" controllor B
d. in B: set Underlay again to FT_anat_ns, and switch to Talairach View (all is well)
e. B: SetupICorr, using errts+tlrc, for example, and actually make a correlation image
f. B: switch to Original View ====> bad coordinates

It is strange that this seems to happen in the context of InstaCorr.

  • rick

I see. I do get that same behavior on my system. It's interesting the A controller can still be switched to orig view while the B controller is in tlrc view and shows the approximately correct coordinate.

Even without doing InstaCorr I run into this issue.

I am running afni_proc.py, using the TT_N7 as the template. I have MPRAGE_ns+tlrc and MPRAGE_ns+orig in my directory. When I open this dataset in the GUI, it does not maintain fixation on the same brain location when switching between original and talairach view. I'm using the MPRAGE_ns as both the underlay and the overlay to ensure that afni gui does not crash. This is without running InstaCorr, just trying to toggle between views.

In the past (ie 2014 afni versions), I was able to do this. I used it to run InstaCorr in +tlrc view, identify a coordinate with robust seed-based connectivity, record the tlrc coordinate of the "voxel of interest". I would then make the MPRAGE_ns the overlay (thus, closing the InstaCorr results), so that I could toggle between +tlrc and +orig views in order to record the +orig coordinate of that "voxel of interest" that corresponded to the +tlrc voxel that was identified in +tlrc view via InstaCorr.

I suppose if this feature is lost, then I could save a 2mm sphere mask at the tlrc "voxel of interest" and then transform that sphere mask into +orig space, and then obtain it's coordinates.

Hi again,

Following up with this. I tried creating a 2mm sphere at the voxel of interest in tlrc space:

echo "-44 -65 26" | 3dUndump -orient LPI -srad 2 -master MPRAGE_ns+tlrc -prefix coord_tlrc+tlrc -xyz -

and then transformed it to orig space:

3dresample -master MPRAGE_ns+orig -input coord_tlrc+tlrc -prefix coord_orig+orig

I confirmed that the tlrc space (MPRAGE_ns+tlrc underlay with the coord_tlrc+tlrc) shows the sphere in the correct brain area, but in orig space (MPRAGE_ns+orig underlay with coord_orig+orig) shows the sphere a few mm away from the actual place. The discrepancy is similar to the coordinate discrepancy when toggling between orig and tlrc view, without any overlay.

It seems something is funky in the transforming from tlrc back to orig space. Any idea what may be going on?

In this preprocessed data, I ran 3dWarp -deoblique on the MPRAGE (immediatley after running dcm2niix_afni) and 3dWarp -deoblique on the functional run (after 3dTshift). I am now running preprocessing without these two 3dWarp commands to see if this helps resolve the issue. I'd appreciate any other advice!

Thanks!

3dresample is not the right command for this transformation. That's used for interpolating from one grid to another without a spatial transformation. For affinely transformed data, you can use 3dAllineate (or adwarp,3dWarp) to apply a transformation matrix or Vecwarp to transform coordinates. For data that has been nonlinearly transformed, use 3dNwarpApply for the data or 3dNwarpXYZ for coordinates. You can transform just the coordinates and create a new sphere at the new coordinates in native space.