MTILEIMAGE(1)

💖 mTileImage(1) 💖

okay bestie, welcome to the manual page for mTileImage — that's the Montage tool you'll find sitting in section 1 of the manual. Lowkey it's a little name-vs-synopsis situation (the page is called mTileImage, the command you actually run is mTileHdr), but we move. Sit down, grab a strawberry something, and let's get into it 🍓

---

✨ NAME ✨

mTileImage — Create a set of tiled images or header templates from a FITS file or header

---

✨ SYNOPSIS ✨

mTileHdr [-d] [-s statusfile] orig.hdr new.hdr nx ny ix iy [xpad [ypad]]

---

✨ DESCRIPTION ✨

So here's the vibe: this thing takes a header template file and pops out another header that represents exactly one tile out of a whole regular grid of tiles covering the original. You, the user, get to decide the gridding of the tiles and which specific tile you want. Main character energy, you're picking.

The only keyword lines that get changed are NAXIS and CRVAL (that's the pixel size and the reference point location, iykyk). Every other keyword value? Inherited straight from the input header. No cap. 🫶

---

✨ OPTIONS ✨

• -d — Turns on debugging. Let it spill the tea 🐛
• -s statusfile — Output and errors get sent to statusfile instead of to stdout

---

✨ ARGUMENTS ✨

• orig.hdr — ASCII header template from which to derive tiled headers. Your starting point, your blueprint 💅
• new.hdr — Path to output header. Where the new baby goes.
• nx — Number of tiles in the x-direction
• ny — Number of tiles in the y-direction
• ix — Integer identifying the x location of the output tile on the grid (counting from 0)
• iy — Integer identifying the y location of the output tile on the grid (counting from 0)
• xpad — Number of pixels to overlap tiles in the x direction (optional; default is 0)
• ypad — Number of pixels to overlap tiles in the y direction (optional; default is 0)

Not me pointing out that the indexing starts at 0, not 1. It's giving computer science, bestie. Count accordingly 🙈

---

✨ RESULT ✨

[struct stat="OK", naxis1=xsize, naxis1=ysize, crpix1=xref, crpix2=yref]

Where xsize and ysize are the x and y dimensions of the image described by the output header, and crpix1 and crpix2 are the new offset from the original reference pixel on the sky. ✨

---

✨ MESSAGES ✨

• OK — [struct stat="OK", naxis1=xsize, naxis2=ysize, crpix1=xref, crpix2=yref] — the good ending 🎀
• ERROR — Cannot open status file: statusfile
• ERROR — (nx,ny) have to be positive integers and (ix,iy) have to be in the range (0..nx-1, 0..ny-1)
• ERROR — Cannot open output template new.hdr
• ERROR — Bad template:orig.hdr
• ERROR — Bad template:new.hdr
• ERROR — Output wcsinit() failed.

---

✨ EXAMPLES ✨

Say template.hdr is 850x850 pixels, and we want to generate the center tile out of 9 (3 by 3):

$ mTileHdr template.hdr tile_1_1.hdr 3 3 1 1
       [struct stat="OK", naxis1=283, naxis2=283, crpix1=-283,
       crpix2=-283]

And the tea on tile_1_1.hdr: it has the same reference location and pixel scale as the input header, but a new pixel offset (CRPIX) and size (NAXIS). Slay. 🔥

---

✨ BUGS ✨

Okay so, the less fun section, but we stay honest:

• The drizzle algorithm has been implemented but has not been tested in this release. (Iconic of it, honestly, but be careful. 💀)
• If a header template contains carriage returns (i.e., it was created or modified on a Windows machine), the cfitsio library will be unable to read it properly, and you'll get this 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 is safer to turn on the "level only" background matching (the -l flag in mBgModel).

fr fr, read that third one twice. Chopped-off images = sad background correction 😭

---

✨ COPYRIGHT ✨

2001-2015 California Institute of Technology, Pasadena, California

If your research uses Montage, please include the following acknowledgement: "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."

The Montage distribution includes an adaptation of the MOPEX algorithm developed at the Spitzer Science Center.

---

and that's the whole page, bestie 🦋 no notes, we ate. this was Montage 5, dated Dec 2016, and it's the MTILEIMAGE(1) page — tysm for reading, go tile something gorgeous 💜🌈