PixInsight Forum (historical)
Software Development => New Scripts and Modules => Topic started by: Andres.Pozo on 2013 June 23 12:04:10
-
The alignment of images is a basic tool for processing of astronomical images. PixInsight has an excellent tool (StarAlignment) for aligning images that works comparing the overlapping areas between the target image and a reference image and trying to find a match between them. Then computes a lineal transformation that converts the geometry of the target image so that it is similar to the reference image.
This usually works very well but it has a few limitations:
- When the images to align have different geometric distortions StarAlignment can not align them because there is not a lineal transformation between them. This usually happens in images taken with short focal lengths.
- When building mosaics, StarAlignment can only match the images when there is a big enough overlapping area. For example, it can not align images from the segmented sensors of professional telescopes.
- When building mosaics, StarAlignment aligns the images by pairs. When a mosaic is formed by many tiles the process is prone to mismatchings caused by accumulating errors.
AlignByCoordinates tries to solve this shortcomings using a different approach to the alignment: Instead of matching an image against other, it requires that the images are plate solved. Knowing the coordinates of each pixel of the image the script can reproject them so the geometries of the images are compatible.
AlignByCoordinates can cope with two kind of geometric distortions:
- Projection distortions: When two images are not centered in the same point they have different projections. The difference in the projections causes that there is not a lineal transformation between them. This effect is stronger in images with short focal length.
The following animation shows an example of this effect. The images have been generated from catalog data and the only geometric distortions are caused by the projection. As can be seen in the animation, the Orion asterism has different distortions in each frame.
(https://dl.dropboxusercontent.com/u/71653208/FotosForum/AlignByCoords_ProjectionDistortion.gif)
- Geometric optical aberrations: The plate solving of astronomical images is usually done supposing that the optical system can be modeled by a Gnomonic projection (http://en.wikipedia.org/wiki/Gnomonic_projection).
However, many lenses or telescopes don't follow strictly this projection. The images from these optical systems can not be solved with high accuracy using only lineal polynomials. ImageSolver and ManualImageSolver can use higher degree polynomials to model the geometric distortions. AlignByCoordinates can use the distortion model generated by the plate solving process for fixing it when aligning images with different distortions.
As a result, AlignByCoordinates can be used for generating wide field mosaics where the tiles have little or no overlapping and when the tiles have strong distortions caused by short focal lenses.
The instructions for using this script are in this PDF: AlignByCoordinates.pdf (https://dl.dropboxusercontent.com/u/71653208/FotosForum/AlignByCoordinates.pdf). The contents of this PDF will be available as the online help of the script when it is distributed with PixInsight.
The following animation is used in the documentation of the script but it doesn't work in the PDF:
(https://dl.dropboxusercontent.com/u/71653208/FotosForum/AlignByCoords_Mosaic.gif)
The following video shows the four corners and the center of 12 images aligned with AlignByCoordinates. The images were taken with 17mm optics and have heavy distortions:
http://www.youtube.com/watch?v=ARiKCITz1lI (http://www.youtube.com/watch?v=ARiKCITz1lI)
UPDATED VERSION 0.2
-
This looks great but when I try to download any program to un-compress the file ESET NOD32 (my antivirus software) goes crazy. Is it possible to post a standard .zip file?
Thanks,
-
There are a lot of "variants" of 7zip that are used to transport viruses. Try the official download at http://www.7-zip.org/ of this excellent tool.
Georg
-
Thanks, that worked great.
-
Now that they are unzipped do I just place them in the PI Scripts folder or a new sub-folder under Scripts?
Thanks again,
-
Now that they are unzipped do I just place them in the PI Scripts folder or a new sub-folder under Scripts?
Thanks again,
You have to unzip all the files in any directory and then register this directory with "SCRIPT / Feature scripts / Add".
-
Got it thanks, I remember now. It's a bear getting old!
-
Hello,
if I want to run the script, this error message comes
Processing script file: C :/ Program Files / PixInsight / src / scripts / AdP / AlignByCoordinates.js
Error ***: C :/ Program Files / PixInsight / src / scripts / AdP / AlignByCoordinates.js, line 54: include file not found: pjsr / SectionBar.jsh
What can it be?
Best regards,
Thomas
-
Hello,
if I want to run the script, this error message comes
Processing script file: C :/ Program Files / PixInsight / src / scripts / AdP / AlignByCoordinates.js
Error ***: C :/ Program Files / PixInsight / src / scripts / AdP / AlignByCoordinates.js, line 54: include file not found: pjsr / SectionBar.jsh
What can it be?
Best regards,
Thomas
This script requires PixInsight v1.8RC7. You probably have a previous version.
-
I read through the reference file and tried aligning images taken last night of the Moon. This is with a 12.5" RC @f/9 and a STL-11000M camera using my Ha filter. Now this didn't work as expected as the images all have the coordinates in the FITS header as copied from MaxIm:
SIMPLE = T / file does conform to FITS standard
BITPIX = 16 / number of bits per data pixel
NAXIS = 2 / number of data axes
NAXIS1 = 4008 / length of data axis 1
NAXIS2 = 2672 / length of data axis 2
EXTEND = T / FITS dataset may contain extensions
COMMENT FITS (Flexible Image Transport System) format is defined in 'Astronomy
COMMENT and Astrophysics', volume 376, page 359; bibcode: 2001A&A...376..359H
BZERO = 32768 / offset data range to that of unsigned short
BSCALE = 1 / default scaling factor
PROGRAM = 'PixInsight 01.08.00.1015 RC7' / Software that created this HDU
COMMENT PixInsight Class Library: PCL 02.00.02.0589
COMMENT FITS module version 01.00.14.0228
COLORSPC = 'Grayscale' / PCL: Color space
RESOLUTN = 72. / PCL: Resolution in pixels per resolution unit
RESOUNIT = 'inch ' / PCL: Resolution unit
DATE-OBS = '2013-06-24T04:15:34' / YYYY-MM-DDThh:mm:ss observation start, UT
EXPTIME = 0.07 / Exposure time in seconds
EXPOSURE = 0.07 / Exposure time in seconds
CCD-TEMP = -19.9771007366559 / CCD temperature at start of exposure in C
XPIXSZ = 9. / Pixel Width in microns (after binning)
YPIXSZ = 9. / Pixel Height in microns (after binning)
XBINNING = 1. / Binning factor in width
YBINNING = 1. / Binning factor in height
XORGSUBF = 0. / Subframe X position in binned pixels
YORGSUBF = 0. / Subframe Y position in binned pixels
READOUTM = 'Normal ' / Readout mode of image
FILTER = 'Ha ' / Filter used when taking image
IMAGETYP = 'Light Frame' / Type of image
OBJECT = 'Moon1 '
OBJCTRA = '18 54 57' / Nominal Right Ascension of center of image
OBJCTDEC = '-19 07 18' / Nominal Declination of center of image
OBJCTALT = '28.0735 ' / Nominal altitude of center of image
OBJCTAZ = '152.0529' / Nominal azimuth of center of image
OBJCTHA = '-1.7301 ' / Nominal hour angle of center of image
PIERSIDE = 'WEST ' / Side of pier telescope is on
SITELAT = '37 48 41' / Latitude of the imaging location
SITELONG = '-78 23 51' / Longitude of the imaging location
JD = 2456467.67747685 / Julian Date at start of exposure
JD-HELIO = 2456467.68324002 / Heliocentric Julian Date at exposure midpoint
AIRMASS = 2.11486317809478 / Relative optical path length through atmosphere
FOCALLEN = 2877. / Focal length of telescope in mm
APTDIA = 317.5 / Aperture diameter of telescope in mm
APTAREA = 79173.0458121747 / Aperture area of telescope in mm^2
EGAIN = 0.829999983310699 / Electronic gain in e-/ADU
SWCREATE = 'MaxIm DL Version 5.24 130927 1V9AM' / Name of software that created
SBSTDVER = 'SBFITSEXT Version 1.0' / Version of SBFITSEXT standard in effect
HISTORY Dark subtraction (Simple Auto-dark)
CALSTAT = 'D '
PEDESTAL = -100. / Correction to add for zero-based ADU
TELESCOP = ' ' / telescope used to acquire this image
INSTRUME = 'SBIG STL-11000 3 CCD Camera w/ AO'
OBSERVER = ' '
NOTES = ' '
FLIPSTAT = ' '
SWOWNER = 'Steven J Reilly' / Licensed owner of software
INPUTFMT = 'FITS ' / Format of file from which image was read
What I have is 10 images taken with moon in about 1/2 the frame height for the top and 10 frames with the lower 1/2 of Moon. Aligned using PI without issue using StarAlignment. When I load them in the script I get an error as seen in the uploaded picture.
Not sure if I'm using this script properly or not. MS-ICE did make a nice mosaic without issue but I'd rather see this work in PI.
Thanks,
-
The images have to be solved using the WCS convention. You can do this in PixInsight using the scripts ImageSolver or ManualImageSolver. There are also other programs (as PinPoint) that can do it.
The WCS convention is described in this page:http://fits.gsfc.nasa.gov/fits_wcs.html (http://fits.gsfc.nasa.gov/fits_wcs.html)
Your image hasn't the keywords CTYPE1, CTYPE2, CRPIX1, CRPIX2, CRVAL1, CRVAL2, CD1_1, CD1_2, CD2_1, CD2_2. The keywords that the image currently has are not enough to fully describe the geometry of the image.
-
I have updated in the first message the version of the script. It had a silly error that prevented starting the script.
-
That clears up the error but It's not writing any output files now.
-Thanks
-
That clears up the error but It's not writing any output files now.
-Thanks
Could you post a copy of the contents of the console? Also one of the images would be very helpful. You can use dropbox or similar to upload it.
Keep in mind that this script is designed for deep sky images. It probably won't work for stitching mosaics of the moon or landscapes.
In any case, the process for creating a mosaic would be this:
- Calibrate, register and integrate the subframes of each tile.
- Crop the tiles in order to remove the areas at the borders that were no covered by all the subframes.
- [Optional] If the tiles have gradients you should remove them using DBE.
- If the tiles are RGB you should do a color calibration.
- Solve the tiles using ImageSolver or ManualImageSolver. The quality of the alignment of the tiles depends on this process.
- Execute AlignByCoordinates using the mode "Create mosaic" and select as reference image the tile closest to the center .
- Merge the aligned tiles using a suitable process. I recommend GradientMergeMosaic.
I will add this to the documentation of the script.
-
I have just finishd an example of aligning and integrating 10 images taken with a 105mm lens and a camera with a big sensor. The images were taken with a dithering of several tens of pixels. Since the images have moderate distortions in the corners the dithering causes misalignment of the stars.
Using ImageSolver for solving the images with 5th degree polynomials and AlignByCoordinates, the result of the integration is better than when it is done using StarAlignment.
This animation compares the right-bottom corners of the result of the integration of the images aligned with StarAlignment and AlignByCoordinates:
(https://dl.dropboxusercontent.com/u/71653208/FotosForum/AlignCompare.gif)
This is the result of the script FWHMEccentricity (by Mike Schuster):
(https://dl.dropboxusercontent.com/u/71653208/FotosForum/AlignCompare.png)
This is the distortion map of one of the images:
(https://dl.dropboxusercontent.com/u/71653208/FotosForum/AlignCompare_distortions.png)
-
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
-
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/ (http://www.astrobin.com/46392/)) taken with a resolution of 1.1" and an excellent image from "fulgor" (http://www.astrobin.com/12039/) taken with a resolution of 5.5".
The result is this (click on the image to see it at full resolution):
(https://dl.dropboxusercontent.com/u/71653208/FotosForum/CrescentMosaic.jpg) (https://dl.dropboxusercontent.com/u/71653208/FotosForum/CrescentMosaic.jpg)
In any case you should read the instructions of the script and keep in mind the limitations enumerated there.
-
This is an animation of the "before/after" the merging of the mosaics.
(https://dl.dropboxusercontent.com/u/71653208/FotosForum/CrescentMosaicCrop.gif)
-
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
-
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.
-
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
-
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
-
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
-
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.
-
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
-
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?
-
Andres, registered images does not contains DATE-OBS keyword. Could you check this please? Thank you.
-
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.
-
I have just created a pullrequest with the fix of this problem.
-
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.