iraf.net

I define a 64x64 pix frame buffer by following the documented procedure:
1. edit graphcap. I merely copied the imt128 entry then replaced all 128's by 64's, called this buffer # 63 and imt63
2. add 63 4 64 64 imt53 to end of .imtoolrc
3. start ds9 or ximtool
4. start cl (or pyraf) then do
reset graphcap = /home/xxx/mygraphcap
gflush
reset stdimage = imt63

But when I display a 64x64 chunk of e.g. dev$pix, it is sliced into 4 copies that are 1/4 the correct height, i.e. the word bits are sliced into 4 copies.

If I do this on a 32-bit system then I get only 2 slices of the input words that are 1/2 the correct height.

On either system if I specify e.g. 50x50 region I get completely garbled output, so this is definitely related to word slicing.

This is iraf 2.16.0 on Fedora 20 laptop w/ 12 GB RAM.

Is this fixed in 2.16.1? I'm using Ureka installation on 64-bit laptop and vanilla IRAF distribution on 32 bit.

Seems to work fine for me, there haven't been any changes to this part of the code in forever. Any chance you forgot to change the ":cn" entry of the graphcap to be config number 63? Otherwise, check to see whether there is a /usr/local/lib/imtoolrc file or something defined in your environment that might be naming a different file or might be picked up by DS9 before the $HOME/.imtoolrc version. It might also be something peculiar to the ureka setup, I doubt it is a 32-vs-64 bit thing.

Mike, here are the entries

mygraphcap (the only one used)
imt63|imtsami|SAMI frame buffer:cn#63r#50:yr#50:\
:LC:BS@:z0#1:zr#200D=node!imtool,,50,50:tc=iism70:

.imtoolrc (ditto)
63 4 50 50 # imt63|imtsami

Looksok to me.

Actually both laptops are 64 bits on the Linux side. I don't have a 32-bit installation to test.
But one is Ureka the other vanilla. ximtool 2.0-UR and ds9 7.0.2

and /usr/local/lib/imtoolrc is simlink to /iraf/iraf/dev/imtoolrc which actually doesn't exist because that vanilla iraf installation was replaced by Ureka installed in user space. I removed that link but the display problem remains.

I renamed all imtoolrc to Oimtoolrc and graphcap to Ographcap then copied graphcap and my .imtoolrc to ~/Ureka/iraf/dev They are the only ones picked up in my PATH.

reset stdimage = imt63
is confirmed by gdevice to be in there but display problem persists. I also replaced Ureka's 7.0.2 installation of ds9 w/ 7.2 and no fix. I'll check work installation on Monday first, which isn't Ureka based. If that functions properly then I'll contact Ureka folk because your experience suggests a problem w/ their IRAF installation.

DS9 v7.2 is known to be broken wrt iraf image display so it would be better to revert to the older version (or install 7.3 or later from ds9.su.edu).

The imtoolrc file is used on the server side (i.e. ds9) to map the config number (":cn") sent in the IIS header to a specific frame buffer size. The /usr/local/lib/imtoolrc file (or the symlink to $iraf/dev/imtoolrc) is normally where this is found, the $HOME/.imtoolrc is a backup. Note however that DS9 has a built-in table of size as well, to be used in case the imtoolrc isn't found. It may be that the warning in the imtoolrc comments to start the config numbers at 64 should be taken literally so this internal table isn't confused, try changing the '63' to a '64' in the imtoolrc/mygraphcap to see if it helps.

Otherwise, you can define a 'DEBUG_IIS' unix environment variable before starting ds9 to have the IIS traffic printed out: in there should be a 'set wcs' packet where you should see the config number. If you're not sure how to read this, post the top few lines until it starts repeating with the data writes.

Resolved! The problem was indeed due to broken ds9. 7.2 and 7.0.2 at least failed as I described. But the current ds9 beta 7.3b5 works correctly w/ custom buffer sizes under 2.16.0. I doubt that Ureka currently ships this ds9 so users should beware.

I've not tested recent ximtool releases.