Error detection and reporting enhanced in various places

Linwood

Well-known member
I have had a run of bad luck lately, and it is exacerbated by the reporting that comes out of process or script logs and reporting. I'd like to suggest that it deserves improvement.

Two recent examples:

WBPP had an issue with long file names (addressed elsewhere). During its run, it failed to create output files; these failures were duly logged in the log file, the program continued. At the end, what's readily visible all looked good. In fact what happened is I lost about 20% of the output cosmetically corrected subs. I actually did not notice until I was moving these into a different folder structure. If it had been fewer lost I would not have noticed at all. Yes -- all the errors were in the log, but it's a very long log and you have to search.​
Star alignment, run with thin plate and local distortion can fail to create a distortion model, and when it does, the actual alignment is rubbish. The error is reported as an "ERROR" in the process log screen in red, but the error does not trigger the on-error action from the process. If (as I was) you are aligning hundreds of files the log will not even still contain the error unless you chose to write it to a file, and go back and review in detail.​

It would be unfair to say there is no error messages given, but I think it is very fair to say they are obscured by volume and by the lack of any kind of "abort on error" setting that works (in one case there is none, in another it fails to catch).

Star Alignment has a related issue that, if it fails completely (which will catch on the error), even if you save the log due to parallelism it can be really tough to find the actual sub name that fails. So if you get "899 succeeded, 1 failure" type message and want to know which one so you can look at it... well, good luck with that.

I'd like to suggest that Pixinsight needs a better recap at the end of processes and scripts, that boldly lets the user know if there were issues during the run that caused a failure of output or function. Where practical (and many files are involved) list the actual files that caused the issue in a recap (Star Alignment being a great example).

Yes... again, I realize in all the examples I've shown, there is an indication in the log that the user could find -- but to do so you have to log to a file continuously, and search for key words like ERROR or WARNING manually after each thing you do. Maybe some do that. But it's darn inconvenient, and all too easy now to lose subs along a long workflow (or maybe worse, include subs that you should not, like mis-aligned frames that were output anyway).

I realize this is not "a" wish, but I also think that making this a goal you can identify some low hanging fruit (I suggest two above) for ongoing cleanup. Especially WBPP which is under active development.
 
Back
Top