6.6. mosaicADdetectors¶
6.6.1. Purpose¶
This primitive mosaics the SCI frames of the input images, along with the VAR and DQ frames if they exist.
6.6.2. Inputs and Outputs¶
tile
: bool (default: False), tile images instead of mosaic (mosaic includes
transformations)
dq_planes
: bool (default: False), transform the DQ image, bit plane by bit
plane
6.6.3. Algorithm¶
This primitive overrides the one of the same name inherited from
GEMINIPrimitives
. The override logic is identical to the original except
for two hacks introduced just prior to calling the mosaicing routine,
gemini_mosaic_function
, and undone immediately after. These are necessary
in order to trick the underlying mosaicing machinery into working for GHOST
data, and are as follows:
- First, we add ‘GSAOI’ to the internal array of types for our input AstroData
object (which contains the extensions we want to mosaic). This bypasses the
GSAOI-/GMOS-only check built into
gemini_mosaic_function
. Afterwards we reset the type list back to normal by invokingAstroData.refresh_types
on the resulting, mosaiced, AstroData object. - Secondly, we set the
INSTRUME
PHU keyword to../../../astrodata_GHOST/ADCONFIG_GHOST/lookups
. This tricksset_geo_values
(called bygemini_mosaic_function
) into referencing thegeometry_conf.py
file under our ownastrodata_GHOST/lookups
folder. As soon as the mosaicing routine returns we resetINSTRUME
back to ‘GHOST’ (and in fact this must be done before the call torefresh_types
mentioned above).
Until such time as astrodata_GHOST
has been merged into astrodata_Gemini
(like GMOS and GSAOI have been), or astrodata_Gemini
is refactored, the
above two hacks will be necessary in order for GHOST to make use of Gemini’s
mosaicing mechanism.
6.6.4. Issues and Limitations¶
Requires ugly hacks until integration with, or refactoring of,
astrodata_Gemini
is completed.