AlignByCoordinates

[gvanhau]

This sounds very promising, I have a wide field mosaic waiting to be processed.

Does the script handles tiles at different scales o is it necesary to rescale them first?

Geert

[Andres.Pozo]

This script can work with images of different scales.
For example, I have made a mosaic with one of my images (http://www.astrobin.com/46392/) taken with a resolution of 1.1" and an excellent image from "fulgor" taken with a resolution of 5.5".
The result is this (click on the image to see it at full resolution):


In any case you should read the instructions of the script and keep in mind the limitations enumerated there.

[Andres.Pozo]

This is an animation of the "before/after" the merging of the mosaics.

[gvanhau]

Hello Andres

Last night I gave it a try to build a mosaic.
The script performed very well in order to place the tiles. Better and much faster than the star align method, but the result was not very good in therms of distortion: when I applied GradientMergeMosaic to the resulting frames, there were areas where stars didn't match, my impression is that this is worse where the overlapping areas are big.
May be my case is special, because not al frames are ortogonal....
This evening I will do a second try.

note: when I build the mosaic using star align i get simmilar distortion issues, and until now the only way I found to build the mosaic is using manual align using a lot of alignment stars which is a very time consuming task.

Geert

[Andres.Pozo]

Hi Geert,

If AlignByCoordinates (ABC) has no bugs, it should be able to align without errors all the images that have a perfect coordinates solution. I am reasonably sure of the correctness of ABC,  so the problem is probably in the solution of the images that you are aligning. Achieving a good enough solution for ABC is much harder than for the AnnotationScript because it has to have a subpixel error for all the pixels of the image. This is specially hard in the borders and corners but there is also where the precision is more critical since is where the images overlaps.

If you solve the images using ImageSolver or ManualImageSolver please check the option "Generate residuals image". In this image most of the stars should have zero residuals (the red line showing the error degenerated to a red point). The red lines are exaggerated 10 times, so a line 10 pixels long corresponds to an error of one pixel. If the line is only 1 pixel long, the error should be less that 0.1 pixels.

Also, if the images are taken with a short focal length (<200mm) you should use a degree >1 for the polynomials. I usually have good results with polynomials of 4 or 5 degree.

If you sent me the images I could assist you. However, I am going to take a short holidays, so I won't be able to do it until the middle of the next week.

[gvanhau]

Thanks Andres.
I think you gave a couple of hints:
I took some of the images involved with a 500 mm FL, but with a 5DMKII they may be considered as wide field
I resolved images using ImageSolver but just entered fl, pixel size and coords. No other adjust.

I will try again this evenening, generate residuals images and see what comes out.

Enjoy your holidays
Regards
Geert

[gvanhau]

Hello
I did some test using higher degree polynomials.

First I tried 3 degree, and the result was better but sill vast areas with distortion.
Then I used 5 degree. The result was much better, only a few small areas still showed some distortion.
After that,  I used 9th degree polynomials to see if I could improve the result.  the process took several hours to finish the computations (I left it working during the night) and this morning I launched the GradientMergeMosaic to see the final result.
I got a very weird image with some strange islands on the image.
Looking at the images generated by the script I saw the islands there too (see attached examples).

Edit: The Islands are some kind of proyection of the image on a otrogonal plane.

regards
Geert

[rleisenz]

This script is great. One of the things i missed in PI. But as far i understand, the images have to be already platesolved.
When staying inside the family with Imagesolver, the process seems to be a little bit annoying.
You have to solve one file after the other by hand. Is there some kind of batchroutine do to that?

Thanx
Robert

[Andres.Pozo]

This script is great. One of the things i missed in PI. But as far i understand, the images have to be already platesolved.
When staying inside the family with Imagesolver, the process seems to be a little bit annoying.
You have to solve one file after the other by hand. Is there some kind of batchroutine do to that?

It would not be very difficult to implement the capability of solving the images that are not solved yet. The script AperturePhotometry can already do this.
I don't know when I will find time to do it but it is definitely something that I should do.

[rleisenz]

Tried the script today with no result. The script bugs out with an error message:
A file extension is required to identify an output file format:
followed by the path to the output directory/filename_


Any idea whats going wrong here?


Robert

[Andres.Pozo]

Tried the script today with no result. The script bugs out with an error message:
A file extension is required to identify an output file format:
followed by the path to the output directory/filename_


Any idea whats going wrong here?


Robert

Could you post the contents of the console?

[FunTomas]

Andres, registered images does not contains DATE-OBS keyword. Could you check this please? Thank you.

[Andres.Pozo]

Andres, registered images does not contains DATE-OBS keyword. Could you check this please? Thank you.

I'll do it, but I need a few days.

[Andres.Pozo]

I have just created a pullrequest with the fix of this problem.

[Juan Conejero]

Hi Andrés,

Thank you so much for your excellent work. I have just released an update with these changes. It is now available for version 1.8.4.1195 of PixInsight on all supported platforms.