psImageReadSection and/or psImage has no concept of a mask.

[robert.desonia@…]

psImageReadSection has no concept of a mask to mark nul pixels. Shall I assume
the use of a magic pixel value is to be used? I thought it was a desire to use
a byte-sized mask array for this purpose instead.

It may make sense, actually, to add the pixel mask to the psImage struct
instead, as it is highly coupled to the image.

-rdd

[eugene]

When we go to or from FITS via read/write, we are flattening any mask
information since we only have one native-FITS option (ie, the BLANK or BADPIX
value). The whole mask issue is actually somewhat more complex than this. I do
not want to wrap it in the psImage structure for a couple reasons: 1) We would
like to be able to do image-type operations on the mask independently of the
data (ie, extract segments, search for objects, etc). 2) the meaning of a mask
bit value is context-dependent rather than mathematically defined. For example,
we may want to have one mask bit value which means "saturated data", one which
means "extended object pixels", etc. The meaning of a specific operation, such
as A + B, is not defined unless we know that the mask bit value for that pixel
means.

For the case of reading from the FITS file: we should just read the actual data
values into the array. For floating-point type images, the cfitsio functions
can handle NaN/Inf correctly anyway, and so should we. For the integer data
types, we will be informed, via the header & psMetadata what the value is so we
can handle it. Reading in an actual astronomical image is going to be more
complex anyway since we will need to populate the image data structures (cell,
chip, etc). Writing data to FITS images is even worse since we will have to
handle the whole header, etc. We are working on defining that functionality,
which will be part of the MHPCC task to work on the Phase-2 modules and will
probably require multiple calls to the Fread / Fwrite varients. The specified
functions should be very low-level and not specifically deal with the metadata /
header data or make any extensive use of the CFITSIO extra functionality. Note
that we don't yet address the whole BSCALE / BZERO issue either. for now, let's
just keep the null value at 0, which avoids interpretation by the CFITSIO
functions and keep BSCALE = 1, BZERO = 0.

​http://heasarc.gsfc.nasa.gov/docs/software/fitsio/c/c_user/node26.html
​http://heasarc.gsfc.nasa.gov/docs/software/fitsio/c/c_user/node39.html

The other related issue is how to handle floating-point exceptions, esp in
BinaryOp, which is currently not defined in the SDRS. We will address this.

Paul: can you track this issue since it interacts heavily with the P2 modules issue.

[robert.desonia@…]

I'm not 100% clear on this yet.

When reading in a FITS file, CFITSIO gives me an option to create a mask image
(e.g., fits_read_pixnull), but you are saying you'd rather use the nulval
notation (e.g., fits_read_pix) and create the mask as a separate operation?

FITS does flatten the mask to a single binary value, but I'd think you'd want
the option to generate the cooresponding mask while reading an image, none the
less. One of the possible mask values could coorespond to the 'bad pixel at
read time' condition.

If we are strictly going with the special nulval in an image and no mask image
creation, do you really want to use zero to integers, or should I use values
defined in the header (which would most likely be set to MAX_UINT8, MAX_INT16,
or MAX_INT32)? For floating point, obviously NaN is the value to use here.

Should all operations on an image check for nulval as well?

[Paul Price]

For the time being, we'll create and store the masks separately from the image,
so don't worry about deriving them from the image using cfitsio.

As far as image operations are concerned, I think we should trap operations
involving NaN, but don't worry about the other values (e.g. zero for the integer
types) --- these pixels will be taken care of in the mask.

[Paul Price]

Agreed that this bug should be closed at this morning's meeting.