PixInsite Confession

Tony Gondola · Mar 22, 2026, 06:49 PM

So in PI speak, this would be the process lineup?

ImageCalibration

CosmeticCorrection

SubFrameSelector

StarAlignment

LocalNormalization

ImageIntergration

I would agree that WBPP isn’t super fast but it’s light years faster than what I was doing before. I’ve always understood the steps involved but I’ll have to learn a lot more about what’s possible to adjust in each process and why. Not much point if I’m mostly just taking the defaults.

I started using PI after WBPP was pretty well optimized. I find it does everything I need nicely in one shot. My integration workflow is 90% of the time perfectly met by WBPP. I like to be able to kick it off and go do other things for an hour or 2 (if I have a large data set) and not babysit. It’s doing each of those things in the background, so functionally there should be no difference. The frame selector is the only interactive step now, although a most of the time WBPP selects the appropriate weighting of bad frames and it doesn’t make much difference at all.

Basically, if you like to have ultimate control, feel free to go step by step…not a bad way to learn what WBPP is doing behind the scenes. But I’ve used WBPP enough that I can control a process if I need to, but 90% of the time I just let it fly.

Rick

Tony Gondola · Mar 23, 2026, 12:44 AM

Honestly, I’ll always look at the lights on SAS’s blink process as I think it’s pretty much a perfect way to look at you’re frame data and cull as/if needed. In Siril it was absolutely necessary to do this but I’m tending to agree the WPBB does such a good job of eliminating bad frames that culling might be unnecessary for most data sets.

I actually like to use Zwo Studio’s ASIFitsView as a quick go-through even mid session since I can zip through the files in real time and delete the egregious bad one on the spot in the tool.

I haven't had a chance to learn SAS as deeply as I'd like.

I typically will blink in PI and remove obviously bad frames or frames with plane/satellite trails, and then run subframe selector and only cull massive outlier frames based on FWHM or eccentricity. I still stack in Siril because it is so much faster than PI, but perhaps I should WBPP another go. It worked well enough for awhile, but the last time I used WBPP, it didn't recognize the frames after a meridian flip, and just stacked the flipped frames upside down instead of flipping the frames to match the rest 😂

But like you @Tony Gondola, I'm so used to organizing my files for siril processing, that I don't find my process of PI Blink and Subframe Selector, Siril stacking, and back to PI for the remainder of processing, to be all that cumbersome for OSC. Perhaps if I move to mono, I may no longer find this approach worthwhile!

I agree with what was said earlier, I would not use PI just because of WBPP, but it is really handy and I now use it for 90% of my initial processing and integration.

I will however, respectfully disagree with the earlier assertion that it is a “black box.” WBPP is a PI script that organizes specific PI processes in a single interface. Properly set up, you can control everything just as you can by setting up each process individually. What WBPP does is pass the data along from one process to another, applying parameters and criteria you control, with less intervention between steps. I think that some people call WBPP a black box is because they treat it as one. They drop all their data in and hit “go”, but that is not the best way to use it, or any other PI script or process.

————————————————

How I use WBPP within my initial PI workflow (but by no means does everyone have to do it my way! I claim no special brilliance):

I use Blink to look through all the frames, get a feel for them and how things went during the night. I remove any truly bad frames: opaque clouds, streaked stars due to a gust of wind, high background because I tried to collect too close to dawn, a bright airplane going right over the object I want to see, etc. Satellite trails, light clouds, etc. are all fine - I leave them in because while they may have defects, they will not hurt anything and mathematically they improve the S/N. I used to discard a lot of frames, now I hardly discard any.

In addition to blinking, I open a few representative images taken throughout the night (maybe 4-5) and examine them. I’m looking for the approximate background brightness, amount of contrast, obvious gradients, degree of vignetting and distortion/aberration at the edges, how many stars are saturated (hopefully not many!), etc. If I took darks or flats I will also look at a few of those. My goal is just to get a feel for the nature of the data and thus if I need to consider anything special during calibration and integration.

