Reproducible PI crash in StarAlignment

D

dclark

Member
Hi PI Team
I have a reproducible crash in PixInsight. I've spent the last day trying to distill the problem into a small set of conditions.
It occurs in StarAlignment.

I have put the relevant files in a zip file at

bugreport.zip

drive.google.com drive.google.com

Here are the steps to reproduce.
1) Use Windows 64 bit, 32Gb ram
2) Start new PI instance, latest version.
3) Open the attached file 'referencemosaic_16_cropped.xisf'.
4) Create a new preview (menu Preview/New Preview option) of dimensions
left = 10899
top = 5241
width = 4670
height = 4075
5) Open process StarAlignment. Configure it with the reference view referencemosaic_16_cropped.
Set it to use registration model 'Thin plate splines'. turn on 'Distortion Correction' and 'Frame Adaptation'
Under 'Interpolation' section, set the 'Pixel Interpolation' to 'Lanczos 3'
6) Open file light-FILTER_L-BINNING_1.xisf
7) Drag the triangle 'New Instance' icon from StarAlignment onto the light-FILTER_L-BINNING_1 file to run it.
For me, this runs for a while, and then crashes reliably. The last console message printed is:
Building recursive surface subsplines: 87%
and the exception is
Exception thrown at 0x00007FFEE61EA035 (ntdll.dll) in PixInsight.exe: 0xC0000005: Access violation writing location 0x0000007F36200FF0. occurred

(and possibly also
Exception thrown at 0x00007FFEE3F8A799 in PixInsight.exe: Microsoft C++ exception: [rethrow] at memory location 0x0000000000000000.
Exception thrown at 0x00007FFEE61EA035 (ntdll.dll) in PixInsight.exe: 0xC0000005: Access violation writing location 0x0000007F36200FF0.
)

It would be great if this could be fixed, since it is blocking my lovely star image progress !! :)
Thanks
David
 
Oh, and just an update: The crash only seems to occur if the "Local Distortion" checkbox is ticked.
Cheers
Dave
 
This is a known problem with recursive subsplines; see for example:

Reproduceable crash in star alignment on mac and linux

Hi, Using star alignment to create a mosaic (register/union - separate) causes PI to crash on both linux (fedora, kde plasma) and Mac. Same images cause the issue on both platforms, two panels of the mosaic complete, two cause the crash. Using a rough mosaic to do the alignement which is quite...
pixinsight.com

I have identified and analyzed this bug, and will work to get it fixed as soon as possible (maybe in the next version). It happens in rare cases where the algorithm enters an infinite recursion loop.

Fortunately, this problem is very unlikely to happen. The only known workaround is to disable local distortion, as you have discovered. This prevents the use of recursive subsplines.

Sorry for the inconvenience, and thank you for the data. I already have downloaded it, in case you want to free space on your Google Drive.
 
Thanks Juan.
Great to know that you will be able to fix this problem.
I am absolutely loving using PixInsight. I'm programming up a heap of scripts, automating my workflow etc.
Apart from this one problem, PI is incredibly stable and reliable.
Cheers
Dave
 
Hi Juan.
I understand that the StarAlignment process uses some 'randomness' during part of the processing (RANSAC?). This non-deterministic behavior is rather frustrating. Sometimes the alignment will succeed, and sometimes it will not. This is a particular problem for those of us who script a bunch of operations to run sequentially (say, overnight). Sometimes the StarAlignment will fail and stop all the subsequent processing, leading to a loss of productivity. This is affecting me quite a lot.
Although the ideal would be for the StarAlignment process to simply succeed 'more often', I understand that this is a difficult task. Instead, would it be possible for you to stop the 'randomnesss' element of the processing - perhaps by seeding the random number generator to a known value prior to use, or using a deterministic ordering within the algorithm? (eg if it is about choosing matching triangles, then order them by, say, 'largest angle closest to a whole number of degrees' or some other pseudo-random method).
By removing the randomness, then at least we will know that if the StarAlignment procedure works once (with a given set of data), it will work next time. This isn't the case currently.
Thanks for listening to my half-brained ideas. Dave
 
Hi Dave,

StarAlignment (SA) is a very robust and accurate image registration process. As implemented in SA, RANSAC does not introduce any non-deterministic behavior able to cause the process to fail under normal working conditions. Just at the contrary, RANSAC is one of the key elements that make SA so robust. I strongly recommend you to read about the RANSAC algorithm and its multiple variants (for example, the Wikipedia entry is a good general description) to understand how it works as both an outlier detector and a maximum likelihood estimator.

When SA fails to register images, it is typically because the data are poor and/or the selected parameters are either incorrect or not well tailored to the properties of the data. For example, if you enable distortion correction, the process will try to compute PSF models by default. This requires reasonably good star profiles, which in turn requires good focus and tracking. If the data you are processing cannot guarantee both conditions, then you'll have to disable PSF estimates (by setting SA's fitPSF parameter equal to StarAlignment.prototype.FitPSF_Never) to increase the probability of success at the cost of some accuracy loss. In other cases the images are so noisy and weak that SA cannot find enough stars. When this happens, the noiseReductionFilterRadius parameter must be increased. Just to mention a third typical cause of problems, SA can fail to register uncalibrated or wrongly calibrated images because of an excessive amount of hot pixels. A script using the SA process should include a robust error detection and recovery mechanism to be able to work without interruption in case image registration fails for particular targets. This is relatively easy to implement using exception handling in JavaScript.

