Open leliel12 opened 5 years ago
I'm having this problem too.Max iterations exceeded while trying to find acceptable transformation.
We're trying to use astroalign
in our project (MYRaf Project).
the piece of code we're trying to use is:
Note: Within the same class we can read, write, and get headers from fits files.
def align(self, image, ref, output, overwrite=True):
"""Aligning an image with respect of given referance"""
self.logger.info("Aligning image({}) with reference({})".format(image, ref))
try:
#Read data from image
image_data = self.data(image)
#Get header (? means all header object) from hdu
image_header = self.header(image, field="?")
#Get data from ref image
ref_data = self.data(ref)
#Align the image with reference image using astroalign
img_aligned, _ = aa.register(image_data, ref_data)
#Write the aligned image to disk
self.write(output, img_aligned, header=image_header, overwrite=overwrite)
except Exception as e:
self.logger.error(e)
Any work around this problem. I visiually checked the images and they're alignable.
Note: aa._find_sources
returns more than 1000 sources for the same fits data. (We're using it as automatic source-detector)
Hi @mshemuni,
aa._find_sources returns more than 1000 sources
This could actually be the issue. It could be that aa._find_sources
is catching hot pixels as sources or some other kind of fake sources.
Would you mind sending me a couple of problem images to take a look at them?
BTW note that aa._find_sources is an internal method and it's a very simple source detection, I would recommend using a more robust source detection algorithm to use in production.
This could actually be the issue. It could be that
aa._find_sources
is catching hot pixels as sources or some other kind of fake sources.
Actually we use aa.register,
which is using find_transform
which is using aa._find_sources
.
Additionaly I tried to clean the fits files using ccdproc.cosmicray_lacosmic
with no success.
Please keep in mind some mosaic CCDs would provide data with hot column/row And I think this is the case.
Hi @mshemuni,
Sorry it took me so long to reply, I haven't thoroughly tested your images yet, but I suspect the moire pattern in them may be creating fake sources. But I still have to check if that's really the problem. In any case, it's indication that the source extraction could be made better for astroalign.
I'm seeing this problem too. Astroalign worked remarkably well when I was using it on crappy .cr2 images from an old Rebel, but now I have a Sony Alpha with a much more sensitive sensor, and when I try astroalign it always fails with MaxIterError. I'll attach a couple of sample images. _find_sources() on the two arrays I'm trying to align returns shapes (3860, 2) and (3990, 2) if I use raw .arw, or (10719, 2) and (11023, 2) for JPG. Github won't let me attach the raw files so here are two JPGs (not great astro images, just something I'm using to test aligning).
Thanks @akkana, I'll look into it. I'm curious, do you use a single channel to try to align or do you somehow combine the 3 RGB channels when sending to align?
(BTW I'm opening a new issue for this specific problem)
Implement property-based testing on astroalign to detect corner cases
For example, anything with stars
<= 98
fails