The data from the images isn’t reflected to IRAF.
inosworld wrote on May 08, 2009
Hi.
I could finish to install IRAF successfuly and IRAF run.
I'm using DS9.
ecl>display ***.fits 1 (The image is displayed in DS9)
ecl>noao
noao>digiphot
digiphot>apphot
apphot>phot ***.fits (The black circle cursor appears in the image.)
After that,
the data from the image isn't reflected in IRAF regardless of typing space key with the cursor in the image.
How can I do?
I could finish to install IRAF successfuly and IRAF run.
I'm using DS9.
ecl>display ***.fits 1 (The image is displayed in DS9)
ecl>noao
noao>digiphot
digiphot>apphot
apphot>phot ***.fits (The black circle cursor appears in the image.)
After that,
the data from the image isn't reflected in IRAF regardless of typing space key with the cursor in the image.
How can I do?
Mike Fitzpatrick wrote on May 08, 2009
I'm not sure what you mean by "reflected in IRAF". If I had to guess, I would say that your 'window policy' is 'click to focus', and so you would need to click on the DS9 image window in order for the input to be focused on the DS9 window so it can read the space keystroke. Depending on the platform you are using the instructions for changing this will vary, for now, click on the DS9 window border before trying to enter any keystrokes (and remember to click on the terminal window to reset the focus there). Post back if you still have problems.
-Mike
-Mike
inosworld wrote on May 08, 2009
Thanks a lot.
I just tried to do that. But I still have problems.
apphot> phot ****.fits
Warnings: Graphics overlay not available for display device.
After that,
I tried to focus on the DS9 window, and entered space key.
But the data from the image isn't displayed in the IRAF window.
In addition, I tried to execute /iraf/iraf/unix/hlib/sysinfo.
But, There are no warnings and errors.
I don't know what the cause is.
I just tried to do that. But I still have problems.
apphot> phot ****.fits
Warnings: Graphics overlay not available for display device.
After that,
I tried to focus on the DS9 window, and entered space key.
But the data from the image isn't displayed in the IRAF window.
In addition, I tried to execute /iraf/iraf/unix/hlib/sysinfo.
But, There are no warnings and errors.
I don't know what the cause is.
Mike Fitzpatrick wrote on May 08, 2009
The 'graphics overlay' warning is normal, these were never implemented in IRAF and the disturbing message should probably be removed. In any case, what, if anything, do you see in response to the space bar in the DS9? What platform are you using? Do other tasks like IMEXAMINE work and do you need to do the border-click-to-focus trick?
-Mike
-Mike
inosworld wrote on May 08, 2009
Thanks a lot.
>what, if anything, do you see in response to the space bar in the DS9?
No, I couldn't see anything.
But when I typed "q" key, the following message appears in the IRAF window.
[Hit return to continue, n next image, q quit, w quit and save parameters]
After That, I focused on the IRAF window, and typed "q" again.
Then The above message disappeared, and The shape of the cursor returned.
>What platform are you using?
I'm using Fedora 10.
>Do other tasks like IMEXAMINE work.
I tried IMEXAMINE.
It was the same with case of PHOT.
>Do you need to do the border-click-to-focus trick?
What's the border-click-to-focus trick?
>what, if anything, do you see in response to the space bar in the DS9?
No, I couldn't see anything.
But when I typed "q" key, the following message appears in the IRAF window.
[Hit return to continue, n next image, q quit, w quit and save parameters]
After That, I focused on the IRAF window, and typed "q" again.
Then The above message disappeared, and The shape of the cursor returned.
>What platform are you using?
I'm using Fedora 10.
>Do other tasks like IMEXAMINE work.
I tried IMEXAMINE.
It was the same with case of PHOT.
>Do you need to do the border-click-to-focus trick?
What's the border-click-to-focus trick?
Mike Fitzpatrick wrote on May 08, 2009
It sounds like a focus problem, i.e. when you start PHOT the input focus is on the terminal window but then the image cursor appears so you can type commands. For DS9 to read the cursor though, you need to first click on the border of the DS9 window so the input focus is on DS9 and the keystroke will be read. The 'focus policy' can usually be set by some sort of control center in your windowing system, changing it to "focus-follow-mouse' will let you simply move the mouse to the DS9 window and type the keystroke.
-Mike
-Mike
inosworld wrote on May 08, 2009
Thanks a lot for your reply.
I changed 'focus policy' to "focus-follow-mause", and retried.
but I still have the problem.
In addition, I tried to run IRAF on Windows VISTA( in the same PC with Fedora 10). Then I did without problems.
But I wont to run IRAF on Fedora 10.
I really appreciate your help.
-Yoshi
I changed 'focus policy' to "focus-follow-mause", and retried.
but I still have the problem.
In addition, I tried to run IRAF on Windows VISTA( in the same PC with Fedora 10). Then I did without problems.
But I wont to run IRAF on Fedora 10.
I really appreciate your help.
-Yoshi
Mike Fitzpatrick wrote on May 08, 2009
Do *any* keystrokes work, e.g. the '?' for instance? Both PHOT and IMEXAM have the concept of an 'image cursor' and a 'graphics' cursor and use the 'i' and 'g' keystrokes to switch between them. PHOT will also work entirely off a contour plot depending on the value of the 'display' parameter.
If you simply want to test the image display cursor readback, try using the RIMCURSOR task (type the EOF when you are done, otherwise it should echo the keystrokes you type). If this works, the try unlearning the PHOT parameters and perhaps also the APPHOT package params, e.g.
-Mike
If you simply want to test the image display cursor readback, try using the RIMCURSOR task (type the EOF when you are done, otherwise it should echo the keystrokes you type). If this works, the try unlearning the PHOT parameters and perhaps also the APPHOT package params, e.g.
cl> unlearn apphot phot-Mike
Rebekah wrote on May 08, 2009
Hello
I am trying to use imexamine in IRAF but when i click on the image to examine it the cursor jumps to the left hand corner of the screen and thus examines the wrong area of the image, if anything. This problem seems similar to the ones mentioned above.
I am trying to use imexamine in IRAF but when i click on the image to examine it the cursor jumps to the left hand corner of the screen and thus examines the wrong area of the image, if anything. This problem seems similar to the ones mentioned above.
Mike Fitzpatrick wrote on May 08, 2009
What platform is this on (I assume linux of some kind??) and what window system are you using? Does changing the mouse policy to focus-follows-mouse change the behavior?
-Mike
-Mike
Rebekah wrote on May 08, 2009
I am using fedora8 and xgterm. No changing the mouse flow does not change the behaviour. I recently discovered that if the standard size of the image is set to 512 i.e. set stdimage=imt512 then imexamine seems to work, but with any bigger image it does not.
Chris Simpson wrote on May 08, 2009
I'll tag on here because I'm at the same institute as Rebekah (where we have a system-wide IRAF distribution) and have what is undoubtedly a related problem, although the symptoms are different.
My problem is that the image cursor only responds to the keystroke "q". So, in IMEXAM or PHOT, I get the image cursor and focus on the ds9 window and I can press keys to my heart's content but nothing happens unless I press "q" (which exits the task, obviously).
If I type "=imcur" from the ecl prompt, I get no response unless I press "q", which provides
0.000 0.000 100 q
so note the incorrect x and y values. Running RIMCURSOR produces no response unless I press "q" (or ":"), which throws the cursor to the top left of the screen. And I can only escape RIMCURSOR by typing Ctrl-C. I'm guessing this might mean that IMEXAM does read the cursor but fails to respond because it obtains coordinates of (0,0) which is off-image, and so fails to act.
I just investigated Rebekah's problem and I note that imcur is not providing the correct x and y values for her (although it does recognize all keystrokes), so this sounds like it can explain her problem.
So, if it's a problem reading the image cursor, any idea which files are likely to be the culprits?
My problem is that the image cursor only responds to the keystroke "q". So, in IMEXAM or PHOT, I get the image cursor and focus on the ds9 window and I can press keys to my heart's content but nothing happens unless I press "q" (which exits the task, obviously).
If I type "=imcur" from the ecl prompt, I get no response unless I press "q", which provides
0.000 0.000 100 q
so note the incorrect x and y values. Running RIMCURSOR produces no response unless I press "q" (or ":"), which throws the cursor to the top left of the screen. And I can only escape RIMCURSOR by typing Ctrl-C. I'm guessing this might mean that IMEXAM does read the cursor but fails to respond because it obtains coordinates of (0,0) which is off-image, and so fails to act.
I just investigated Rebekah's problem and I note that imcur is not providing the correct x and y values for her (although it does recognize all keystrokes), so this sounds like it can explain her problem.
So, if it's a problem reading the image cursor, any idea which files are likely to be the culprits?
Mike Fitzpatrick wrote on May 08, 2009
Check for a /usr/local/lib/imtoolrc symlink pointing to the $iraf/dev/imtoolrc file. This is used to define the various frame buffer sizes and should be created when the install script is run (but might be missing ig e.g. you're using a SciSoft distribution or installed from an rpm file). If it is missing you can copy the dev$imtoolrc file to ".imtoolrc" in your unix login directory and restart the ds9/ximtool.
If you reset your stdimage to be e.g. imt2048 but still only see the central 512x512 pixels of an image then this is probably your problem. Note this doesn't explain any problem with reading the graphics cursor command, but might explain why the coords are wrong and should be checked first. Write back it you still have problems.
-Mike
If you reset your stdimage to be e.g. imt2048 but still only see the central 512x512 pixels of an image then this is probably your problem. Note this doesn't explain any problem with reading the graphics cursor command, but might explain why the coords are wrong and should be checked first. Write back it you still have problems.
-Mike
Chris Simpson wrote on May 08, 2009
Thanks for the reply. Sadly there seems to be no problem with the image display device -- the file is there and correctly links -- so that's not the problem. Image display is fine -- we both see as much of the image as the stdimage setting allows. Tasks like TVMARK also plot at the correct position on the image. And setting the image cursor in a task like IMEXAM to a previously prepared file (with lines like "230.2 470.1 100 r") works OK for both of us.
I have discovered that I'm simply experiencing a slow response to all keystrokes apart from "q" and ":" because if I simply hold another key down, I get the results I desire (at the correct location on the image) after maybe half a second. Because "q" and ":" produce an immediate response, this still looks like an IRAF problem (or else all keys would be slow to respond).
I have discovered that I'm simply experiencing a slow response to all keystrokes apart from "q" and ":" because if I simply hold another key down, I get the results I desire (at the correct location on the image) after maybe half a second. Because "q" and ":" produce an immediate response, this still looks like an IRAF problem (or else all keys would be slow to respond).
Jaehyon Rhee (Jay) wrote on May 08, 2009
I have exactly the same problem which Rebekah posted on June 2, 2009.
Jaehyon Rhee (Jay) wrote on May 08, 2009
I am using fedora 10.
Jaehyon Rhee (Jay) wrote on May 08, 2009
Everything works fine with the 24-bit Ximtool, so I can continue to work anyway. (By the way, make sure you have the numlock key off.)
But, it would be very nice if I can use ds9 also with imexam.
Jay
But, it would be very nice if I can use ds9 also with imexam.
Jay
Chris Simpson wrote on May 08, 2009
Curiouser and curiouser... the problem I have described happens when I have the image displayed at zoom 1 or lower (i.e., zoomed out). When I zoom in with ds9, all keys respond immediately, but I now get Rebekah's problem (cursor moves to top-left of screen and task output is given for an apparently random position on the image).
Mike Fitzpatrick wrote on May 08, 2009
I suspect the problem is in DS9 and would recommend that you be sure you have the latest version. I suspect what's happening is that the cursor read is not responding because DS9 is intercepting them as keystroke shortcuts (e.g. the 'c' prints coords rather than passes through to the image cursor read). The 'q' key is not mapped, but if you want to test this see whether keys on the list at http://hea-www.harvard.edu/RD/ds9/ref/keyboard.html but other ones don't.
Also, are you using any kind of virtualization software, e.g. VMWare or VirtualBox to run linux? We've had reports this can have some unusual problems with X and may explain e.g. the cursor jumping to the corner of the window. The fact the cursor changed to a blinking circle means the client (IRAF) initiated the cursor read correctly, the rest of up to the server being used (DS9 or XImtool).
If it is a DS9 problem you'll have to take it up with Bill Joye at CfA if you can't find a working version. So far, I havent been able to reproduce any of this.
-Mike
Also, are you using any kind of virtualization software, e.g. VMWare or VirtualBox to run linux? We've had reports this can have some unusual problems with X and may explain e.g. the cursor jumping to the corner of the window. The fact the cursor changed to a blinking circle means the client (IRAF) initiated the cursor read correctly, the rest of up to the server being used (DS9 or XImtool).
If it is a DS9 problem you'll have to take it up with Bill Joye at CfA if you can't find a working version. So far, I havent been able to reproduce any of this.
-Mike
Chris Simpson wrote on May 08, 2009
Thanks for the suggestions Mike, but no joy. Although we only have ds9 V5.4, I've downloaded V5.6.3 and confirmed that the problem persists. The only keys which respond immediately are 'q' and ':', all others require holding the key down, irrespective of whether they're on the ds9 shortcut list or not. And I'm running linux as native.
I'll drop Bill Joye an email and see if he's ever heard of this problem. Like jrhee, Rebekah and I are using Fedora 10, so I'm starting to think it's connected with that.
I'll drop Bill Joye an email and see if he's ever heard of this problem. Like jrhee, Rebekah and I are using Fedora 10, so I'm starting to think it's connected with that.
yan wrote on May 08, 2009
I think it's the problem of Fedora 10.
Last post on May 08, 2009