What is happening, and I'm guessing here (in a semi-educated way), is that the oblique transformation data read from the DICOM data of either or both the anatomical and EPI data is wrong, or at least not consistent. The scanner manufacturers do not necessarily present these in a standard or even reasonable way, and we have to backwards engineer what the obliquity really is. DICOM servers at various institutions can also mangle this information too, so by the time the data gets into a NIFTI or AFNI format, it may not be correct. Usually it is, and we make efforts to try to figure out some of these problems as they come up. Still there are times when it is easy to workaround by doing things like "3drefit -deoblique". Collecting data across many sites may give many types of DICOM files, for instance, and it is often easier to align the data with "-giant_move -deoblique off". You could, of course, use other DICOM converters to see if that solves the problem. mri_convert (Freesurfer), mriconvert, dcm2nii, Osirix are all good conversion tools for this task, and I'm sure there are many or at least several others.

For your particular problem, I would say do that same thing - "align_epi_anat.py -giant_move -deoblique off". For some of this bad data, it's often useful to use @Align_Centers just to get the datasets to be roughly in the same grid. That's a strategy that's useful for aligning across sites, scanners or modalities. For some other data, like another posting yesterday, the oblique transformation from DICOM is correct, but the oblique transformation swings the out of the original "cardinal" grid when it's deobliqued/obliqued for the anat to match the EPI. See that posting about using "-master_anat".