origin of the geomap rotation
Ari Takalo wrote on Jun 29, 2009
Hi
I have different observation times have small rotational differences. I allso want to minimize noise, so i want to combine all images at one time to get best possible median (iam reducing ir data) for combining. so I combine all sets first separately to get large enough area to have enough stars for comparing and use geomap to calculate rotation needed. i must move the origin of rotation for the individual dithered images, because of the dither pattern.
Is the origin for this rotation calculated by geomap the center of the combined input image?
Thank you
Ari Takalo
edit:
colleague pointed out to me, that it should be corner not the center.
I have different observation times have small rotational differences. I allso want to minimize noise, so i want to combine all images at one time to get best possible median (iam reducing ir data) for combining. so I combine all sets first separately to get large enough area to have enough stars for comparing and use geomap to calculate rotation needed. i must move the origin of rotation for the individual dithered images, because of the dither pattern.
Is the origin for this rotation calculated by geomap the center of the combined input image?
Thank you
Ari Takalo
edit:
colleague pointed out to me, that it should be corner not the center.
Francisco Valdes wrote on Jun 29, 2009
The geometrical interpretation of the coefficients that come out of a polynomial fit depends on assumptions and how the task is used. If you use
and assume the rotation point is fixed (that is, does not shift) then the "xshift" and "yshift" values must satisfy an equation like:
where (xo, yo) is the rotation point. This follows from the model of the transformation:
Therefore, you would need to solve the first set of equations given the output of geomap that tells you theta, xshift, and yshift. You might have to flip the signs of the rotation (i.e use 360-theta).
Since the measured positions would be expected to have some noise there will be some error in deducing (xo, yo).
I hope this helps.
Yours,
Frank Valdes
fitgeometry = "rotate"
xterms = "none"
yterms = "none"
and assume the rotation point is fixed (that is, does not shift) then the "xshift" and "yshift" values must satisfy an equation like:
xshift = xo * (1 - cos(theta)) + yo * sin(theta)
yshift = yo * (1 - cos(theta)) - xo * sin(theta)
where (xo, yo) is the rotation point. This follows from the model of the transformation:
xin = xo + (xref-xo) * cos(theta) - (yref-yo) * sin(theta)
yin = yo + (xref-xo) * sin(theta) + (yref-yo) * cos(theta)
Therefore, you would need to solve the first set of equations given the output of geomap that tells you theta, xshift, and yshift. You might have to flip the signs of the rotation (i.e use 360-theta).
Since the measured positions would be expected to have some noise there will be some error in deducing (xo, yo).
I hope this helps.
Yours,
Frank Valdes
Ari Takalo wrote on Jun 29, 2009
Thank you for the info, seems like i must do some more coding. ;) I was doing another reduction project for couple weeks, hence slow answer. Rotation point should be fixed, because I handle every combined image separately and so for one set rotation is fixed. Basicly im just trying to do the rotation to every part of the mosaic image separately to get as much images to the final combining as possible.
How does the geotran determinate the origin? does it solve the equations or has it some other method to get the rotation right?
Is there some other task that could calculate the needed rotations with some fixed origin(corner, center etc.)?
Allso i noticed that rotate and so geotran does not like negative rotation origins. It can handle positive origins, which are out of the image, but negative numbers cause out of range error. Is there task that can do this because the origin might be out of some individual part of the mosaic and possibly on the negative side. If this cannot be done, I probably must just combine the mosaic images. this of course would lower the quality, but thats better than no picture at all. :)
Thank you again.
Ari Takalo
How does the geotran determinate the origin? does it solve the equations or has it some other method to get the rotation right?
Is there some other task that could calculate the needed rotations with some fixed origin(corner, center etc.)?
Allso i noticed that rotate and so geotran does not like negative rotation origins. It can handle positive origins, which are out of the image, but negative numbers cause out of range error. Is there task that can do this because the origin might be out of some individual part of the mosaic and possibly on the negative side. If this cannot be done, I probably must just combine the mosaic images. this of course would lower the quality, but thats better than no picture at all. :)
Thank you again.
Ari Takalo
Francisco Valdes wrote on Jun 29, 2009
Hi,
GEOTRAN does not explicitly compute a rotation at all. It computes coefficients to a polynomial function. As described in the help the polynomial coefficients can be "interpreted" as a rotation for some forms of the polynomial. But since it is not really fitting an equation with a rotation there is no specific rotation origin and, it follows, that it is not possible to constrain the origin even if you know what it is.
As for the constraint to positive angles, this must be limited by the parameter file and the limit can be changed by the user. However, even easier is simply to use angles greater than 180 degrees which is equivalent to negative angles less than 180 degrees. For instances an rotation of -10 degrees is the same as a rotation of 350 degrees.
Frank Valdes
GEOTRAN does not explicitly compute a rotation at all. It computes coefficients to a polynomial function. As described in the help the polynomial coefficients can be "interpreted" as a rotation for some forms of the polynomial. But since it is not really fitting an equation with a rotation there is no specific rotation origin and, it follows, that it is not possible to constrain the origin even if you know what it is.
As for the constraint to positive angles, this must be limited by the parameter file and the limit can be changed by the user. However, even easier is simply to use angles greater than 180 degrees which is equivalent to negative angles less than 180 degrees. For instances an rotation of -10 degrees is the same as a rotation of 350 degrees.
Frank Valdes
Ari Takalo wrote on Jun 29, 2009
valdes
Hi,
GEOTRAN does not explicitly compute a rotation at all. It computes coefficients to a polynomial function. As described in the help the polynomial coefficients can be "interpreted" as a rotation for some forms of the polynomial. But since it is not really fitting an equation with a rotation there is no specific rotation origin and, it follows, that it is not possible to constrain the origin even if you know what it is.
Oh yeah forgot that
As for the constraint to positive angles, this must be limited by the parameter file and the limit can be changed by the user. However, even easier is simply to use angles greater than 180 degrees which is equivalent to negative angles less than 180 degrees. For instances an rotation of -10 degrees is the same as a rotation of 350 degrees.
Frank Valdes
It's not about the degrees, but the origin/center of the rotation. specifically xin and yin parameters in rotate task. it defaults to center of image, but if i try to input rotation center like xin= -1 task gives:
ERROR: Parameter value is out of range; try again
on the other hand if i give it number like 5000, which is way outside the 1024X1024 image it does not complain and performs the rotation. rotate apparently can handle out of the image rotation centers, but seem to have problem with negative numbers.Is this just some decided limit or is there some problem with handling negative origins.
geotran acts similarly with parameter transformation. haven't tested with database file.
Just noticed that the optional result file geomap produces has term "Mean Xin and Yin: <number> <number>" are these the rotation centers or are they some other parameters. Geomap gives shift amounts and rotation degrees it would seem odd if it didn't give the rotation centers coordinates. Without information about the rotation center the rotation numbers are useless.
oh and thank you for quick answer
EDIT: found a solution to divert this problem, i stamp the part images to right positions in empty templates made out of the mosaic image. then i just do the given geo tran given by geomap for the mosaic. simplifies things lot.
Ari Takalo wrote on Jun 29, 2009
thought to make new post because this is related, but different guestion. This might be too easy and i haven't noticed. How do i get physdim out of image header, because it is not a normal parameter imgets does not find it? It allso is not in imgets standard image headers list. I need the exact physical size of the image for putting those partimages to templates.
EDIT: figured it out, maybe there is easier way but this is my solution
EDIT: figured it out, maybe there is easier way but this is my solution
string imtype,eka,toka
int ol,oj,oh,sizex,sizey
imhead(fname)|scan(imtype)
ol=strstr(',',imtype)
eka=substr(imtype,1,ol-1)
toka=substr(imtype,ol+1,strlen(imtype))
oj=strstr('[',eka)
oh=strstr(']',toka)
eka=substr(eka,oj+1,strlen(eka))
toka=substr(toka,1,oh-1)
x=int(eka)
y=int(toka)
=x
=yFrancisco Valdes wrote on Jun 29, 2009
Hi,
PHYSDIM is not expected to be a useful parameter to users and, as you say, is a special parameter not accessible by the usual means. Maybe what you want to access is NAXIS1 and NAXIS2 which you can get with HSELECT or IMGETS.
What you did to parse the output of IMHEAD is reasonable.
Regards,
Frank Valdes
PHYSDIM is not expected to be a useful parameter to users and, as you say, is a special parameter not accessible by the usual means. Maybe what you want to access is NAXIS1 and NAXIS2 which you can get with HSELECT or IMGETS.
What you did to parse the output of IMHEAD is reasonable.
Regards,
Frank Valdes
Last post on Jun 29, 2009