Show all posts by user
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
Results 121 - 150 of 2305
Great, glad that updating sorted things out.
The R package failures will just affect some of the group analysis programs, and even then just a few of them (like RBA, likely). We can discuss more about those if that becomes a major issue.
--pt
by
ptaylor
-
AFNI Message Board
Hi-
That version of AFNI appears to be 5.5 years old. At that time, most Python programs in AFNI were written in Python 2.7. For a long time now, all Python programs in AFNI have been updated to run in both Python 2.7 and Python 3.* (the only exception is an older meica.py program, written by P Kundu and distributed within AFNI).
Regardless of Python version, there are so many updates to
by
ptaylor
-
AFNI Message Board
Hi-
What is the output of:
afni_system_check.py -check_all
on that system?
thanks,
pt
by
ptaylor
-
AFNI Message Board
Hi, Michal-
I pinged some MEICA experts here, and the advice was:
That particular error message could apparently come up relatively often in the older (Kundu et al.) MEICA, but the recommended way to solve/address/avoid it would be to use the newer tedana (Du Pre et al.):
https://tedana.readthedocs.io/en/stable/
It integrates into your afni_proc.py command in essentially the exact same wa
by
ptaylor
-
AFNI Message Board
Hi, Michal-
Can I ask what "-combine_method .." you are using? I guess it is either the older (Kundu et al) or newer (du Pre et al) MEICA? Probably it is going to be an issue within that software specifically to try to work out.
--pt
by
ptaylor
-
AFNI Message Board
Hi, Carolin-
Just to zoom out for a second:
A) Are you wanting to characterize the spikiness in an ROI at the start of processing, before anything has been done to the time series?
B) Also, do you want your spikiness measure to reflect temporal associations of spikes? That is, say there are 10 voxels in the left-hippocampus and you have 100 time points. Do you care if 3dDespike finds 10
by
ptaylor
-
AFNI Message Board
Hi, Giuseppe-
No worries, better to ask more questions to clarify and be sure of things than less questions.
And I'm glad this 3dcalc output is not behaving very weirdly, in the end.
--pt
by
ptaylor
-
AFNI Message Board
I don't quite see why this 2022-question is attached to the 2010-question. Am I misreading it, or aren't they separate issues? The first one was about voxel dimension, and this one is about matrix size---those are likely separate considerations.
It would also be helpful/necessary to see the exact commands being run to be able to consider what is happening. In general, a question a
by
ptaylor
-
AFNI Message Board
Thanks, Philipp! And have a good holidays there, too.
--pt
by
ptaylor
-
AFNI Message Board
Hi, Philipp-
Thanks for the alignment update, and glad to hear things are looking good! Yes, those options:
-align_opts_aea -cost lpc+zz -giant_move \
-align_unifize_epi local \
... and probably ones I would consider default for human FMRI processing.
Re. Q1: The little "missing" bits around the edges typically reflect signal dropout and loss in the original EPI. Life is ha
by
ptaylor
-
AFNI Message Board
NB: this conversation took a turn to another topic, so I split the thread and it continues here:
https://afni.nimh.nih.gov/afni/community/board/read.php?1,169045,169045#msg-169045
--pt
by
ptaylor
-
AFNI Message Board
Hi, Philipp-
That is odd. Can you check the NIFTI header directly, with:
nifti_tool -disp_hdr -field pixdim -infiles DSET_EPI
Does that show a TR of 1s? That is, is the value of pixdim[4] (zerobased counting) equal to 1.0? Note that first 5 pixdim values are:
pixdim[0] -> flag about qform or sform
pixdim[1-3] -> spatial voxel dims
pixdim[4] -> TR
It is possible that there
by
ptaylor
-
AFNI Message Board
This conversation changed topic from this thread:
https://afni.nimh.nih.gov/afni/community/board/read.php?1,169036,169044#msg-169044
... focusing on TRs instead of alignment.
---------------------------------------------------------------------------
Hi, Philipp-
I edited my previous reply in the thread with more info.
I am not sure about the previous issues, but hopefully this will
by
ptaylor
-
AFNI Message Board
Hi, Philipp-
Great, thanks. *That* shows your initial overlap, with your anatomical (that has no obliquity) and the EPI *with its original obliquity applied*. That is a reasonable starting point for alignment. I would put those datasets into afni_proc.py, sticking with the "lpc+ZZ" cost function for EPI-anatomical alignment.
Going back to the original point, you typically sta
by
ptaylor
-
AFNI Message Board
Hi, Philipp-
Focusing first on the img_epi_anat_olap.jpg: what EPI did you input there? Your DSET_EPI should be the "raw" or non-deobliqued one---the one that still has obliquity information---and then the output image of interest should be called img_epi_anat_olap_DEOB.jpg (created by "deobliquing" the dataset in the sense of applying the obliquity information).
Fro
by
ptaylor
-
AFNI Message Board
Hi, Philipp-
I don't quite agree with the "bad" designation here. Again, to me the new.jpg looks pretty good. Also note that this deobliquing will not unrotate the dataset relative to its acquired image axes---this EPI appears to have been acquired with standard brain slices at an angle to the FOV bounds, and they will stay there.
And *actually,* since the anatomical does n
by
ptaylor
-
AFNI Message Board
Hi, Philipp-
When you say that you get "bad results", what does that mean---if you put your recentered data into afni_proc.py, is the EPI-anatomical alignment not good (ve2a block), or is the anatomical-template alignment not good (va2t block)?
Note that what those sets of commands are doing is purging obliquity from the header while preserving the location of the coordinate origi
by
ptaylor
-
AFNI Message Board
Hi, Jenna-
It wouldn't surprise me if that paper's coordinates were specified in LPI orientation. If there are meaningful names for each location, that might help verify that "left" has a negative x-value, for example. I wish more authors provided that useful nugget of information, though... These are the rules about the interpretation of the xyz coordinates:
-orient c
by
ptaylor
-
AFNI Message Board
Hi, Jenna-
I'm not quite sure I understand the question, about what transform might be needed?
The one thing to change would be that "-xyz" is not an option that should be followed by coordinates, but it is a flag, signifying:
-xyz = Coordinates in the input file are (x,y,z)
spatial coordinates, in mm. If neither
-ijk or -xy
by
ptaylor
-
AFNI Message Board
Hi, Arda-
I think there are a lot of possibilities for why the dataset might have different properties than described, including: the paper description has one or more mistakes, or the paper describes a different stage of processing. It is probably a question that you would have to ask the people who created the dataset and wrote the article about it in order to be sure. It shouldn't r
by
ptaylor
-
AFNI Message Board
Actually, reading more carefully here, I see that your versions of AFNI each pre-date the 3dBrickStat fix that went in on Sept 1, 2022.
Testing your dataset on my computer with each of the old and new versions of 3dBrickStat, I see that the above bug fix (related to masking or not) fixes this issue. Therefore, AFNI versions >= 22.2.10 should not have this problem.
Thanks for checking ab
by
ptaylor
-
AFNI Message Board
OK. I am unsure (a fix about something else in 3dBrickstat had been made a little while ago, based on whether one had a mask or not; but that looks separate).
I am not sure about this, so will email you for the dset specifically, if that is OK? I am curious what the datum type of it is, as well as whether a scaling factor is involved... But rather than continually prodding with questions, I
by
ptaylor
-
AFNI Message Board
Hi, Zhihao-
You can create a set of spheres with stick connections as described here in the sphere tutorials:
Please let us know if that doesn't work.
--pt
by
ptaylor
-
AFNI Message Board
Hi, Zhihao-
There isn't a direct way to pare down those datasets. The best way to do that would be to re-run 3dNetCorr with a subset of the ROIs in the "-in_rois .." dset. That could be done with subbrick selectors, for example: -in_rois DSET_ROIS"[0..10,12,17,21..\$]"
As a side benefit, that will also mean that the corresponding *.netcc file with the associated ma
by
ptaylor
-
AFNI Message Board
Hi, Giuseppe-
What is your AFNI version number? That is, the output of:
afni -ver
?
--pt
by
ptaylor
-
AFNI Message Board
Hi-
You can check the voxelsize and matrix dimensions of one or more datasets with:
3dinfo -ad3 -n4 -prefix DSET_OR_LIST_OF_DSETS
You can also ask if two datasets have the same grid (a more detailed constraint) with:
3dinfo -same_all_grid LIST_OF_DSETS
Calculations across datasets often require having the same grid. There are multiple ways to put a dataset onto another grid, but it is
by
ptaylor
-
AFNI Message Board
Hi, Robin-
A couple of quick comments/questions:
A) You might want to add the following options to your AP command, to be explicit about the values used (there are defaults, but I prefer to state them):
-blur_size SOMETHING
-anat_has_skull YES_OR_NO
B) Are you sure you want this line in there, even though processing task-based data:
-regress_apply_mot_types demean deriv \
I am u
by
ptaylor
-
AFNI Message Board
Hi, Brady-
Cool, thanks.
Re 1) That must be an input dataset you have included the 3dinfo data for? The mask+underlay images you show appear to have much, much higher resolution (and a spatially isotropic one, too). It is great to have the initial resolution information, but I suspect that the processing pipeline included a very large upsampling factor, then? Frankly, that output looks l
by
ptaylor
-
AFNI Message Board
Hi, Robin-
Those look reasonable for a starting point. Note how it is much closer than in the initially shown case.
You could also check those overlaps (anatomical-template, and EPI-anatomical) before running @Align_Centers here---that might not be necessary, if the datasets are already well-centered around the (x,y,z)=(0,0,0) coordinate origin.
--pt
by
ptaylor
-
AFNI Message Board
Hi, Giuseppe-
OH. 5000 datasets probably is more instances than you want to use in the GUI...
Glad that was useful for you.
Will ponder making that into a slightly more script/commandline form, indeed, then.
--pt
by
ptaylor
-
AFNI Message Board