Hacky NIRCAM/BAR_NARROW developments

[wbalmer]

Take initial crpix from pysaif directly (ensures the narrow 400x256 subarray centers are recorded correctly in headers).
Options to take sqrt and mask whole regions before align and shift steps (both recenter_frames and align_frames). This enables the suppression of certain sidelobes and mask the central leakage (even if centers are recorded incorrectly), these effects can pull shifts away from small angle maneuver commands in the bar_narrow offset images.

I think all of this won't affect any normal usage :)

[kammerje]

As @wbalmer already noted on Slack, populating the database with the pySIAF aperture reference position instead of the FITS file CRPIX header will not work if people crop or pad the images before in which case only the CRPIX header will be updated. Wrong CRPIX headers are a fault of the JWST pipeline and should be corrected there. This change needs to be undone. Tagging also @JarronL. SpaceKLIP is meant to be flexible and allow the user to determine the order in which steps are being run, and also stop/restart the reduction at any point in the process.

[JarronL]

As @wbalmer already noted on Slack, populating the database with the pySIAF aperture reference position instead of the FITS file CRPIX header will not work if people crop or pad the images before in which case only the CRPIX header will be updated. Wrong CRPIX headers are a fault of the JWST pipeline and should be corrected there. This change needs to be undone. Tagging also @JarronL. SpaceKLIP is meant to be flexible and allow the user to determine the order in which steps are being run, and also stop/restart the reduction at any point in the process.

The problem here is that CRPIX header values for the files that William is working on will never be corrected unless there is some external intervention. You are correct, this is a problem with the JWST fitswriter that generates the raw FITS files, but it may be a problem that persists for some time with a lot of bar masks data due to these new aperture sizes. In addition, with the introduction of simultaneous SW/LW, there are now incorrect APERNAME values in a number of coronagraphic datasets (due to incorrect fitswriter logic) that also have wrong CRPIX values. Suffice it to say, there's already a lot of data out in the wild with incorrect header information unbeknown to the user, so I would like SpaceKLIP to accommodate or at least warn about that.

I've already written a function that determines the correct aperture name based on the observations information (webbpsf_ext.imreg_tools.get_coron_apname), which allows us to then get the correct CRPIX values via pysiaf. Perhaps we should provide a standalone script that first checks the header for consistency and updates the FITS header values if they don't match the expected values?

[kammerje]

@JarronL I like the idea of having a separate script that checks and updates the header keywords if necessary. This way, the existing code will not break and people can still reduce their corrupt files. We could also introduce a new keyword when reading files into the database that allows the user to determine whether FITS header or pySIAF CRPIX values shall be used, with an explicit warning that the latter won't work if the data has been padded or cropped before.

[wbalmer]

rebased this branch at Ananya's request

[asahooexo]

@wbalmer, I think the rebasing didn't go well as this branch is still 46 commits behind develop.

[wbalmer]

Since this PR was based on my dev/wb branch and is a bit of a mess, I am closing it and opening two new PRs (#182 and #183 ) with their own dummy branches that address the two distinct changes I had to make to reduce NIRCam bar NARROW data.