iraf.net

I am having problems accessing a fits file in an application written in
SPP when it is compiled with a 64 bit installation of iraf v215.The file has dimension [900,1024,6].
The BITPIX value is 32.The existing version compiled with v213 and copied to the 64 bit platform
works fine.The problem is that pixels are not being addressed correctly in the
64 bit version. For instance referencing [451,1,1] goes to [1,2,1].So I stripped it down and wrote just a pixel reader.
I immap the file, read the whole image with imgs3r and then select
specific pixel column, row, plane to check.I address the pixel by multiple methods:* Explicitly calculate the offset and read directly from the Memr[].* Pass Memr[array pointer] to another procedure where it is declared
as a multidimension array and referenced in the normal way.* calculate the offset and copy the specific plane into another MALLOCed
array which I again read both with an explicit offset and in a subroutine
as a 2d array.All 4 methods are consistant with each other and return the same value.
When I compare the 32 and 64 bit versions I get different results. The
32 bit version gives the correct result (verified by reading and
examining the image with ds9).The 64 bit version gives the correct results for the first half of the
first row of the first plane. That is, pixels [1:450,1,1] are read
correctly. But beginning with [451,1,1] an incorrect pixel is accessed.64 bit location -> mapped to (correct) 32 bit location
[451,1,1] -> [1,2,1]
[452,1,1] -> [2,2,1]
...
[1,2,1] -> [1,3,1]
etc.Starting at plane 1, row 513 it starts mapping onto the 2nd plane.
cols 451:900 don't seem to be addressable. At least I haven't found
where they get mapped to. Starting at plane 4 it starts getting into
what looks like a 0 filled area. I haven't invested any time exploring
up there.Has anyone else seen this behavior? At first glance this doesn't look
quite like the sort of issue that P2R addresses.It seems like the issue is with fits io procedures. The way the array is
dimensioned should be completely indepent of the Memr mechanism so 450
(900/2) should not be any sort of magic number. But imgs3r does have the
dimension values passed to it.I haven't tried accessing subsections of the image in the imgs3r call
or trying to trick it with bogus dimensions.Thanks for any pointers that could help with this.RichardThe relevant code snippets follow:pointer immap(), imgs3r()
pointer ioimg, pxbuf, pxpl
real pixval
...
ioimg=immap(fnam,READ_ONLY,0)
nax = imgeti(ioimg,"i_naxis") # dimensions and offsets
nax1 = imgeti(ioimg,"i_naxis1")
nax2 = imgeti(ioimg,"i_naxis2")
nax3 = imgeti(ioimg,"i_naxis3")
pxbuf = imgs3r(ioimg, 1,nax1,1,nax2,1,nax3)
plsize = nax1 * nax2
size = plsize * nax3
call malloc(pxpl, plsize, TY_REAL)
...
offset = (ipl-1)*plsize + (irow-1)*nax1 + icol-1
pixval=Memr[pxbuf+offset]
# some printf statements...call amovr(Memr[pxbuf+(ipl-1)*plsize],Memr[pxpl],plsize)
offset = (irow-1)*nax1 + icol-1
pixval=Memr[pxpl+offset]
# some printf statements...# a bunch of printf statements are in the arr subroutines.
call arr3d(Memr[pxbuf], nax1,nax2,nax3, icol,irow,ipl)
call arr2d(Memr[pxpl], nax1,nax2, icol,irow)
...

I'm looking into. It is a 64-bit problem in the IMIO interface, not a bug in your code. Will post a summary when it is tracked down.

I've verified the problem is fixed for the next release and put and updated libex.a atftp://iraf.noao.edu/iraf/v215/support/linux64/libex.aDownload in binary mode and install in your $iraf/bin.linux64 directory, then relink your application to verify the fix. To relink the entire system with this change:[code:1:aa2c73996a]
% cd $iraf
% make linux64
% make update
[/code:1:aa2c73996a]You'll need to relink the external packages individually.A patched 'macintel' library was updated as well, follow the above instructions with the 'macintel' architecture name.If you still have problems, post back.