MFIXNAN(1)

πŸ’– MFIXNAN(1) πŸ’–

okay bestie, buckle up, we're doing mFixNaN from the Montage era β€” yes the whole squad is here, and yes this little icon replaces a specific set of values in a FITS image with NaNs (or does the reverse, because she contains multitudes πŸ’…).


✨ NAME ✨

mFixNaN β€” replaces a particular set of values in a FITS image with NaNs (or vice-versa, she's flexible like that πŸ¦‹)


🌸 SYNOPSIS 🌸

mFixNaN [-d level] [-v NaN-value] in.fits out.fits [minblank maxblank]

πŸ’« DESCRIPTION πŸ’«

so the whole vibe here is: NaNs are lurking in your image and you want them to be something else (a value you, the user, supply). OR: you have a range of values and you want them to become NaNs instead. Either direction, she handles it. no cap. πŸ”₯


πŸŽ€ OPTIONS πŸŽ€

  • -d level β€” turn on debugging, dial it up to the level you want (that's 1-3, bestie).
  • -b β€” check for a non-physical boundary area (think: the corners of an Aitoff image, they're giving chaos πŸ™ˆ) and correct them.
  • -v NaN-value β€” the value to use in place of any NaNs.

🧚 ARGUMENTS 🧚

  • in.fits β€” your input FITS image file. the moment. the source material. ⭐
  • out.fits β€” the path of the output FITS file. BUT β€” and this is the fun part β€” if you wanna run in "count" mode without actually creating an output file, just use a dash (-) for this argument. iconic behavior tbh.
  • minblank maxblank β€” if you don't use the -v switch, mFixNaN will replace all pixel values between minblank and maxblank with NaN. that's the whole assignment. πŸ’€

🌈 RESULT 🌈

[struct stat="OK", rangeCount=rangeCount, nanCount=nanCount]

so rangeCount is the number of pixels that were found between minblank and maxblank, assuming you specified them. and if you didn't β€” like, if NaNs got removed and swapped out for a value instead β€” then nanCount is the number of NaNs that got removed. one or the other, she's telling you which. πŸ‘‘


πŸ’œ MESSAGES πŸ’œ

  • OK β€” [struct stat="OK", rangeCount=rangeCount, nanCount=nanCount"]
  • ERROR β€” No debug level given
  • ERROR β€” Debug level string is invalid: level
  • ERROR β€” Debug level string is invalid: level
  • ERROR β€” Debug level string cannot be negative
  • ERROR β€” No value given for NaN conversion
  • ERROR β€” NaN conversion value string is invalid: 'NaN-value'
  • ERROR β€” Invalid input file 'in.fits']
  • ERROR β€” min blank value string is not a number
  • ERROR β€” max blank value string is not a number
  • ERROR β€” Image file in.fits missing or invalid FITS
  • ERROR β€” FITS library error

(and yes, that one Debug level string is invalid: level is listed twice in the original. i'm not deleting her sister. both stay. periodt. πŸ’…)


πŸ”₯ EXAMPLES πŸ”₯

so picture this: a FITS image with BITPIX -64 (that's double-precision floating point, iykyk) got generated without using NaNs, and every single "blank" pixel is just represented by a very small negative number. which, lowkey, throws off your first attempts to display the image with a proper stretch, AND it doesn't conform to the FITS standard. rude. 😭

to replace all those "blank" pixels with NaNs:

mFixNaN original.fits NaN.fits -4.61169e32 -4.61169e10
       [struct stat="OK", rangeCount=1321, nanCount=0]

and to convert those NaNs back into a single pixel value:

mFixNaN -v -4.6e32 NaN.fits blankval.fits
       [struct stat="OK", rangeCount=0, nanCount=1321]

look at her go. ate. ✨


🫢 BUGS 🫢

okay real talk, caveats incoming, pay attention bestie:

  • The drizzle algorithm has been implemented but has not been tested in this release. so... it's giving "we'll find out together" πŸ’€
  • If a header template contains carriage returns (i.e., it was created/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"]. windows moment fr fr.
  • For the background correction algorithms, it's best 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. The recommendation is to use an expanded header for the reprojection and background modeling steps, and then return to the originally desired header size for the final coaddition. Also: the default background matching assumes there are no non-linear background variations in the individual images (and therefore in the overlap differences). If there's any uncertainty about that, it is safer to turn on the "level only" background matching β€” that's the -l flag in mBgModel. noted, saved, screenshot. πŸ“Έ

2001-2015 California Institute of Technology, Pasadena, California

If your research uses Montage, please include the following acknowledgement β€” for real, she's asking nicely πŸ₯Ί:

"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 πŸ’– this was Montage 5, dated Dec 2016 β€” thanks for coming to my ted talk, go fix those NaNs, you're gonna slay πŸŽ€βœ¨πŸŒΈ