|
Документ взят из кэша поисковой машины. Адрес
оригинального документа
: http://hea-www.harvard.edu/PROS/PUG/node22.html
Дата изменения: Unknown Дата индексирования: Mon Oct 1 23:08:33 2012 Кодировка: Поисковые слова: п п п п п п п п п п п п п п п п п п п п п п |
This section is an attempt to keep track of things that might cause confusion, errors, etc., because of the evolution of the PROS software. Most of these items are reported in earlier sections.
An error involving a missing tasks parameter indicates that the parameter file may have changed between the last time the task was used and the current version. Deleting the uparm directory every time a new build is released is a drastic way to solve the problem. However, the problem can be dealt with on a task by task basis, by typing unlearn `task' to reset the parameter file to the `current' default. If still in trouble, delete the parameter file in `myiraf/uparm' corresponding to the task (the names are somewhat contrived, but with a bit of imagination it is not too difficult to identify the right one).
Note that the exposure and vignetting masks are appropriate only for the reference image, i.e., any change in the dimension of the reference file requires that a new mask be made. See `help exposure'.
Any change in size, either through blocking
factors or sections, will change the logical
coordinate system.
In other words, the logical center of the 1024
1024 original QPOE file (512, 512), will become (256, 256) when a block=2 is applied.
Coordinates that you use to define a section of an image or QPOE file must be in the logical coordinate system of the affected file. For example, the ``[200:300,200:300]'' in ``rp90[200:300,200:300]'' are in the logical coordinate system of the rp90 image (which may differ from its physical coordinate system).
It is important to understand how the task imcnts uses region masks.
Regions given on separate lines, and not logically connected
(i.e., with a boolean operator), are treated as separate regions, but
they are not necessarily independent.
A problem may arise when there are overlapping regions
in the same region descriptor.
Each photon is assigned to only one region: the
most recent region containing the photon's position. In other words,
successive regions overwrite previous regions
that they overlap. A region descriptor of the kind:
will produce a circle of radius 11.25 pixels (region 2) and an adjacent
annulus of inner and outer radius 11.25 and 22.5 pixels (region 1).
A region of the kind:
will produce only a circle with radius 22.5 pixels (region 2).
The first example will give an annulus and a circle; the second example will output only one region, region 2, since region 1 has been entirely written over. (See `help regions'.)
Regions are identified differently in the table header and in the data section. In the header, each region specification is identified by a letter (or other ASCII character), while regions are numbered sequentially in the table. Since some region specifications may define multiple regions (annuli, pie slices), the header may contain fewer region specifications than the resulting number of regions in the table.
The number of region specifications in the header is limited, by the tables package's treatment of ASCII characters (e.g., conversion to upper case), to 33. When the limit is exceeded, the table will still contain the total number of rows and the correct results, but the header information will be unreliable.
File names can contain arithmetic symbols e.g. `+', `-'. However, when files are input to tasks that perform calculations (imcalc is an obvious example), file names must be included in quotes, to avoid confusion. In particular, since imcalc does not require spaces between file names and operands, the quotes are essential.
Region descriptor file names should not begin with upper or lower case `B' or `J' followed by a number whose value is between 1899 and 2101. (The excluded forms are taken as equinox specifications.)
Most IRAF commands will not accept leading dots in real numbers. .5 should always be written as 0.5 to avoid error messages.
Sometimes a task won't run after an error occurs (often when ctrl-c is used to stop a task). Type `flprcache' to stope the subprocesses left over from the aborted task, and then rerun the task in question; it's usually successful. Getting out, and then back into IRAF is the alternate solution when really stuck.