MPROJECT(1)

✨ MPROJECT ✨ β€” a.k.a. the mProject manual page, bestie edition πŸ’–

okay so first things first: this is the manual for mProject, part of Montage, and it lives in section 1 of the manual. Buckle up, we're reprojecting FITS images and it's gonna be iconic πŸ¦‹


🌸 NAME 🌸

mProject β€” re-project FITS images πŸ’…


πŸŽ€ SYNOPSIS πŸŽ€

mProject [-z factor] [-d level] [-s statusfile] [-h hdu] [-x scale] [-w
weightfile] [-W fixed-weight] [-t threshold] [-X] [-b border-string]
[-e(nergy-mode)] [-f] in.fits out.fits hdr.template

✨ DESCRIPTION ✨

So, what does mProject actually do? It takes one single image and reprojects it onto the scale defined in a FITS header template file (there's a whole explainer about header templates if you go read up on it, iykyk).

And it doesn't just hand you one file, it hands you a pair:

  • the reprojected image itself, and
  • an "area" image β€” that's the fraction of input pixel sky area that landed in each output pixel 🫢

The "drizzle" algorithm is what's implemented here. How does it work? Basically:

  1. It maps pixel corners (as adjusted by drizzle, if drizzle got called) from the input pixel space to the output pixel space.
  2. It calculates the overlap area with each output pixel.
  3. It accumulates the appropriate fraction of the input flux into the output image pixels.

And on top of that, the appropriate fraction of the input pixel area gets accumulated into the area image pixels too. No pixel gets left out πŸ’–

Projecting points from input pixel space to output pixel space happens in two steps:

  1. First, map from input pixel space to sky coordinates.
  2. Second, map from sky coordinates to output pixel space.

🚨 SPECIAL NOTE TIME, this one has happened enough times that it earned its own paragraph 🚨

It is genuinely possible to define a FITS header with the reference location off the image. And people do it a LOT β€” like, folks will often reference cylindrical projections (e.g., CAR, CEA) to location (0.,0.) (e.g., the Galactic center). That's not wrong in itself, bestie, but it does lead to extremely large pixel offsets (e.g., in the hundreds of thousands 😭).

And related to that: if you extract a header from an image with large offsets of this type, it is unlikely that you can simply change projection types without also adjusting the reference location/offsets. Most likely, you will end up with the reproject data all being off-scale. So like... be careful, okay? πŸ™ˆ


πŸ’… OPTIONS πŸ’…

  • -z factor β€” processing is done utilizing the drizzle algorithm. factor is a floating point number; the recommended drizzle factors are from 0.5 to 1. Slay.
  • -d level β€” causes additional debugging information to be printed to stdout. Valid levels are 1-5. (For higher debugging levels, it's recommended that you redirect the output to a file, because it gets chatty.)
  • -s statusfile β€” output and errors are written to statusfile instead of being written to stdout. Quiet girl era 🀫
  • -h hdu β€” use the specified FITS extension (default is to use the first HDU with image data).
  • -x scale β€” apply a correction factor of scale to each pixel.
  • -w weightfile β€” path to a weight map to be used when reading values from the input image.
  • -W fixed-weight β€” use a constant weight value for the whole image.
  • -t threshold β€” pixels with weights below threshold will be treated as blank. Gone. Ghosted. πŸ’€
  • -X β€” makes the output region (originally defined in the header template) big enough to include all of the input images.
  • -b border-string β€” define a border width or border pixel corners outside of which all pixels are set to NaN.
  • -e β€” process the data as total energy rather than the default energy density (scale values by relative pixel areas).
  • -f β€” output the full region requested even if there is a border of NULL values (default is to shrinkwrap to just the pixels with values).

🧚 ARGUMENTS 🧚

  • in.fits β€” input FITS file to be reprojected.
  • out.fits β€” path of output FITS file to be created.
  • hdr.template β€” FITS header template to be used in generation of output image.

🌈 RESULT 🌈

Two files are created as output, and yes that's the whole point:

  • the reprojected FITS file (out.fits), and
  • an "area" image (out_area.fits) which records the amount of coverage (in output pixel space) provided by the input images. πŸ’–

πŸ‘‘ MESSAGES πŸ‘‘

Here's the whole menu of things this program might say to you:

  • OK β€” [struct stat="OK", time=seconds] βœ…
  • ERROR β€” Drizzle factor string (string) cannot be interpreted as a real number
  • ERROR β€” Weight threshold string (string) cannot be interpreted as a real number
  • ERROR β€” Flux scale string (string) cannot be interpreted as a real number
  • ERROR β€” Cannot open status file: statusfile
  • ERROR β€” HDU value (hdu) must be a non-negative integer
  • ERROR β€” No overlap
  • ERROR β€” Not enough memory for output data image array
  • ERROR β€” Not enough memory for output area image array
  • ERROR β€” Output wcsinit() failed.
  • ERROR β€” Input wcsinit() failed.
  • ERROR β€” FITS library error
  • ERROR β€” All pixels are blank
  • ERROR β€” Template file not found
  • ERROR β€” Image file in.fits missing or invalid FITS
  • ERROR β€” Weight file weightfile missing or invalid FITS

πŸ“ EXAMPLES πŸ“

Look at her go:

$ mProject rawdir/real_orig.fits projdir/base_unity.fits
templates/galactic_orig.txt
       [struct stat="OK", time=143]

ate. no crumbs. πŸ”₯


πŸ’€ BUGS πŸ’€

okay so the not-so-cute part, but we gotta be honest:

  • The drizzle algorithm has been implemented but has not been tested in this release. (Yeah. We said what we said.)
  • If a header template contains carriage returns (i.e., created/modified on a Windows machine), the cfitsio library will be unable to read it properly, resulting in the error: [struct stat="ERROR", status=207, msg="illegal character in keyword"]
  • It is best for the background correction algorithms if the area described in the header template completely encloses all of the input images in their entirety. If parts of input images are "chopped off" by the header template, the background correction will be affected. We recommend you use an expanded header for the reprojection and background modeling steps, returning to the originally desired header size for the final coaddition. The default background matching assumes that there are no non-linear background variations in the individual images (and therefore in the overlap differences). If there is any uncertainty in this regard, it's safer to turn on the "level only" background matching (the -l flag in mBgModel).

2001-2015 California Institute of Technology, Pasadena, California

If your research uses Montage, please include the following acknowledgement β€” fr fr, this is the polite thing to do:

"This research made use of Montage. It is funded by the National Science Foundation under Grant Number ACI-1440620, and was previously funded by the National Aeronautics and Space Administration's Earth Science Technology Office, Computation Technologies Project, under Cooperative Agreement Number NCC5-626 between NASA and the California Institute of Technology."

Also! The Montage distribution includes an adaptation of the MOPEX algorithm developed at the Spitzer Science Center. πŸ’œ


and that's the whole page, bestie πŸŽ€ this was Montage 5, dated Dec 2016, and you've been reading the MPROJECT(1) manual β€” go forth and reproject, main character πŸ’…βœ¨πŸ¦‹