I have been having issues with Pixinsight WBPP failing to measure a significant number of sub-exposures during the Measurements step with the reason as “Unknown exception.
I have posted this issue to the PI forum and this time been told to use FBPP because of the number of subs I am integrating, which is a lame response. There are advantages to WBPP in cases where data is inconsistent. In my case seeing is highly variable in my data and I’d like to be able to weight subs with lower FWHM by using PSF Signal Weight. So nuts to the PI forum, maybe someone here has a better answer?
I am running an iMac, here are the specs on that:
3.8 GHz, 8 core Intel i9, 32 GB 2667 MHz DDR4 Memory, Sequoia 15.7 (recently updated, but problem occurred before and after).
I process my OSC data as separate R/G/B, and then use 1x drizzle.
To be precise, the “Unknown exception” errors are happening when PI is Measuring R, G or B separated subs after Debayering per its process for separate channels.
I have tried using the Mac’s main SSD hard drive thinking that the errors may be resulting from failures to read from a USB3 HDD drive. Doing so still resulted in “Unknown exceptions”.
In a set of 741 subs, this time, 741 reds were measured no problems, but only 719 blues and 689 greens. Previously a larger number of reds (than blue or green) experienced the error, so that would support that there isn’t an issue with a particular channel or channels.
At first a well-informed person who I had shared my issue with had suggested reducing the number of cores available to PI to 7 from 8, which I did. I think I may have done this a few years ago when I first started using PI per the same person’s advice. The next image I processed only lost one frame, (and I think to “Rejected” rather than an unknown exception, maybe a corrupted file?), so I thought that that had resolved the issue.
I randomly selected 2 blue and 2 green subs from the Debayered folder that had experienced the error, (based upon a review of the Log file), and ran those through SubframeSelector with no issue.
The only thing that I can assume that could be “on my end” at this point would be that my computer is insufficiently fast enough or suffering from some sort of failure. Otherwise I cannot figure out anything that I could do differently. My data seems to be fine, as is reflected in the ability to manually get a result from SFS. My suspicion is that PI is failing to read the files completely, or something to that effect, and that results in an “Unknown exception”. Not being a programmer, and only somewhat familiar with hardware/software issues like this, I am left to speculate in a bit of a vacuum.
Is there anyone here smarter than me that can offer a solution or something else that I could check?
WBPP experiencing "Unknown exception" errors during "Measurements"
I’ve never heard of anyone having this issue.
The only thing I think might be worth testing is stacking the data without splitting it into separate R, G, and B sets, since it kinda sounds to me like Pix might struggle with such a large number of frames. Afaik there shouldn’t be any significant difference between splitting vs not splitting the debayered subs, since you can freely extract & combine the final results anyway.
I have the same issue. I’m running a MacBook Pro with an intel chip. Seems to be a Mac only problem.
I will also report this issue to the PI team. But I think more Mac users have to report the issue.
Is it feasible to have WBPP simply calibrate the frames, then do them in batches of say 250 frames per batch ?
You could then manually star align / integrate, or maybe re-run WBPP but point it to the calibrated frames and disable calibration? (I have not tried this)
It’s frustrating that PI team seems unenthusiastic on WBPP issues
Other option is SetiAstro https://www.setiastro.com/ I think it has stacking - maybe try that ?
Or maybe the free trial of APP to see if it wil stack it.
Chri-Fi · Sep 29, 2025, 06:17 AM
I have the same issue. I’m running a MacBook Pro with an intel chip. Seems to be a Mac only problem.
I will also report this issue to the PI team. But I think more Mac users have to report the issue.
It is good to hear that I am not alone on this!
The troubleshooting I have done points to an issue with PI, perhaps in its application on Intel Macs, but I can’t prove it.
A few more voices over at the PI forum might help get the developers to take the issue more seriously.
Thanks!
Nick Ambrose · Sep 29, 2025, 04:39 PM
Is it feasible to have WBPP simply calibrate the frames, then do them in batches of say 250 frames per batch ?
…
It’s frustrating that PI team seems unenthusiastic on WBPP issues
Other option is SetiAstro https://www.setiastro.com/ …
I could do the whole process manually, but the point of WBPP is to be able to press play and come back to a final integration, which it doesn’t seem to be able to do.
It is truly frustrating how dismissive the PI developers can be. There was another instance, (I forget the exact issue), where my post/concern was ignored or dismissed and then actually addressed at a later time with a new revision. Nobody is perfect, maybe especially software developers.
That noted, and in response to your other recommendation, PI is truly the best available option for AP processing, and I am not really interested in switching platforms. This contributes to the frustration even more, however.
Thanks for your response!
Mikołaj Wadowski · Sep 29, 2025, 12:33 AM
…
The only thing I think might be worth testing is stacking the data without splitting it into separate R, G, and B sets, since it kinda sounds to me like Pix might struggle with such a large number of frames. Afaik there shouldn’t be any significant difference between splitting vs not splitting the debayered subs, since you can freely extract & combine the final results anyway.
There are potential benefits to separating channels for Star Alignment that can lead to reduced chromatic aberrations. Given my imaging equipment, this may be irrelevant or insignificant, however, (Newtonian with CC)
Also, I have been using 1x drizzle integration per PI developer recommendations for OSC data to address Debayering “interpolation error”, (which I barely understand). Doing this may render the separated channel integration pointless, but I don’t know for sure.
Regardless, the software should be able to deal with all of this, but it experiences repeated failures, (apparently per Chri-Fi’s input here and my experience), on Mac’s running Intel chips.
I’d like to continue to use my potentially-pointless pre-processing routine since it should work regardless of its usefulness.
FWIW, it has rarely had any issues with the Local Normalization and Integration of everything after the Measurement step, it’s just a bit slow.