If I spot anything, it can affect how I proceed. I might decide to not jump right into WBPP, but to do just a calibration on a small set of the images to be sure that will go well. If I am going to integrate many nights of data, I want to know if there are differences between them that I need to consider. For example, I have learned that with a certain optical configuration, aberrations around the edges can cause issues with registering data from the two sides of the meridian, and so I will adjust for that.

When I am ready, I t set up WBPP, using what I learned from the inspections to guide the configuration and parameters. As an aside, I always use the interactive mode for creating a local normalization reference image, and don’t do the astrometric solution.

In regard to the new Subframe Selection feature within WBPP, it is pretty cool and my understanding is that it was implemented recently due to a lot of users asking for it. With that said, I think it likely will lead to a lot of people throwing out perfectly good data without a really good reason to. The image analysis features already built in do a really good job of judging the quality of each frame using several features, and objectively assigning a score (PSF Signal Weight, usually). That score takes into account all the other things that you might look at yourself (FWHM, Eccentricity, Stars) in a quantitative way. Then, this score determines whether the frame is included and how it is used (the "weighted” part of WBPP)

I like to look at the new interactive subframe selector just to get a feel for the variability in my data, but to be honest the only time I exclude a frame is when the PSF Signal Weight is so obviously an outlier that there is something really wrong with it, like nearly opaque clouds that I missed during blinking. Likely that would be rejected anyway, without my intervention.

A fun exercise is to run a batch processing with all your data, without even blinking, and let WPBB decide what to include and what not. Then, run it again and manually excluded frames. Then, compare the final masters and see whether one is better than the other.

————————————————

Anyway, the fun thing about this hobby is that we have so many tools, and so many choices, it truly is “choose your own adventure.” What works for you and what you enjoy is what matters!

(One more aside: I have learned a HUGE amount from Adam Block’s videos on PI. Among other topics, he dives deeply into WBPP. You have to pay for access, but he really takes you “under the hood,” which is how I like to learn things.)

Tony Gondola · Mar 23, 2026, 03:35 PM

Cyril Richard · Mar 23, 2026, 02:30 PM

Fabrice Lamidey · Mar 14, 2026, 03:07 AM

It is incomprehensible to me that Siril does not have a fully automated, foolproof preprocessing module. When you are into heavy multi nights multifilter imaging, WBPP will do in 10 clicks what takes over 50 or 80 in Siril, if you're lucky to know what you're doing…

I’m using mono camera. I do all my process manually. And this is easy to do… But of course, one need to read the doc :).

I’d love to know what your workflow is for that. If you had for instance, 3 nights worth of data. Night 1 is L data, nights two and three are RGB, how would you process that out so that the result is one master frame for L,R,G and B?

If I can jump in, I would load all the data from all nights into WBPP, along with the darks, flats, and darks for the flats. If I already have appropriate master darks or master flats, I would put those in rather than the individual calibration frames. Note that if all these data are in a single folder, you can just point to that folder and it will look for images in there and load them. Or you can load them by type yourself.

WPBB will identify the type of image (L, R, G, or B, dark, flat) based on the FITS header. It will also look at the exposure to match the appropriate dark to the light. For example, if your L frames are 60s and your R, G, B frames are 180s, it will realize that your 60s darks go with L and your 180s frames go with the R,G,B. Likewise it will match up your flats with the appropriate darks for those flats, and the flats with the appropriate lights based on name. In other words, it uses the information in the FITS header to match up everything.

You can verify that it got it right by clicking on different datasets in the dialog box, and it will light up the other datasets that will be used with it. You can also open a little box that shows a diagram of the calibration strategy for each dataset.

After setting up all the other parameters, you hit run and what will come out are the 4 masters.

Tony Gondola · Mar 23, 2026, 03:35 PM

I’d love to know what your workflow is for that. If you had for instance, 3 nights worth of data. Night 1 is L data, nights two and three are RGB, how would you process that out so that the result is one master frame for L,R,G and B?

I wrote a book. It explains most of my workflows. It should be published in English soon (next month?).

Tony Gondola · Mar 23, 2026, 05:27 PM

