I'd like to raise this issue again. The impression I had from last time (https://pixinsight.com/forum/index....ment-didnt-align-but-said-it-succeeded.17155/) is that this is a feature, but a recent event with WBPP makes me want to raise it again.
The issue is this: If you ask Star Alignment to correct for local distortion, and for some reason it is unable to do so, it still does an alignment without distortion correction, and reports it as a success.
When running manually, while very awkward, this is shown in the console window and you can notice it (nicely it is red). You can see it below, and also since it was the last file, you can see the overall success indication. (That window is regular star alignment not WBPP.)
So while it is hard to tell in a very long alignment if you only get a few of these, it is at least possible.
Now WBPP -- if you enable it there, while the error does appear in the log file, having the alignment succeed buries the bad impact of the failure much deeper. One needs to search the log carefully to find this pretty specific issue.
I'd like to suggest that, when one asks for local distortion to be used, if it cannot be used the alignment should fail and no output file be produced.
To me if you want distortion corrected and it does not, it is a failure. Sure, one can argue that we asked PI to do something it cannot do, but that's also true if any other aspects of alignment failure -- but then it DOES fail. Providing a mis-aligned file into the integration is worse than omitting the sub (in my case almost all failed, and the integrated stack was a royal mess.)
I think the growing popularity of WBPP, and how this gets buried even more deeply, makes it even more important that failures get called to the users' attention. Sure, it is arguable it is my fault for not searching the log for this particular message, but ... well, a key value of WBPP is going to be if it can simultaneously automate what were a lot of manual processes, while still retaining the end your users' supervision of those processes.
The issue is this: If you ask Star Alignment to correct for local distortion, and for some reason it is unable to do so, it still does an alignment without distortion correction, and reports it as a success.
When running manually, while very awkward, this is shown in the console window and you can notice it (nicely it is red). You can see it below, and also since it was the last file, you can see the overall success indication. (That window is regular star alignment not WBPP.)
So while it is hard to tell in a very long alignment if you only get a few of these, it is at least possible.
Now WBPP -- if you enable it there, while the error does appear in the log file, having the alignment succeed buries the bad impact of the failure much deeper. One needs to search the log carefully to find this pretty specific issue.
I'd like to suggest that, when one asks for local distortion to be used, if it cannot be used the alignment should fail and no output file be produced.
To me if you want distortion corrected and it does not, it is a failure. Sure, one can argue that we asked PI to do something it cannot do, but that's also true if any other aspects of alignment failure -- but then it DOES fail. Providing a mis-aligned file into the integration is worse than omitting the sub (in my case almost all failed, and the integrated stack was a royal mess.)
I think the growing popularity of WBPP, and how this gets buried even more deeply, makes it even more important that failures get called to the users' attention. Sure, it is arguable it is my fault for not searching the log for this particular message, but ... well, a key value of WBPP is going to be if it can simultaneously automate what were a lot of manual processes, while still retaining the end your users' supervision of those processes.
