12 replies to this topic

[smiller]

I have a set of sub-stacks and normally use SIRIL or APP to stack these? 

 

Here are the attributes that may trip up WBPP

 

1) These are already debayered 32-bit RGB .FITs files 

2) They aren't registered to each other and have slightly different dimensions as the sub-stacks were stacked without a crop

 

For SIRIL and APP, I can just load them up and stack away.  But I'm not sure what modifications to WBPP's settings are needed to enable the stacking of this type of data.

 

Thanks,

 

Steven

[Jared]

How many stacks? I think I would just do a star align to get them to the same scale, then use Pixel Math to average them together with appropriate weighting based on aperture diameter and integration time.

[idclimber]

Yes, but I believe there is a minimum number you need and too few and rejection can not occur.  WBPP will toss warnings since you will not need darks etc, but it should run. 

 

You really only need two tools. Star Alignment and Image Integration. Pretty easy to do this manually. Just turn rejection off in Image Integration if you don't have a lot of sub stacks. If you need them weighted use pixel math as Jared suggested. If you need help with a formula let us know. 

[smiller]

I usually have 20 to 100 substacks.

[idclimber]

I usually have 20 to 100 substacks.

The main advantages to WBPP is weighing and organizing your calibration. You don't need calibration and If you do not need or want weighting then I would do this manually. 

 

If you ever want to know what settings WBPP uses you can open the script in the output directory and load all the steps into a Process Container. You do this in the Script editor. You could do this and then save your settings in an icon file. Then when you want to do this simply open this icon set instead of WBPP. 

[smiller]

The main advantages to WBPP is weighing and organizing your calibration. You don't need calibration and If you do not need or want weighting then I would do this manually. 

 

If you ever want to know what settings WBPP uses you can open the script in the output directory and load all the steps into a Process Container. You do this in the Script editor. You could do this and then save your settings in an icon file. Then when you want to do this simply open this icon set instead of WBPP. 

I wanted to test PI's ability to stack these sub-stacks and weight based on SNR and/or FWHM or whatever combination WBPP defaults to.   

 

I've been happy with APP, but when I check its SNR and "Quality" results (a composite measure) for the individual sub-stacks compared to how they look visually, it reduces my confidence a bit that they are weighted appropriately. 

 

 

So I thought I would do a few more "chili cookoff" comparisons with a few of my sub-stack collections.

Edited by smiller, 16 September 2024 - 06:09 PM.

[idclimber]

I wanted to test PI's ability to stack these sub-stacks and weight based on SNR and/or FWHM or whatever combination WBPP defaults to.   

 

I've been happy with APP, but when I check its SNR and "Quality" results (a composite measure) for the individual sub-stacks compared to how they look visually, it reduces my confidence a bit that they are weighted appropriately. 

 

 

So I thought I would do a few more "chili cookoff" comparisons with a few of my sub-stack collections.

I understand. Another thing that you can do is run WBPP and then reopen the Image Integration tab from that process container. Then you can change the weighting and other settings without running WBPP again. This would allow you to more quickly compare different weighing schemes. 

[smiller]

I understand. Another thing that you can do is run WBPP and then reopen the Image Integration tab from that process container. Then you can change the weighting and other settings without running WBPP again. This would allow you to more quickly compare different weighing schemes. 

What I can’t quite figure out, and this exposes how little experience I have with PI, is how to get WBPP to recognize these substacks as lights that are already debayered with only the need to register, normalize, and stack.

 

Up to now I’ve only used WBPP in it’s intended fashion: With actual raw lights, biases, flats.

Edited by smiller, 16 September 2024 - 07:02 PM.

[idclimber]

I did not have any OSC integrations handy so I simply borrowed one from the Processing thread here at CN. I then copied it a couple times. I was able to load the XSIF in WBPP by using the Lights tab. 

 

To have it not debayer turn off CFA as shown below. I also turned off CC and changed the pedestal to 0 as that is not needed either. Then ran WBPP with no errors. 

 

 

Here is the image container showing each step. To repeat this without bothering with WBPP simply copy these three icons to your PI desktop and save for future use. Then simply load the appropriate files and select output folders, etc. 

 

Open the log in Script Editor tab and hit the lighting bolt on the top (compile and run) to get this image container. 

 

 

[smiller]

Thanks for working on this.

 

Now the problem I’m running into is more clear:  It doesn’t seem to like that each of mine has a slightly different dimension so I think it is trying to integrate them separately and it gives me the error that I’m trying to integrate a single image (“Error: Only 1 frames provided.”)  even though I have a dozen loaded.  It’s like it’s a dozen integrations of 1 image each.

[joshman]

Can you load them all into an image container, perform a dynamic crop to get them all to the same dimension, then run them through the integration steps?.

 

Alternatively, manually performing the registration step first should bring them all to the same size/resolution.

[Jared]

I usually have 20 to 100 substacks.

OK, so this begs the question... Why would you have that many substacks? I can see three or four if you were imaging with multiple telescopes/cameras across multiple years, but twenty to 100? All OSC?  How does that happen? Are you trying to integrate the work of a bunch of different imagers?

 

In any event, you are correct that WBPP will want all files to have the same dimensions, so you're going to have to perform a star alignment before you run them through WBPP for the integration. Then you can load the files as outlined by idclimber, and just turn off registration as a step.

 

Seriously, though, how did you wind up with 20 to 100 substacks of OSC data?

[smiller]

Can you load them all into an image container, perform a dynamic crop to get them all to the same dimension, then run them through the integration steps?.

 

Alternatively, manually performing the registration step first should bring them all to the same size/resolution.

 

That would be another option I expect.  I may give that a spin.

 

OK, so this begs the question... Why would you have that many substacks? I can see three or four if you were imaging with multiple telescopes/cameras across multiple years, but twenty to 100? All OSC?  How does that happen? Are you trying to integrate the work of a bunch of different imagers?

 

In any event, you are correct that WBPP will want all files to have the same dimensions, so you're going to have to perform a star alignment before you run them through WBPP for the integration. Then you can load the files as outlined by idclimber, and just turn off registration as a step.

 

Seriously, though, how did you wind up with 20 to 100 substacks of OSC data?

I regularly capture thousands of short exposures due to leveraging my Alt/Az Goto Observational Dob for Deep sky and stacking in chunks makes the whole process fairly easy as I have it pretty automated with a SIRIL script.

 

So I stack in ~10 minute substacks and I describe it a bit here:

 

https://www.cloudyni...s#entry13656982

 

and I share a bit of my SIRIL script that does it here:

 

https://www.cloudyni...s#entry13344157

 

and I talk about the impact on image quality here:

 

https://www.cloudyni...s#entry13408317

Edited by smiller, 17 September 2024 - 09:23 AM.