Hi, Avi-
OK, that shows what is happening differently. From the help file of 3dinfo, what those 5 numbers mean is comparing these 5 properties (in order), where 1 means agreement and 0 means disagreement:
-same_all_grid: Equivalent to listing all of -same_dim -same_delta
-same_orient, -same_center, and -same_obl on the
Indeed, there is obliquity in vr_*HEAD dset that is purged by the end.
Since all the other 4 attributes match, I believe you should be able to "reattach" the obliquity to the errts* data from the vr*HEAD dset with (since 3drefit will change the header in place, always start with a copy):
3dcopy DSET_ERRTS errts_obl
3drefit \
-atrcopy vr_base_min_outlier+orig.HEAD IJK_TO_DICOM_REAL \
errts_obl+orig.HEAD
... and you can verify that the two dsets match with:
3dinfo -same_all_grid -prefix vr_base_min_outlier+orig.HEAD errts_obl+orig.HEAD
NB: if you don't care about going to standard space, I would probably purge the obliquity from my EPI datasets from the start. Why would you want your final data to have obliquity? I would run adjunct_deob_around_origin on the EPI datasets to start with, to purge obliquity while preserving the location of the coordinate origin and also not incurring any blurring/smoothing. Then you won't have to do any of this post-afni_proc.py stuff, nor deal with hassles that obliquity causes all software.
--pt