Many important tasks in PixInsight depend on SA. For example, you can study the WBPP and ImageSolver scripts to see two examples implemented in mission-critical components.
 
Hi Juan
Thanks for the explanation. That helps me understand the process a bit better and should enable me to write better code :)
I am 90% sure that I have star alignment processes which sometimes succeed, and sometimes do not. (on the same computer with the exact same input data). If this is not what you expect, then would it make sense for me to isolate the required input data in a reproducible form, and send it to you for analysis?
 
I am 90% sure that I have star alignment processes which sometimes succeed, and sometimes do not.
Click to expand...

This can happen when the data is at the limit of tractability, and is normal behavior in such cases. If you can upload some of these images where you are observing this, I'll be glad to take a look to diagnose the problem.
 
Thanks Juan
I have just re-run my script that builds up a mosaic from 16 images. It has been failing randomly, and it did so again just now.
I then wrote a script that specifically ran StarAlignment multiple times, and sometimes it worked, and sometimes not.
I also just tested by using the same images through the normal PI GUI, and it worked the first five times and failed the sixth time.
(the error text from the console in this GUI case is included in the zip file)
Note that the images that I am using are pretty 'clean' and have well formed stars etc. When my mosaic fits together, the joins are nearly seamless.
I have previously tested using Previews (to limit the areas that the star matching works on), but this didn't make the process any more reliable for me.
Included is a sample of the script that I used to test. (no doubt you can interpret my intention and write the script better)
I've zipped all the required files at

bugreport2.zip

drive.google.com drive.google.com
Thanks a lot
Dave
 
(oh, and to be clear, the two images (referencemosaic and newimage) in the above zip file were the ones that I just tried repeatedly through the GUI, with mostly success but sometimes failure)
 
Bug confirmed. Thank you for reporting it and for the images.

The bug has nothing to do with RANSAC or with the way star pair matches are computed, although the fact that the set of star pair matches differs slightly between executions as a result of random selections has an influence in this case, causing it to fail sometimes and succeed others.

The bug is an error in the way distortion correction is applied in successive iterations. For some reason that I have to investigate, at some point an iteration that tries to gather more stars in the distortion model fails, which in turn may cause failure of the entire image registration process. See for example this sequence of distortion correction iterations:

Matching stars: done
579 putative star pair matches.
Performing RANSAC: done
175 star pair matches in 16 RANSAC iterations. Residual: 6640.8434 px
Computing global distortion correction: done
Performing RANSAC: done
Global distortion correction applied with 629 stars.
* Distortion correction: Iteration 2 of 20
Matching stars: done
561 putative star pair matches.
Performing RANSAC: done
173 star pair matches in 6 RANSAC iterations. Residual: 3.7044 px
Computing global distortion correction: done
Performing RANSAC: done
Global distortion correction applied with 645 stars.
* Distortion correction: Iteration 3 of 20
Matching stars: done
556 putative star pair matches.
Performing RANSAC: done
* Previous attempt failed - this is try #3

As you see, the process was working fine and converging toward a valid solution by reducing the residual (green lines). Then it fails for some weird reason, which should never happen. I cannot reproduce this problem with other images, but it is perfectly repeatable with the ones you have uploaded.

I'll try to fix this bug as soon as possible, sorry for the inconvenience.

On a side note, we are working on a new tool for mosaic construction based on astrometry, which is the only valid way to generate big mosaics like this one (SA is not really designed to build mosaics like the one you have uploaded). Unfortunately, development of this new tool has been delayed because of other priorities, but I hope to release a first version in two months or so. The new tool will allow you to generate huge mosaics with unprecedented accuracy and speed, leveraging the quality of our astrometric solutions. Right now you can also use the MosaicByCoordinates script, which is also based on astrometric solutions, although it can be slow.
 
Hi,

I found a workaround.
I have two tile mosaic, total 6 images (RGB), p1r,p1g,p1b,p2r,p2g,p2b. I generated two reference images r1 and r2 from a star catalog with more and less sparse star field. Reference r1 worked for 5 of 6: all except p2g, reference r2 worked for 5 of 6 but at this time alignment failed for p1r. I checked tiles in Blink and final RGB image visually and didn't find any misalignment.

--
Nik
 
Hi Juan. Is this issue now fixed in the latest release of PI? From the release notes, it sounds like it might be. However when I run a tricky star alignment process (on a mosaic frame), I am still getting inconsistent results and some failures. Thanks Dave
 
Hi Dave,

No, this issue has not been fixed yet. Since this is a corner case and the bug is quite complex, I decided to leave it unfixed for now in version 1.8.8-6. I hope to have it fixed soon, and then I'll release an update. Sorry for the inconvenience.

The other bug in calculation of recursive subsplines is now fixed in version 1.8.8-6.
 
You must log in or register to reply here.
Back
Top