Myrddin |
11/04/2013 11:12AM (Read 4107 times)
|
|
|
Status: offline
Registered: 11/04/2013
Posts: 4
|
Hi
I'm having trouble making hardcopies with :.snap. I use the tool igi in stsdas package to plot the spectra in three windows. When i try to make the hardcopy i get this:
igi = gcur # to get into the display command line
:. snap eps #Help!
ERROR: floating point overflow
VOCl\$this->_split2($m[0]) gflush #A .eps file is created in the work directory. However this file has 0bytes in size.
Can anyone give me a hand with this?
|
|
|
|
fitz |
11/04/2013 09:40PM
|
|
|
Status: offline
Registered: 09/30/2005
Posts: 4040
|
From the 'floating point overflow" error it's hard to know whether the error is coming from the SGI translator producing the EPS or IGI itself. Note you can set the 'device' parameter to be 'eps' to generate the plot directly without going through the cursor, does this make a difference? Note that you will need to issue the command "gflush" to force the file to be written out (i.e. to avoid a zero-length file).
Otherwise, what version of IRAF and what platform is this? There was a known issue with TABLES/STSDAS because they are 32-bit only where certain commands broke when talking to the 64-bit CL. The workaround in that case was to install a 32-bit version of the CL from
ftp://iraf.noao.edu/iraf/v216/support//vocl.e
where would be either 'linux' or 'macosx' and where you would replace the 'linux64' or 'macintel' binaries respectively.
I've tried a plot from the IGI help page and didn't see a problem in the v2.16.1 system. Since you have a 'vocl\$this->_split2($m[0])' prompt you're using at least v2.16 so you can update to the latest using the commands
% cd $iraf ; make latest
Lastly, does this happen only with this one plot or with anything using IGI?
|
|
|
|
haha |
11/07/2013 12:12PM
|
|
|
Status: offline
Registered: 10/25/2013
Posts: 39
|
.snap could save a jpeg or png file?
Quote by: fitz
From the 'floating point overflow" error it's hard to know whether the error is coming from the SGI translator producing the EPS or IGI itself. Note you can set the 'device' parameter to be 'eps' to generate the plot directly without going through the cursor, does this make a difference? Note that you will need to issue the command "gflush" to force the file to be written out (i.e. to avoid a zero-length file).
Otherwise, what version of IRAF and what platform is this? There was a known issue with TABLES/STSDAS because they are 32-bit only where certain commands broke when talking to the 64-bit CL. The workaround in that case was to install a 32-bit version of the CL from
ftp://iraf.noao.edu/iraf/v216/support//vocl.e
where would be either 'linux' or 'macosx' and where you would replace the 'linux64' or 'macintel' binaries respectively.
I've tried a plot from the IGI help page and didn't see a problem in the v2.16.1 system. Since you have a 'vocl\$this->_split2($m[0])' prompt you're using at least v2.16 so you can update to the latest using the commands
% cd $iraf ; make latest
Lastly, does this happen only with this one plot or with anything using IGI?
|
|
|
|
fitz |
11/07/2013 04:08PM
|
|
|
Status: offline
Registered: 09/30/2005
Posts: 4040
|
There is no direct support for JPEG or PNG, however there are 'g-gif', 'g-xbm' and 'g-svg' device names to produce GIF, XBM and SVG formats respectively (e.g. ":.snap g-gif"). The file produced is call "sgiXXXX.gif" (or with appropriate extensions) in the current directory. As always, a ":.gflush" is required to finalize the file creation.
|
|
|
|
haha |
11/07/2013 04:36PM
|
|
|
Status: offline
Registered: 10/25/2013
Posts: 39
|
Quote by: fitz
There is no direct support for JPEG or PNG, however there are 'g-gif', 'g-xbm' and 'g-svg' device names to produce GIF, XBM and SVG formats respectively (e.g. ":.snap g-gif"). The file produced is call "sgiXXXX.gif" (or with appropriate extensions) in the current directory. As always, a ":.gflush" is required to finalize the file creation.
so there are two steps right?
:.snap g-gif
:.gflush
I produced a gif with a white background. It seems there is no way to save the entire colorful iraf term screen,right?
There is no manual for this kind of methods. How to collect this kind of methods quickly?
|
|
|
|
fitz |
11/07/2013 04:42PM
|
|
|
Status: offline
Registered: 09/30/2005
Posts: 4040
|
Right, both commands are required. The SGI translator is not a full graphics kernel and so color/raster information is lost versus what you see in an XGterm plot. If you have STSDAS installed you can use the 'psidump' device that uses the Postscript kernel and get full color. If you want to save a JPEG you might consider some tool that does a screenshot of the window instead.
|
|
|
|
Myrddin |
11/23/2013 07:48PM
|
|
|
Status: offline
Registered: 11/04/2013
Posts: 4
|
Quote by: fitz
From the 'floating point overflow" error it's hard to know whether the error is coming from the SGI translator producing the EPS or IGI itself. Note you can set the 'device' parameter to be 'eps' to generate the plot directly without going through the cursor, does this make a difference? Note that you will need to issue the command "gflush" to force the file to be written out (i.e. to avoid a zero-length file).
Otherwise, what version of IRAF and what platform is this? There was a known issue with TABLES/STSDAS because they are 32-bit only where certain commands broke when talking to the 64-bit CL. The workaround in that case was to install a 32-bit version of the CL from
ftp://iraf.noao.edu/iraf/v216/support//vocl.e
where would be either 'linux' or 'macosx' and where you would replace the 'linux64' or 'macintel' binaries respectively.
I've tried a plot from the IGI help page and didn't see a problem in the v2.16.1 system. Since you have a 'vocl\$this->_split2($m[0])' prompt you're using at least v2.16 so you can update to the latest using the commands
% cd $iraf ; make latest
Lastly, does this happen only with this one plot or with anything using IGI?
It happens with any file which I try to print. I have the 2.16 version of iraf and the 3.16 version of stsdas package.
Moreover i tried to get a hardcopy directly from an igi script but I get a new error:
vocl\$this->_split2($m[0]) igi device=eps gflush /
vocl\$this->_split2($m[0]) /bin/sh: 1: sgidispatch: not found
I have been looking for solutions for 'the hardcopy problem' for a few days, and the only thing I found was this link, but I dont understand your solution (I am kind of noob in iraf and in ubuntu):
ftp://iraf.noao.edu/ftp/web/sites/list2/0795.html
I give you a screenshot with the error message.
Thanks in advance.
|
|
|
|
Myrddin |
11/23/2013 07:52PM
|
|
|
Status: offline
Registered: 11/04/2013
Posts: 4
|
|
|
|
|
fitz |
11/23/2013 08:16PM
|
|
|
Status: offline
Registered: 09/30/2005
Posts: 4040
|
Since this appears to be a problem with the Ureka distribution I recommend you contact their helpdesk (help@stsci.edu).
The 'sgidispatch' command is normally created in the same directory as commands like 'cl' and 'mkiraf' and should be in a directory in the path defined in your .cshrc/.bashrc file. The 'psi_land' device uses the PostScript graphics kernel in STSDAS and is defined in the default dev$graphcap file, however it appears you don't have STSDAS installed. As a first step you might try installing the package per the Ureka instructions.
|
|
|
|