|
|
| Line 1: |
Line 1: |
| | __NOTOC__ | | __NOTOC__ |
| | === Synopsis === | | === Synopsis === |
| − | : grmatch [options] -r <reference> -i <input> [-o <output>] | + | : grtransh [options] <input> [-o <output>] |
| | | | |
| | === Description === | | === Description === |
| − | : The program `grmatch` matches lines read from two input files, namely from a reference and from an input file. All implemented algorithms are symmetric, in the manner that the result should be the same if these two files are swapped. The only case when the order of these files is important is when a geometrical transformation is also returned (see point matching below), in this case the swapping of the files results the inverse form of the original transformation. The lines (rows) can be matched using various criteria. 1. Lines can be matched by identifier, where the identifier can be any concatenation of arbitrary, space-separated columns found in the files. Generally, the identifier is represented by a single column (e.g. it is an astronomical catalog identifier). The behaviour of the program can be tuned for the cases when there are more than one rows with the same identifier. 2. Lines can be matched using a 2-dimensional point matchig algorithm. In this method, the program expects two-two columns both from the reference and input files which can be treated as X and Y coordinates. If both point lists are known, the program tries to find the appropriate geometrical transformation which transforms the points from the frame of the reference list to the frame of the input list and, simultaneously, tries to find as many pairs as possible. The parameters of the geometrical transformation and the whole algorithm can be fine-tuned. 3. Lines can be matched using arbitrary- (N-) dimensional coordinate matching algorithm. This method expects N-N columns both from the reference and input files which can be treated as X_1, ..., X_N Cartesian coordinates and the method assumes both of the point sets in the same reference frame. The point 'A' from the reference list and the point 'P' from the input list forms a pair if the closest point to 'A' from the input list is 'P' and vice versa. | + | : The main purpose of the program `grtrans` is to transform coordinate lists and fit transfomrations to input data. The transformation can be one of the following methods. 1. Evaluate polynomial functions (with arbitrary order)of two independent values. 2. Two dimensional spherical projection (converting to RA/DEC or longitude/latitude values to projected coordinates on a given tangent plane. 3. Two dimensional spherical de-projection (converting tangent planar coordinates to RA/DEC or longitude/latitude values). 4. Compose arbitrary polynomial functions of two independent values with arbitrary two-dimensional affine (or linear) transformations. The program also can be used to fit functions, namely fit the coefficients of arbitrary-order polynomial functions of two independent values or fit WCS distortion parameters. |
| | | | |
| | === Options: === | | === Options: === |
| | | | |
| − | === General options: === | + | === General administrative options: === |
| | | | |
| | : '''-h,''' '''--help''' | | : '''-h,''' '''--help''' |
| Line 20: |
Line 20: |
| | | | |
| | : '''-C,''' '''--comment''' | | : '''-C,''' '''--comment''' |
| − | :: Comment the output (both the transformation file and the match file). | + | :: Comment the output. |
| | | | |
| − | === Options for input/output specifications: === | + | === Options for input/output specification: === |
| − | | + | |
| − | : '''-r''' <referencefile>, '''--input-reference''' <referencefile>
| + | |
| − | :: Mandatory, name of the reference file.
| + | |
| | | | |
| | : <inputfile>, '''-i''' <inputile>, '''--input''' <inputfile> | | : <inputfile>, '''-i''' <inputile>, '''--input''' <inputfile> |
| − | :: Name of the input file. If this switch is omitted, the input isread from stdin (specifying some input is mandatory). | + | :: Name of the input file. If this switch is omitted, the input is read from stdin (specifying some input is mandatory). |
| | | | |
| | : '''-o''' <output>, '''--output''' <output>, '''--output-matched''' <output> | | : '''-o''' <output>, '''--output''' <output>, '''--output-matched''' <output> |
| − | :: Name of the output file, containing the matched lines. The matched lines are pasted lines, the first part is from the reference file and the second part is from the input file, these two parts are concatenated by a TAB character. This switch is optional, if it is not specified, no such output will be generated. | + | :: Name of the output file, if the program was used for transforming coordinate lists. |
| | | | |
| − | : '''--output-excluded-reference''' <out>, '''--output-excluded-input''' <out> | + | : '''-T,''' '''--input-transformation''' <output-transformation-file> |
| − | :: Names of the files which contain the valid but excluded lines from the reference and from the input. These outputs are disjoint from the previous output and altogether contaions all valid lines.
| + | :: Name of the input transformation file (see also the notes below). |
| − | | + | |
| − | : '''--output-id''' <out>
| + | |
| − | :: Name of the file which contaions only the identifiers of the matched lines. If the primary matching method was not identifier matching, one should specify the column indices of the identifiers by '''--col-ref-id''' and '''--col-inp-id''' also. | + | |
| | | | |
| | : '''--output-transformation''' <output-transformation-file> | | : '''--output-transformation''' <output-transformation-file> |
| − | :: Name of the output file containing the geometrical transformation, in human-readable format, if the matching method was point matching (in other case, this option has no effect). The commented version of this file includes some statistics about the matching (the total number of lines used and matched, the required CPU time, the final triangulation level, the fit residuals and other things like these). | + | :: Name of the output file containing the fitted geometrical transformation, in human-readable format (see also the notes below). |
| | | | |
| − | : In all of the above input/output file specifications, the replacement of the file name by "-" (a single minus sign) forces the reading from stdin or writing to stdout. Note that all parts of the any line after "#" (hashmark) are treated as a comment, therefore ignored. | + | : In all of the above input/output file specifications, the replacement of the file name by "-" (a single minus sign) forces the reading from stdin or writing to stdout. Note that all parts of the any line after "#" (hashmark) are treated as a comment, therefore ignored. |
| | | | |
| − | === ===
| + | : Note that there is no explicit switch for distinguishing between the fitting and the evaluating purposes of the program. If --input-transformation has been specified, the program implies that the user wants to evaluate a function described by this existing transformation file. On the other hand, if --output-transformation has been specified, the program fits the parameters of the function and stores the resulted transformation file as it specified by the argument of this option. In other words, if no WCS or spherical (de)projection declared by the directives of --wcs, one of these two switches should be given in the command line. |
| | | | |
| − | === General options for point matching: ===
| |
| | | | |
| − | : '''--match-points''' | + | === General options for fitting polynomial coefficients: === |
| − | :: This switch forces the usage of the point matching method. By default, this method is assumed to be used, therefore this switch can be omitted.
| + | |
| | | | |
| − | : '''--col-ref''' <x>,<y>, '''--col-inp''' <x>,<y> | + | : '''--col-xy''' <x>,<y> |
| − | :: The column indices containing the X and Y coordinates, for the reference and for the input file, respectively. The index of the first column is always 1, the index of the second is 2 and so on. Lines in which these columns do not contain valid real numbers bers are omitted. | + | :: Column indices for the independent values. In the current implementation, grtrans can only fit polynomial functions of exactly 2 independent variables. Lines where these columns do not contain valid real numbers are excluded. |
| | + | |
| | + | : '''--col-fit''' <>[,<>[,<>]...] |
| | + | :: Column indices for the dependent values. In the current implementation, grtrans can only fit 2 dimensional polynomial functions to arbitrary dimensional data. The dimension of the fitted data is specified indirectly, by the number of column indices specified after this switch. |
| | | | |
| | : '''-a''' <order>, '''--order''' <order> | | : '''-a''' <order>, '''--order''' <order> |
| − | :: This switch specifies the polynomial order of the resulted geometrical transformation. It can be arbitrary positive integer. Note that if the order is A, at least (A+1)*(A+2)/2 valid points are needed both from the reference and both from the input file to fit the transformation. | + | :: Order of the fitted polynomial function. It can be any positive integer. |
| | + | |
| | + | : '''-n''' <N>, '''--iterations''' <N>; '''-r''' <S>, '''--rejection-level''' <S> |
| | + | :: These switches specify the total number of rejection iterations of outlyer points and the rejection level in sigma units. By default, no rejection is applied, therefore all valid lines are used. |
| | + | |
| | + | : '''--col-weight''' <w> |
| | + | :: Column index for optional weights. If specified, this column should contain a valid non-negative real number which is used as a weight during the least-squares fit. |
| | + | |
| | + | : '''--weight''' [magnitude],[power=<P>] |
| | + | :: These directives specify the weights which are used during the fit of the functions or transformations. For example, in practice it is useful in the following situation. We try to match star lists, then the fainter stars are believed to have higher astrometrical errors, therefore they should have smaller influence in the fit. We can take the weights from a given colum, specified by the index after '''--col-weight''' (see above). The weights can be derived from stellar magnitudes, if so, specify magnitude to convert the read values in magnitude to flux. The real weights then is the powerth power of the flux. The default value of the power is 1, however, for the maximum-likelihood estimation of an assumed Gaussian distribution, the weights should be the second power of the fluxes. |
| | + | |
| | + | : '''-ot,''' '''--output-transformation''' <output-transformation-file> |
| | + | :: Name of the output transformation file containing the result of the fit (see above). |
| | + | |
| | + | === General options for transformation or function evaluation: === |
| | + | |
| | + | : '''--input-transformation''' <input-transformation-file> |
| | + | :: Name of the input transformation file containing the desired transformation (see above). |
| | + | |
| | + | : '''--reverse,''' '''--inverse''' |
| | + | :: Perform inverse transformation. This is a valid option only if the dimension of the fitted function is the same as the dimension of the independent variables (namely, 2, because in the actual implementation the latter can only be 2). |
| | + | |
| | + | : '''--col-xy''' <x>,<y> |
| | + | :: Column indices for the independent values. In the current implementation, `grtrans` can only fit polynomial functions of exactly 2 independent variables. Lines where these columns do not contain valid real numbers are excluded. |
| | + | |
| | + | : '''--col-out''' <>[,<>[,<>]...] |
| | + | :: Column indices for the evaluated output variables. The number of indices listed here should be the same as the number of independent functions stored in the input transformation file. |
| | + | |
| | + | === General options for transformation composition: === |
| | + | |
| | + | : '''--input-transformation''' <input-transformation-file> |
| | + | :: Name of the input transformation file. |
| | + | |
| | + | : '''--scale''' <s> |
| | + | :: Scale factor. |
| | + | |
| | + | : '''--offset''' <dx>,<dy> |
| | + | :: Shift. The affine transformation with which the input transformation is composed is going to be: x'=dx+s*x, y'=dy+s*y. |
| | + | |
| | + | : '''--output-transformation''' <output-transformation-file> |
| | + | :: Name of the output transformation file containing the result of the composition. |
| | + | |
| | + | === Options for spherical projection and deprojection: === |
| | + | |
| | + | : '''--wcs''' [sin|arc|tan],ra=<R>,dec=<D>,[degrees|radians|scale=<S> |
| | + | :: This set of directives specify the common parameters of the spherical projection or deprojection. The sin, arc and tan directives set the type of projection to orthographic, arc and gnomonic, respectively. The values after ra and dec (<R> and <D>) specify the center of the projection (right ascension and declination, respectively, in degrees). The degrees, radians or the scale=<S> directives specify the scaling of the output. The directive degrees is equivalent to set scale=57.29577951308232087721 (180 over \Pi), this is the default. The directive radians is equivalent to set scale=1. |
| | + | |
| | + | : '''--col-radec''' <r>,<d> |
| | + | :: Column indices for RA and DEC values. This option implies projection. |
| | + | |
| | + | : '''--col-pixel''' <x>,<y> |
| | + | :: Column indices for X and Y projected values. This option implies deprojection. |
| | + | |
| | + | : '''--col-out''' <>,<> |
| | + | :: Column indices for the output values (which are X and Y for projection and RA, DEC for deprojection). |
| | + | |
| | + | === Options for fitting WCS information: === |
| | + | |
| | + | : '''--wcs''' [sin|arc|tan],ra=<R>,dec=<D>,order=<order> |
| | + | :: This set of directives specify the common parameters of WCS fitting. The projection can be orthographic, arc or gnomonic (however, there are dosens of projections implemented in the FITS WCS system, but for practical purposes, such projections seem to be more than enough). The center of the fit is set by ra and dec (RA and DEC, in degrees). The distortion order is specified by order. Note that the RA and DEC values specified here can only be an assumed values. |
| | + | |
| | + | : '''--col-ref''' <>,<> |
| | + | :: Column indices for the Ra and Dec values. |
| | + | |
| | + | : '''--col-fit''' <>,<> |
| | + | :: Column indices for the pixel values. |
| | + | |
| | + | : Note that in this case, the set of the appropriate FITS keyword=value pairs are written directly stdout, not in the file specified by the options --output or --output-transformation. |
| | + | |
| | + | |
| | + | === Examples: === |
| | + | |
| | + | : Here is an example for a complete astrometry problem which demonstrates the proper usage of the programs grmatch and grtrans. Let us assume that we have 1/ a reference star catalogue, named "catalog.dat", a file with four columns: the first is the identifier of the star, the second and third are the celestial coordinates (RA and DEC, in degrees), and the last is the magnitude of the stars; 2/ an astronomical image, named "img.fits" (not crucial for the astrometry itself, it is required only by the demonstration of the export of FITS WCS headers); and 3/ a list of decected stars (from "img.fits"), named "img.star", a file with three columns: the first two are the pixel coordinates and the third is an estimation of the flux (in ADUs, not in magnitudes). |
| | | | |
| − | : '''--max-distance''' <maxdist>
| |
| − | :: The maximal accepted distance between the matched points in the coordinate frame of the input coordinate list (and not in the coordinate frame of the reference coordinate list). Possible pairs (which are valid pairs due to the symmetric coordinate matching algorihms) are excluded if their Eucledian distance is larger than maxdist. Note that this option has no initial value, therefore, if omitted, all possible pairs due to the symmetric matching are resulted, which, in certain cases in practice, can result unexpected behaviour. One should always specify a reasonable maximal distance which can be estimated only by the knowledge of the physics of the input files.
| |
| | | | |
| − | : See more options concerning to point matching in the section "Fine-Tuning of Point Matching" below. That section also describes the tuning of the triangulation used by the point matching algorithm. For a more detailed description about the point matching algorithms based on pattern and triangle matching see [1], [2] or [3]. | + | : Let us also denote the celestial coordinates of the center of the image by R and D, the RA and DEC values, in degrees and, for example let R=220 and D=25, a field in the Bootes. Let us also assume that the size of our field (both the catalog and the list of the deceted stars) is 3 degrees and there are approximately 4000-4000 stars both in the reference catalog and in the list of the detected stars. Because we have such a large amount of stars, one can use only a fraction of them for triangulation. |
| | | | |
| − | === ===
| |
| | | | |
| − | === General options for coordinate matching: ===
| + | : The first step is to make a projection from the sky, centered around the center of our image: |
| | | | |
| − | : '''--match-coord,''' '''--match-coords'''
| |
| − | :: This switch forces the usage of the coordinate matching method. Note that because of the common options with the point matching method, one should specify this switch to force the usage of the coordinate matching method (the default method is point matching, see above).
| |
| | | | |
| − | : '''--col-ref''' <x>[,<y>,[<z>...]] '''--col-inp''' <x>[,<y>,[<z>...]] | + | : |
| − | :: The column indices containing the spatial coordinates, for the reference and for the input file, respectively. The index of the first column is always 1, the index of the second is 2 and so on. Lines in which these columns do not contain valid real numbers are omitted. Note that the dimension of the coordinate matching space is specified indirectly, by the number of column indices listed here. Because of this, the number of column indices should be the same for the reference and input, in other case, when the dimensions are mismatched, the program exits unsuccessfully.
| + | :: grtrans '''--input''' catalog.dat '''--wcs''' tan,degrees,ra=220,dec=25 '''--col-radec''' 2,3 '''--col-out''' 5,6 '''--output''' img.proj |
| | | | |
| − | : '''--max-distance''' <maxdist>
| + | : The second step is the point matching: |
| − | :: The maximal accepted distance between the matched points. Possible pairs (which are valid pairs due to the symmetric coordinate matching algorihms) are excluded if their Eucledian distance is larger than maxdist. Note that this option has no initial value, therefore, if omitted, all possible pairs due to the symmetric matching are resulted (see also point matching, above).
| + | |
| | | | |
| − | === ===
| |
| | | | |
| − | === General options for identifier matching: ===
| + | : |
| | + | :: grmatch '''--reference''' img.proj '''--col-ref''' 5,6 '''--col-ref-ordering''' '''-4''' '''--input''' img.star '''--col-inp''' 1,2 '''--col-inp-ordering''' +3 '''--match-points''' '''--order''' 4 '''--triangulation''' auto,unitarity=0.01,maxnumber=1000,conformable '''--max-distance''' 1 '''--weight''' reference,column=4,magnitude,power=2 '''--comment''' '''--output-transformation''' img.trans |
| | | | |
| − | : '''--match-id,''' '''--match-identifiers''' | + | : This grmach invocation matches the stars from projected reference catalog, "img.proj " and the detected stars. The "--order 4" specifies a fourth-order polynomial fit, which is, in practice, good for a field with the size of 3 degrees. The directives after "--weight" makes the magnitudes taken from the reference file to be used as a weight for fitting. This invocation yields one new file, "img.trans" which stores the fitted 4th-order polynomial transformation which transforms the projected coordinates to the system of the image. |
| − | :: This switch forces the usage of the identifier matching method.
| + | |
| | | | |
| − | : '''--col-ref-id''' <i>[,<j>,[<k>...]] '''--col-inp-id''' <i>[,<j>,[<k>...]]
| |
| − | :: Column index or indices containing the identifiers, from the reference and from the input file, respectively.
| |
| | | | |
| − | : '''--no-ambiguity,''' '''--first-ambiguity,''' '''--any-ambiguity,''' '''--full-ambiguity''' | + | : The next step is the astrometrical transformation, we create a "local" catalog, which is the original catalog extended with the proper X and Y plate coordinates: |
| − | :: These options tune the behaviour of the matching when there is more than one occurrence of a given identifier in the reference and/or input file. If '''--no-ambiguity''' is specified, these identifiers are discarded, this is the default method. If '''--first-ambiguity''' is specified, only the first occurence is treated as a matched line, independently from the number of occurrences. If the switch '''--any-ambiguity''' is specified, the lines are paired sequentally, until there is any left from the reference and from the input. For example, if there is 4 occurrences in the reference and 6 in the input file of a given identifier, 4 matched pairs are returned. Otherwise, if '''--full-ambiguity''' is specified, all possible combinations of the lines are treated as matched lines. For example, if there is 4 occurrences in the reference and 6 in the input file of a given identifier, all 4*6=24 combinations are returned as matched pairs.
| + | |
| | | | |
| − | === Fine-tuning of point matching: ===
| |
| | | | |
| − | : '''--triangulation''' <parameters> | + | : |
| − | :: This switch is followed by comma-separated directives, which specify the parameters of the triangulation-based point matching algorithm:
| + | :: grtrans '''--input''' img.proj '''--col-xy''' 5,6 '''--input-transformation''' img.trans '''--col-out''' 7,8 '''--output''' img.cat |
| | | | |
| − | : delaunay, level=<level>, full, auto, unitarity=<U> | + | : This invocation yields an other new file, "img.cat" which has 8 columns. The first six columns are the same as it was in "img.proj" (identifier, RA, DEC, magnitude and projected X, Y coordinates), the last two colums are the fitted plate coordinates. Then, the proper WCS headers can be determined by the following call: |
| − | :: These directives specify the triangulation level used for point matching. delaunay forces the usage only of the Delaunay-triangles. This is the fastest method, however, it is only working if the points in the reference and input lists are almost competely overlapping and describe almost the same point sets (within a ratio of common points above 60-70%). The level specifies the level of the expansion of the Delaunay-triangulation (see [1] for more details). In practice, the lower the ratio of common points and/or the ratio of the overlapping, the higher level should be used. Specifying level=1 or level=2 gives a robust but still fast method for general usage. The directive full forces full triangulation. This can be overwhelmingly slow and annoying and requires tons of memory if there are more than 40-50 points (the amounts of these resources are proportional to the 6th(!) and 3rd power of the number of the points, respectively). The directive auto increases the level of the triangulation expansion automatically until a proper match is found. A match is considered as a good match if the unitarity of the transformation is less than the unitarity U specified by the unitarity=U directive (see also the section Notes/Unitarity below).
| + | |
| | | | |
| − | : mixed, conformable, reverse
| |
| − | :: These directives define the chirality of the triangle spaces to be used. Practically, it means the following. If we don't know whether the input and reference lists are inverted respecting to each other, one should use mixed triangle space. If we are sure about that the input and reference lists are not inverted, we can use conformable triangle space. If we know that the input and reference lists are inverted, we can use reverse space. Note that although mixed triangle space can always result a good match, it is a wise idea to fix the chirality by specifying conformable or reverse if we really know that the point sets are not inverted or inverted respecting to each other. If the chirality is fixed, the program yields more matched pairs, the appropriate triangulation level can be smaller and in auto mode, the program returns the match definitely faster.
| |
| | | | |
| − | : maxnumber=<max>, maxref=<mr>, maxinp=<mi> | + | : |
| − | :: These directives specify the maximal number of points which are used for triangulation (for any type of triangulation). If maxnumber is specified, it is equivalent to define maxref and maxinp with the same values. Then, the first <mr> points from the reference and the first <mi> points from the input list are used to generate the triangle sets. The first points are selected using the optional information found in one of the columns, see the following switches. | + | :: grtrans '''--input''' img.cat '''--col-ref''' 2,3 '''--col-fit''' 7,8 '''--wcs''' tan,order=4,ra=220,dec=25 >img.wcs |
| | | | |
| − | : (Note that there should be only one --triangulation switch, all desired directives should be written in the same argument, separated by commas.) | + | : The newly created file, img.wcs contains the FITS "keyword"="value" pairs, which can be exported to "img.fits" to have a standard header extended by the WCS information. For exporting, the program fiheader(1) can be used: |
| | | | |
| − | : '''--col-ref-ordering''' [-]<w>, '''--col-inp-ordering''' [-]<w>.
| |
| − | :: These switches specify one-one column index from the reference and from the input files which are used to order these lists and select the first maxref and maxinp points (see above) for the generation of the two triangle meshes. Both columns should contain valid real numbers, otherwise the whole(!) line is excluded (not only from sorting but from the whole matching procedure). If there is no negative sign before the column index, the data are sorted in descending(!) order, therefore the lines with the lines with the highest(!) values are selected for triangulation. If there is a negative sign before the index, the data are sorted in ascending order by these values, therefore the lines with the smallest(!) values are selected for triangulation. For example, if we want to match star lists, we might want to use only the brightest ones to generate the triangle sets. If the brightnesses of the stars are specified by their fluxes, we should not use the negative sign (the list should be sorted in descending order to select the first few lines as the brightest stars), and if the brightness is known by the magnitude, we have to use the negative sign.
| |
| | | | |
| − | : '''--fit''' iterations=<N>,firstrejection=<F>,sigma=<S> | + | : |
| − | :: Like '''--triangulation,''' this switch is followed by some directives. These directives specify the number <N> of iterations (iterations=<N>) for point matching. The firstrejection directive speciy the serial number <F> of the first iteration where points farer than <S> sigma level are excluded in the next iteration. Note that in practice these type of iteration is really not important (due to, for instance, the limitations of the outliers by the '''--max-distance''' switch), however, some suspicious users can be convinced by such arguments. | + | :: fiheader img.fits '''--rewrite''' '''--update''' $(cat img.wcs) |
| | | | |
| − | : '''--weight''' reference|input,column=<wi>,[magnitude],[power=<p>] | + | : Note that the last two grtrans calls can be replaced by a single pipeline, when the file img.cat is not created: |
| − | :: These directives specify the weights which are used during the fit of the geometrical transformation. For example, in practice it is useful in the following situation. We try to match star lists, then the fainter stars are believed to have higher astrometrical errors, therefore they should have smaller influence in the fit. We can take the weights from the reference (specify reference) and from the input (specify input), from the column specified by the weight-index. The weights can be derived from stellar magnitudes, if so, specify magnitude to convert the read values in magnitude to flux. The real weights then is the powerth power of the flux. The default value of the power is 1, however, for the maximum-likelihood estimation of an assumed Gaussian distribution, the weights should be the second power of the fluxes.
| + | |
| | | | |
| − | : Some notes on unitarity. The unitarity of a geometrical transformation measures how it differs from the closest transformation which is affine and a combination of dilation, rotation and shift. For such a transformation the unitarity is 0 and if the second-order terms in a transformation distort a such unitary transformation, the unitarity will have the same magnitude like the magnitude of this second-order effect. For example, to map a part of a sphere with the size of d degrees will have an unitarity of 1-cos(d). Therefore, for astrometrical purposes, a reasonable value of the critical unitarity in "auto" triangulation mode can be estimated as 2 or 3 times 1-cos(d/2) where d is the size of the field in which astrometry should be performed.
| |
| | | | |
| − | === === | + | : |
| | + | :: grtrans '''--input''' img.proj '''--col-xy''' 5,6 '''--input-transformation''' img.trans '''--col-out''' 7,8 '''--output''' '''-''' | grtrans '''--input''' '''-''' '''--col-ref''' 2,3 '''--col-fit''' 7,8 '''--wcs''' tan,order=4,ra=220,dec=25 >img.wcs |