psImageWriteSection/psImageFWriteSection clarifications

[robert.desonia@…]

psImageWriteSection doesn't have enough parameters to fully define an "image
portion" for an image. Am I to assume the whole psImage is to be written into
the FITS file at location (x,y,z)?

If the given z is greater than the image cube in the file, is that an error or
should the image cube be resized (which could be a costly operation). Can I
assume that the appropriate action for this is to be defined by the capabilities
of the underlying library (i.e., currently CFITSIO)?

What is the purpose of the return value of psImageWriteSection, as assumably it
does not modify anything but the file? Is it just to communicate success? If
so, why not just return an integer flag?

Can I assume that the extnum parameter is to be used only if extname is NULL?

[eugene]

This is a somewhat simplified function just to get us up and running. The
ambiguity is in what the values of x,y,z mean if a) there is already an existing
image and b) there is not an existing image. This should be clarified in the
SDRS. Here is what I'd like:

case 1: image exists

• write the complete psImage data to the existing image starting at the

coordinate x,y,z. If any of these parameters implies writing pixels outside the
existing data area of the image, return an error (ie, if x + image.nx >= NAXIS1,

y + image.ny >= NAXIS2, or z >= NAXIS3).

case 2: image does not exist

• require x,y,z to be zero. (we could force the output image to have

dimensions of image.nx + x, etc, but let's not bother).

I have no idea why that function is returning a psImage. It should be a status
value, but we didn't specify the possible failure states. For the moment, let's
just return 0 for success, 1 for failure. (also see the new section of psError
for the direction we are going on error handling).

[eugene]

extnum vs extname: yes, extname has precedence. (should it be an error to pass
extname != NULL and extnum != 0? it probably does not matter at this stage).

[robert.desonia@…]

Re: should it be an error to pass extname != NULL and extnum != 0?

I'd say maybe a warning message, but not an error.

[Paul Price]

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