I’m certainly learning to trust WPBB more and more. Sometimes though, nothing beats just running the lights as a video when an out of family issue happens. As an example, I did a stack recently in WPBB when I get a result that showed a double frame, as if I had rotated to camera but I know I didn’t. Nothing stood out in the SAS data but when I ran the video it was obvious. Just before the end of the session the entire imaging train suddenly just rotated by about 20 degrees.

Sometimes nothing beats the old Mark-1 Eyeball and brain combo.

Yep, this is why I like to Blink before - so I can adjust the WBPP settings before I run it. In the situation you mention, I probably would still include the rotated frames (if they are just subset of the total stack). I would turn off Autocrop in WBPP, however. If the final masters had issues because of them, I would just do the last step of integration with the “good frames,” which would be calibrated, corrected, normalized, and registered already.

Tony Gondola · Mar 22, 2026, 05:28 PM

You guys will have to enlighten me because I’m new to PI and WBPP was one of the things I was most impressed with. What’s wrong with using it and what should I really be doing?

I really don’t think there is anything wrong with using it. It is just a personal preference as well as a habit to do it using individual processes instead of a semi-automated system like WBPP.

I think the time I would spend setting up, learning, and using WBPP would be at least as long as (and perhaps longer than) the time it would save me and I would be less confident of the results not having seen each step.

As far as I'm concerned (and I'm not an avid imager), the WBPP alone is a more than valid reason to purchase Pixinsight if you do LRGB imaging. It's priceless to find calibrated, aligned, normalized, and post-processed LRGB files in a single folder.

Carl Gulbish · Mar 28, 2026, 12:56 PM

In SASPro you can load up all your mono and calibration sets together into the stacker and you will get separate stacks for all your data. If you are a OSC user and using a dual narrowband filter set like hA/O3 and s2/O3… it will split them and give you separate stacks just like processing mono. Not arguing which is better, just saying they essentially do the same thing and also that one doesn’t charge you an arm and a leg to be a glorified third party script hub. Clear skies!

I’ve promoted SASPro as very effective software and I’ve used it for various tasks since the begining. Its Blink function is fantastic for culling images and finding bad data. Thing is, I never had success with the stacking suite. I’ve been trying since early in SAS development and it always failed. It might be better now as Frank works super hard improving things. On the PI side, WPBB just worked, first time out of the gate and continues to do so for me. Now if Frank can match or exceed what BlurX does with CC, well then the world changes.

Tony Gondola · Mar 28, 2026, 01:19 PM

Carl Gulbish · Mar 28, 2026, 12:56 PM

In SASPro you can load up all your mono and calibration sets together into the stacker and you will get separate stacks for all your data. If you are a OSC user and using a dual narrowband filter set like hA/O3 and s2/O3… it will split them and give you separate stacks just like processing mono. Not arguing which is better, just saying they essentially do the same thing and also that one doesn’t charge you an arm and a leg to be a glorified third party script hub. Clear skies!

I’ve promoted SASPro as very effective software and I’ve used it for various tasks since the begining. Its Blink function is fantastic for culling images and finding bad data. Thing is, I never had success with the stacking suite. I’ve been trying since early in SAS development and it always failed. It might be better now as Frank works super hard improving things. On the PI side, WPBB just worked, first time out of the gate and continues to do so for me. Now if Frank can match or exceed what BlurX does with CC, well then the world changes.

As much as I love SAS pro, it is still for my use case a big mess for stacking. I'm sure we’ll get there one day, one click stacking 😃

Wait till you discover process containers, custom scripts and chain together scripts.

I have a few I made the when applied to opened master lights, remove the extra images from the master, rename each master to their filter names, combine RGB and SHO masters from individual channels, do gradient correction, SPCC, BlurX and StarX in one go one after the other.

I made another that pre processes all mosaic tiles with processes like MosaicByCoordinates, TrimTile before I manually do Photometric Mosaic on these preprocessed tiles.

Obviously I sometimes have to do these steps manually for things that need manual intervention (like extreme gradients, which require careful background extraction). but in 80% of the cases, it’s a single action. Saves a ton of time.