By default, 3dTshift computes the time shift for each slice to bring it to the average time for all slices. In the example you gave above, this average time would be 0.479167*TR -- slice #0 is at 0/24*TR, #1 is at 12/24*TR, #2 is at 1/24*TR, etc -- the average time is thus ((0+1+2+...+23)/24*TR)/24=0.479167*TR. Thus, slice #0 voxels values should be interpolated to appear as they would at this later time. The problem/bug/error/stupidity was that I shifted them the wrong way -- in this example, slice #0 would be shifted 0.479167*TR to the past instead of the future. This means that it would now be 0.958333*TR away from the center time, instead of the 0.479617 that it was originally and instead of the 0*TR that was the goal. And so on for the other slices -- in the old 3dTshift, they would be pushed away from the center time instead of towards the center time.

How did this bug come to happen? Pure error of thought on my part. It wasn't a typo, it was a braino. The program did exactly what I planned for it, but I interpolated the time series to the desired time point thinking exactly backwards from what should have been done. My checking of the old 3dTshift didn't catch this error because it corresponded with my thinking. Only someone else's brain (Kate Fissell's) could correct this error in ratiocination.

bob cox