funimageget(3)

✨ funimageget(3) ✨

okay bestie, listen up β€” this is the funimageget page from the SAORD Documentation set, and it's literally the glow-up your Funtools images deserve. we're in section 3 of the manual, iykyk πŸŽ€


🌸 NAME 🌸

FunImageGet β€” get an image or image section πŸ’–


πŸ¦‹ SYNOPSIS πŸ¦‹

#include <funtools.h>

void *FunImageGet(Fun fun, void *buf, char *plist)

✨ DESCRIPTION ✨

so FunImageGet() returns a binned image array of the section of a Funtools data file you asked for. that's the whole vibe. but here's the tea on how it gets there πŸ«–:

  • if your input data are already of type image, the array is made by extracting the specified image section and then binning it according to the specified bin factor.
  • if your input data live in a binary table or raw event file, the rows get binned on the columns specified by the bincols= keyword (using appropriate default columns as necessary), and after that the image section and bin factors get applied.

in both cases, the data is automatically converted from FITS to native format, if necessary. no extra steps, no cap 🧚

πŸ’… the three arguments, one by one

  • fun β€” the first argument, the Funtools handle that FunOpen() handed you.
  • buf β€” the second argument, a pointer to a data buffer to fill. if you pass NULL, FunImageGet will allocate a buffer of the appropriate size. generally speaking? you always want Funtools to allocate the buffer, because the image dimensions are determined by Funtools image sectioning on the command line. let Funtools cook πŸ‘‘
  • plist β€” the third argument (aka the parameter list), a string with one or more comma-delimited keyword=value parameters. you can use it to specify the return data type with the bitpix= keyword. if no such keyword shows up in the plist string, the data type of the returned image is the same as the data type of the original input file, or is of type int for FITS binary tables.

πŸ”₯ the bitpix= keyword

if you supply bitpix= in the plist string, the returned image's data type will be one of the supported FITS image data types:

  • 8 unsigned char
  • 16 short
  • 32 int
  • -32 float
  • -64 double

for example:

  void *buf;
  /* extract data section into an image buffer */
  if( !(buf = FunImageGet(fun, NULL, NULL)) )
    gerror(stderr, "could not FunImageGet: %s\n", iname);

this will allocate buf and retrieve the image in the file data format. in this case, you'll have to figure out the data type yourself (using the FUN_SECT_BITPIX value in the FunInfoGet() routine) and then use a switch statement to process each data type:

  int bitpix;
  void *buf;
  unsigned char *cbuf;
  short *sbuf;
  int *ibuf;
  ...
  buf = FunImageGet(fun, NULL, NULL);
  FunInfoGet(fun, FUN_SECT_BITPIX,  &bitpix, 0);
  /* set appropriate data type buffer to point to image buffer */
  switch(bitpix){
  case 8:
    cbuf = (unsigned char *)buf; break;
  case 16:
    sbuf = (short *)buf; break;
  case 32:
    ibuf = (int *)buf; break;
 ...

see the imblank example code for more details on how to process an image when the data type is not specified beforehand. ngl, that's the move πŸ™ˆ

πŸ“ honestly? just say the type

it often is easier to specify the data type directly:

  double *buf;
  /* extract data section into a double image buffer */
  if( !(buf = FunImageGet(fun, NULL, "bitpix=-64")) )
    gerror(stderr, "could not FunImageGet: %s\n", iname);

this will extract the image while converting to type double. slay ✨

🫢 what you get back

on success, a pointer to the image buffer is returned. (this will be the same as the second argument, if NULL is not passed to the latter.) on error, NULL is returned. that's the whole deal πŸ’€

🌈 the summary section, aka the recipe

in summary, to retrieve image or row data into a binned image, you simply call FunOpen() followed by FunImageGet(). generally, you then will want to call FunInfoGet() to retrieve the axis dimensions (and data type) of the section you are processing β€” so as to take account of sectioning and blocking of the original data:

  double *buf;
  int i, j;
  int dim1, dim2;
  ... other declarations, etc.

  /* open the input FITS file */
  if( !(fun = FunOpen(argv[1], "rc", NULL)) )
    gerror(stderr, "could not FunOpen input file: %s\n", argv[1]);

  /* extract and bin the data section into a double float image buffer */
  if( !(buf = FunImageGet(fun, NULL, "bitpix=-64")) )
    gerror(stderr, "could not FunImageGet: %s\n", argv[1]);

  /* get dimension information from funtools structure */
  FunInfoGet(fun, FUN_SECT_DIM1, &dim1, FUN_SECT_DIM2, &dim2, 0);

  /* loop through pixels and reset values below limit to value */
  for(i=0; i<dim1*dim2; i++){
    if( buf[i] <= blimit ) buf[i] = bvalue;
  }

πŸŽ€ mask=all, the underrated icon

another useful plist string value is "mask=all", which returns an image populated with regions id values. image pixels within a region will contain the associated region id (region values start at 1), and otherwise will contain a 0 value. so the returned image is a region mask which can be used to process the image data (which presumably is retrieved by a separate call to FunImageGet) pixel by pixel. obsessed πŸ’–

🧚 bincols=, because event files don't bin themselves

if a FITS binary table or a non-FITS raw event file is being binned into an image, it is necessary to specify the two columns that will be used in the 2D binning. this usually is done on the command line using the bincols=(x,y) keyword:

  funcnts "foo.ev[EVENTS,bincols=(detx,dety)]"

the full form of the bincols= specifier is:

  bincols=([xname[:tlmin[:tlmax:[binsiz]]]],[yname[:tlmin[:tlmax[:binsiz]]]])

where the tlmin, tlmax, and binsiz specifiers determine the image binning dimensions:

  dim = (tlmax - tlmin)/binsiz     (floating point data)
  dim = (tlmax - tlmin)/binsiz + 1 (integer data)

these tlmin, tlmax, and binsiz specifiers can be omitted if TLMIN, TLMAX, and TDBIN header parameters (respectively) are present in the FITS binary table header for the column in question. note that if only one parameter is specified, it is assumed to be tlmax, and tlmin defaults to 1. if two parameters are specified, they are assumed to be tlmin and tlmax. the way that just… works out πŸ’…

🌟 if you don't specify bincols at all

if bincols is not specified on the command line, Funtools tries to use appropriate defaults:

  1. it looks for the environment variable FITS_BINCOLS (or FITS_BINKEY).
  2. then it looks for the Chandra parameters CPREF (or PREFX) in the FITS binary table header.
  3. failing this, it looks for columns named "X" and "Y" β€” and if these are not found, it looks for columns containing the characters "X" and "Y".

see Binning FITS Binary Tables and Non-FITS Event Files for more information. go read it, fr fr πŸ“š


πŸ’œ SEE ALSO πŸ’œ

see funtools(7) for a list of Funtools help pages 🌈


cute lil sign-off: this page is from version 1.4.5, dated April 14, 2011. yes she's been iconic for that long, and yes she still eats. periodt πŸ’…βœ¨