MosaicByCoordinates

[Andres.Pozo]

This is the announcement of a beta version of a new script: "MosaicByCoordinates"

MosaicByCoordinates aligns the tiles of a mosaic using their coordinates. The tiles must be plate solved for this to be possible. MosaicByCoordinates works with different geometric projections and it has the capability of converting the original projection of the tiles to another projection.

The advantages of this aproach are:

• It can create mosaics where the images don't overlap.
• It can create mosaics of very wide field, even all-sky mosaics. For example, it can create a mosaic with Hammer-Aitoff projection from images in Gnomonic projection taken with a common camera.
• All the transformations are done considering the geometric properties of the image so the resulting mosaic has a valid geometry and can be used in other operations (like AnnotateImage).

This is an example with three synthetic images that simulate the field of a Canon 400D with a 17mm lens. The mosaic covers a span of nearly 180º and it uses the Stereographic projection.


This script has required to implement several projections in order to have a enough range of different properties. I have written a document describing them that can be downloaded from https://dl.dropboxusercontent.com/u/71653208/PublicScripts/Projections.pdf. This document will be available from the update system of PixInsight when the beta phase finishes.

I have also needed to modify several other scripts. These are the changes:

• CatalogStarGenerator:
• Possibility of select the projection of the result.
• The stars can be extracted from two catalogs at the same time. This is sometimes necessary because some of the most detailed catalogs doesn't contain the brightest stars.
• ImageSolver:
• Improved the solutions using distortion models. It now works MUCH better.
• Improved the calculation of nonlinear solutions using splines. Now it should be less prone to wild oscillations.
• Added a detailed help file!!
• AlignByCoordinates:
• The previous versions had the capability of creating mosaics. Since this capability has been made obsolete by MosaicByCoordinates, AlignByCoordinates no longer can generate mosaics.

The new beta version of the scripts can be downloaded from this link:
https://dl.dropboxusercontent.com/u/71653208/PublicScripts/AdP.zip

Some of the scripts have integrated documentation that will not be usable from the script until they are released by the update system. Meanwhile I have generated PDFs with the contents:
Documentation of AlignByCoordinates
Documentation of ImageSolver
Documentation of ManualImageSolver
Documentation of MosaicByCoordinates
Documentation of Projections

[georg.viehoever]

Fantastic!
If I may suggest something: currently your scripts appear in different categories in the scripts menue. Maybe they should be bundled into one group (such as Script/WCS).
Georg

[Alejandro Tombolini]

Excellent work Andrés, congrats! I have installed it, now only need some data to make a try.
Thank you!
Saludos, Alejandro

[pfile]

thank you - i will try this on the mosaic i've been working on.

rob

[FunTomas]

Excelent work Andres. I will try to process my 7x7 fields mosaic. I don't know, if your script do that, but is it possible to disable antialiasing when new registered images are generated? It will be better for Georg's script. Thanks.

[Andres.Pozo]

MosaicByCoordinates doesn't apply any explicit antialiasing. However the interpolation at the borders could produce that effect depending on the implementation.

I am using the interpolation algorithms of PixInsight but I check that the coordinates are inside the image. However some interpolation algorithms use a window of size>1 and this would require applying a margin of several pixels for checking if the coordinates are inside the image.

I think that currently the borders of the aligned tiles are "clean" but I don't know if it is enough. Please test it and tell me if there are any problems.

I have attached a stretched and scaled example of the border of an aligned tile.

[chris.bailey]

I just ran it on a four frame Ha mosaic of Orions Sword I am working on. Results are very impressive indeed. Thanks!

[georg.viehoever]

...I have attached a stretched and scaled example of the border of an aligned tile.

Andres,
this kind of  border is OK for GradientMergeMosaic. Pixels that belong to the image are immidiate neighbors of background pixels. GMM only has some problems with images where there are pixels that are "half bright" due to aliasing.
Georg

[pfile]

does the script apply frame adaptation while registering? blinking two frames created by the script shows brightness differences at the overlap point. of course it looks seamless after GMM, so i think it's fine but it got me wondering. of course even with frame adaptation there can be such brightness differences.

i am just wondering if we have to normalize our images beforehand.

rob

[Andres.Pozo]

does the script apply frame adaptation while registering?

No. The script only applies geometric transformations.  It doesn't change the values of the images.

[pfile]

so then what is the right way to normalize the frames? ordinarily when making mosaics you use frame adaptation. obviously LinearFit won't work because the panels are not of the same star field.

do we have to make a dummy run of StarAlignment to find the linear transformation required?

rob

[Andres.Pozo]

You can use LinearFit after aligning the tiles but this only works if there is some overlap between the tiles. If there is not overlap then neither LinearFit nor StarAlignment would work because I think both do the same.

However if there is not overlap, the frame adaptation is not so critical since there are not seams where different backgrounds are very visible. A manual HistogramTransformation should be enough in that case.

[pfile]

okay, i understand - i do have overlap so i'll give LF a try. have to find an automatic way to get the intersection between panels. maybe SA will do that.

rob

[mickut]

Excellent, I was working on a similar script, but now I don't have to anymore. I was heading in the same direction after I made my first mosaic by thin-plates registering against an artificial starfield generated based on a plate-solved rough mosaic. With this I ended with a perfect match across the mosaic for annotating the M31 globulars:



But generating the starfield seemed a useless extra step, if you can get the same results with distortion correction straight out of plate-solved data.

-Antti

[pfile]

i think andres still uses a synthetic star field to compute the distortion all across the frame.

rob