MTILEHDR(1)

💖 MTILEHDR — bestie edition 💖

okay so this is mTileHdr, and it lives in the Montage manual (section 1, obvs). pull up a chair, we're gonna tile some headers ✨

---

🌸 NAME 🌸

mTileHdr — 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]]

that's it. that's the whole vibe. periodt 💅

---

✨ DESCRIPTION ✨

so what this icon does is: it takes a header template file and spits out another one, and that new one represents one specific tile out of a regular grid of tiles covering the original. you tell it how the grid is laid out, and you tell it which tile you want. that's the whole job. slay.

and here's the key thing, the only lines that get changed are the NAXIS and CRVAL keyword lines — that's the pixel size and the reference point location, iykyk. every other keyword value? inherited straight from the input header. no notes. 👑

---

💅 OPTIONS 💅

• -d — turns on debugging. yes queen, show us the tea 🫖
• -s statusfile — output and errors get sent to statusfile instead of going to stdout. so if you don't want the noise in your terminal, this is your girl 🎀

---

🦋 ARGUMENTS 🦋

• orig.hdr — the ASCII header template you're deriving your tiled headers from. the source material. the blueprint 🌸
• new.hdr — the path to the output header. where the magic lands ✨
• 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 (and bestie, it counts from 0 💀)
• iy — integer identifying the y location of the output tile on the grid (also counting from 0, we're programmers here)
• 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)

---

🌈 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. look at that struct. gorgeous. 🫶

---

⭐ MESSAGES ⭐

• OK — [struct stat="OK", naxis1=xsize, naxis2=ysize, crpix1=xref, crpix2=yref]
• 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.

like, read them. they're very self-explanatory. they ate 💅

---

🧚 EXAMPLES 🧚

okay so say template.hdr is 850x850 pixels, and we want to generate the center tile out of 9 (that's 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 tile_1_1.hdr ends up with the same reference location and pixel scale as the input header, but a brand new pixel offset (CRPIX) and size (NAXIS). it's giving glow-up. ✨

---

💀 BUGS 💀

listen, we gotta be honest with each other here.

• The drizzle algorithm has been implemented but has not been tested in this release. so… it exists. we don't know if it works. lowkey terrifying ngl 🙈
• 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"]. so yeah. windows line endings will simply ruin your day. 😭
• 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).

that last one is a whole paragraph but it's important, so we're keeping every word of it, fr fr. 🫡

---

👑 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.

---

k that's the whole page bestie, mwah 💖

this was Montage 5, dated Dec 2016 — thanks for reading, you're the main character of this manpage now, bye 🎀🦋✨