Graphics display problem (possibly major)
Jason Quinn wrote on Dec 02, 2010
Hi, I think I have found a major problem with 2.15 handling multiply displayed images. Graphs produced via imexam (and at least some imexam cursor command's console output) are only using the data from a single image, regardless if the user switches frames.
For instance, suppose I display 6 registered images of the same starfield. And I do "imexam" so I can do a radial plot with an "r" cursor command, which I do over a star in the first image. Now I wish to overplot the same star in the next image. This no longer works. Using the 'z' and 'm' keys now always show data from the first image even if I am in frame 2.
I tried this in both ximtool and ds9. It does not work in 2.15. I also tried in it 2.14. It works there.
Jason
For instance, suppose I display 6 registered images of the same starfield. And I do "imexam" so I can do a radial plot with an "r" cursor command, which I do over a star in the first image. Now I wish to overplot the same star in the next image. This no longer works. Using the 'z' and 'm' keys now always show data from the first image even if I am in frame 2.
I tried this in both ximtool and ds9. It does not work in 2.15. I also tried in it 2.14. It works there.
Jason
Mike Fitzpatrick wrote on Dec 02, 2010
I assume we're talking about IMEXAM here? I'll have a look ....
Jason Quinn wrote on Dec 02, 2010
I am using imexam. I corrected my first post to be more specific.
I am trying various things to see if I am mistaken but it appears that it always wants to use a single image for the data to plot or summarize when mutliple images are displayed.
Also this is the linux64 version.
I am trying various things to see if I am mistaken but it appears that it always wants to use a single image for the data to plot or summarize when mutliple images are displayed.
Also this is the linux64 version.
Francisco Valdes wrote on Dec 02, 2010
Hi Jason,
Yes this is a fairly fundamental problem with 64-bit enabled systems. Before I dive into IMEXAM the more fundamental demonstration is:
I got this for any frame I was in when I did the cursor read. It should return 101, 201, ... for the third field.
Given this problem demonstration (which I did with ximtool but your report probably says it applies to ds9 as would be expected) I leave it to Mike to investigate this further. I expect this will require a fixed release and would affect any task that reads the cursor (whether a script using "imcur" or compiled like imexamine).
Thanks for the timely report and testing.
Yours,
Frank Valdes
Yes this is a fairly fundamental problem with 64-bit enabled systems. Before I dive into IMEXAM the more fundamental demonstration is:
cl> =imcur
256.992 255.992 0 x
I got this for any frame I was in when I did the cursor read. It should return 101, 201, ... for the third field.
Given this problem demonstration (which I did with ximtool but your report probably says it applies to ds9 as would be expected) I leave it to Mike to investigate this further. I expect this will require a fixed release and would affect any task that reads the cursor (whether a script using "imcur" or compiled like imexamine).
Thanks for the timely report and testing.
Yours,
Frank Valdes
Mike Fitzpatrick wrote on Dec 02, 2010
This turned out to be a missing conversion of a variable (the wcs argument) from SPP to/from a C integer in the libc routine called by the CL to read the image cursor. The effect is that the value returned by the SPP code was always being truncated to 0 on 64-bit systems where the C code was still using a 32-bit integer.
The good news is that it was a simple fix and only really affects the CL binaries. For all of the platforms, I've put a patched ecl.e binary in
ftp://iraf.noao.edu/iraf/v215/support
that fixes this problem. These binaries were also built against the '-lncurses' lib instead of '-ltermcap' in hopes in fixes another nagging problem.
If possible, I'll ask people following this thread to verify the problems is/are solved in the new binaries.
-Mike
The good news is that it was a simple fix and only really affects the CL binaries. For all of the platforms, I've put a patched ecl.e binary in
ftp://iraf.noao.edu/iraf/v215/support
that fixes this problem. These binaries were also built against the '-lncurses' lib instead of '-ltermcap' in hopes in fixes another nagging problem.
If possible, I'll ask people following this thread to verify the problems is/are solved in the new binaries.
-Mike
Jason Quinn wrote on Dec 02, 2010
The problem appears to have been solved, judging from my quick tests. I'm glad it was something relatively easy.
It may just be my imagination but it feels like the rendering of the graphics plots are "snappier" in this build. Perhaps a consequence of ncurses vs termcap.
Thanks,
Jason
It may just be my imagination but it feels like the rendering of the graphics plots are "snappier" in this build. Perhaps a consequence of ncurses vs termcap.
Thanks,
Jason
Mike Fitzpatrick wrote on Dec 02, 2010
If you had said the rendering of 'epar' was a bit faster I might believe you, otherwise there would only be a speed gain over using the static 32-bit binary (and even then, just slight). Anyway, glad it is fixed, thanks again for the report.
Last post on Dec 02, 2010