My fault. One would think it difficult to mess up a 3dcopy
command, but I didn't pay enough attention and created another
AFNI dataset.

In any case, I took a closer look at the actual data and it
seems more likely that neither 3dcopy nor 3dAFNItoNIFTI is the
problem. The copied files actually seem correct. It is the
original dataset that does not.

The slice origin of the original dataset is 87.0 L, yet the
oblique matrix shows that it should be 81.35 L. When making
a copy to a NIfTI dataset, that matrix is re-applied upon
loading, creating a new origin of 81.35.

It is more likely that your original to3d program had a bug
that has long since been fixed (likely if the Dicom images
were Siemen's). If you still have the Dicom files, it would
be simple to verify.

Fixing this should not be a big deal, depending on which stage
of processing you actually want to modify. Some choices:

1. start over with the current to3d (good as a test, anyway)
2. fix the pre-aligned origin with 3drefit and re-do alignment
3. modify the newly created NIfTI datasets with nifti_tool

Do any of those seem good, given what you have done and still
need to do with the dataset?

- rick