FLAASH should do nothing with the map registration of your file.  It is a spectral process, not a spatial one.  The only issue I have seen with FLAASH is if your data are in a 'pseudo' or 'arbitrary' projection.  This type of information may not be passed along in the file header after processing it in FLAASH.  If you are seeing an actual shifting of the map information ( you might look at the map info before and after processing in FLAASH), then I would suggest you contact Technical Support about the problem.

Thank you for your reply mminari. All of my data has been projected to UTM16n (although in some cases, this wasn't the case orginially and the images had to undergo a projection conversion). You described a problem with information not being passed along in the file heder after processing in FLAASH. Have you seen this occur when working with images in UTM? Although I wouldn't personally consider UTM 'pseudo' or 'arbitrary', I'm sure some people would since it was developed by the US military. Are you considering UTM within the realm of 'pseudo' or 'arbitrary'? 

No, UTM is a valid true projection.  FLAASH should only pass along the map information of the file.  It seems unlikely that any shifting should occur.  Does the input file and output file have the exact same Map Info as seen in the Available Bands List (or by right clicking on the globe icon and going to Edit Map Information)?

Given your previous response, I conducted a test on the UTM projection. I converted the projection of a sample image to Albers Equal area. Then I simply ran it through FLAASH and compared the before-image to the after-image. I found that there was no spatial difference between the images. The problem doesn't replicate with Albers. I looked at the header files of an image in UTM before FLAASH and after FLAASH and here's the difference:   Map info (before) = {UTM, 1.000, 1.000, 693855.000, 3734175.000 , 3.0000000000e+001, 3.0000000000e+001, 16, North, WGS-84, units=Meters} Map info (after) = {UTM, 1.000, 1.000, 793125.000, 3688335.000 , 3.0000000000e+001, 3.0000000000e+001, 16, North, WGS-84, units=Meters} Above, I highlighted the difference in red. It seems to me that the origin for the UTM projection changes (or isn't retained), or at least that's what I think that number is. I've been researching for a envi header file format template to confirm that but I cannot find any information. Nevertheless, the problem seems to be with the UTM projection. The good news is that it's actually an easy fix on my end. I just need to change the header information manually to match the original 'map info' numbers. This can be done by just opening the two header files up in wordpad and doing a simple copy/paste. However, I find this to be a major setback in using FLAASH. I have nearly 150 images to process and this extra step that is required because of the projection is a problem.

Thanks for reporting this.  It appears to be an issue with subsetted data that have an x/y start value in the header.  This information is not passed through FLAASH and is causing the map informaton to be changed when it should not.  A bug report has been made.  As a work around, if you remove the x/y start values (by setting them to 1, 1), the map information is passed along properly.