data type changes and fits header definitions II
rclark wrote on Nov 26, 2008
An image file is being created with the statement:
op = immap (Memc[outname], NEW_COPY, ip)
so existing header information will be copied, as only a small number of
keywords are to be changed. However among the changes is the data type of
image array. These can include changes of data type and array sizes (the
complex data type was being used in some places-- we're trying to get away
from this for file io) as reflected in IM_PIXTYPE[op], IM_NDIM[op], and
the dimension sizes in IM_LEN[op,n]. (defined in inhdr.h)
The code I'm looking at, and needing to modify, also calculates
IM_BUFSIZE. (defined in imset.h)
bufsize = npix*sizeof(IM_PIXTYPE(op))
call imseti (op, IM_BUFSIZE, bufsize)
So my question is...
How are these IM_* values communicated to the fits kernal?
Is it necessary (or desireable) for the user to be messing around with
this bufsize value? And if so, is it necessary to explicitly set it
with an imseti call? There are no corresponding calls for the IM_NDIM,
IM_LEN and IM_PIXTYPE values in the code. Multiple files undergoing the
same type of processing are open simultaneously.
And finally there will be a line like:
call amovr(Memr[data], Memr[imps3r(op, 1,2, 1,ncols, 1,nlines)], npix)
where the data type of the vos or Mem reference will need to be
changed.
Are there any tools to help check type consistency here. (you're
welcome to place bets on whether I'll miss a few. I know which way
I'm betting:-)
In older versions of iraf there was a tool called spplint. Might it be
able to help with this? and whatever became of it?
op = immap (Memc[outname], NEW_COPY, ip)
so existing header information will be copied, as only a small number of
keywords are to be changed. However among the changes is the data type of
image array. These can include changes of data type and array sizes (the
complex data type was being used in some places-- we're trying to get away
from this for file io) as reflected in IM_PIXTYPE[op], IM_NDIM[op], and
the dimension sizes in IM_LEN[op,n]. (defined in inhdr.h)
The code I'm looking at, and needing to modify, also calculates
IM_BUFSIZE. (defined in imset.h)
bufsize = npix*sizeof(IM_PIXTYPE(op))
call imseti (op, IM_BUFSIZE, bufsize)
So my question is...
How are these IM_* values communicated to the fits kernal?
Is it necessary (or desireable) for the user to be messing around with
this bufsize value? And if so, is it necessary to explicitly set it
with an imseti call? There are no corresponding calls for the IM_NDIM,
IM_LEN and IM_PIXTYPE values in the code. Multiple files undergoing the
same type of processing are open simultaneously.
And finally there will be a line like:
call amovr(Memr[data], Memr[imps3r(op, 1,2, 1,ncols, 1,nlines)], npix)
where the data type of the vos or Mem reference will need to be
changed.
Are there any tools to help check type consistency here. (you're
welcome to place bets on whether I'll miss a few. I know which way
I'm betting:-)
In older versions of iraf there was a tool called spplint. Might it be
able to help with this? and whatever became of it?
Mike Fitzpatrick wrote on Nov 26, 2008
You can ignore the IM_BUFSIZE thing, it is only a way to optimize the file i/o buffer size.
If you want to change the types, look at the achtXY() functions in the sys$osb directory to e.g. convert real to int for a vector. Not that something like imps3r() returns a pointer to real which must match the Mem array being used (this is an alignment issue, you won't get a compile-time error so it's a silent bug you'll pull your hair out over for days).
This was actually a host command written for Sun systems that was never fully ported to PC-IRAF platforms. It mostly used GCC error messages which you get for free now so there was no urgency. It did however use prototypes that might help, but I haven't got a version to give you that works.
-Mike
And finally there will be a line like:
call amovr(Memr[data], Memr[imps3r(op, 1,2, 1,ncols, 1,nlines)], npix)
where the data type of the vos or Mem reference will need to be
changed.
If you want to change the types, look at the achtXY() functions in the sys$osb directory to e.g. convert real to int for a vector. Not that something like imps3r() returns a pointer to real which must match the Mem array being used (this is an alignment issue, you won't get a compile-time error so it's a silent bug you'll pull your hair out over for days).
Are there any tools to help check type consistency here. (you're
welcome to place bets on whether I'll miss a few. I know which way
I'm betting:-)
In older versions of iraf there was a tool called spplint. Might it be
able to help with this? and whatever became of it?
This was actually a host command written for Sun systems that was never fully ported to PC-IRAF platforms. It mostly used GCC error messages which you get for free now so there was no urgency. It did however use prototypes that might help, but I haven't got a version to give you that works.
-Mike
Last post on Nov 26, 2008