FBPP vs WBPP: I Cannot Believe What I Found Out!
Vložit
- čas přidán 29. 06. 2024
- Join this channel to get access to perks:
/ @setiv2
I went into making this video thinking I was going to find some very strong evidence in favor of WBPP....
Follow with me as we take a deep look at the outputs in a more rigorous method then just "eyeballing it"
I appreciate any comments and suggestions! I tried to be as methodical as I could in the comparisons. What has your experience been with FBPP vs WBPP?? - Věda a technologie
Interesting. When you have FBPP create the drizzle files, they all have identical weights. In WBPP it measures every file and weights them accordingly. In FBPP it just assigns a weight of 1.0 to each drizzle file it produces. It does make individual Scale Factors and Zero Offsets for each file. I'm curious how that will affect the quality of the final image. Working on that now.
Thanks for this Frank! This is fascinating! I've tested standard WBPP with and without weights and found a large difference in the past, but now I'll check with FBPP and WBPP - I suspect that very light polluted cities like Tokyo, where the difference at 30 degrees altitude and 80 degrees is extremely massive will have more of a difference.... but stay turned!
Looking forward to it. My part two is all about drizzling from FBPP and how WBPP wins for sure.
VERY interesting. Not what I expected, either. I’m one of those hardcore individuals that will still use WBPP, but in a pinch, this is a great option!
Thank you for doing this!
My my my!! You are the wizard my friend!!
Great analysis! I've been playing with FBPP vs WBPP and I agree with you that if you're not drizzling, FBPP is the way to go. Although it has the drizzle option that you can integrate later, it's just another few clicks that I wish I didn't have to do. Hope they include it into FBPP at some point.
Be sure to watch part 2. If you are drizzling you will want wbpp still
Interesting.
Great comparison. Looks like it’s better to lean on WBPP for under sampled data (2x or up) and FBPP for almost everything else.
RC Astro has a great tool to see if you need to drizzle. Hint: almost everyone needs to drizzle
www.rc-astro.com/mtf-analyzer/
Nice, i will stay with WBBP drizzle , takes longer but so what, drink a cup of coffee in the meantime 😀
Good review and informative results. I wonder if you took the “slow” tasks (LN, autocrop, astrometric solution etc) out of WBPP so it ran at its fastest, and then compared to FBPP results, wouldn’t the difference be due to the stacking algorithm WBPP chooses to use, and the fast algorithm FBPP uses?
No, not entirely, measurements in WBPP run full subframe selector and calculate weighting schemes. This also provides rejection of bad frames, selecting the best reference frame, etc. So you do get some m9re than just the integration algorithm. But as this shows there is not much differemce at all. That is how I ran the no normalization stacks. The difference comes down to mostly difference is stacking noise. Drizzling on the other hand is a different beast
HI thanks for that investigation! You said drizzle would not be possible, but there is a "generate drizzle" option in the FBPP. So that after the integration one could run the drizzle integration no?
I still need to do that test, but for a preprocessing script I am hoping they incorporate it within the script.
Yes you can. I checked the generate rejection maps/drizzle option.
After FBPP is done, you can invoke the drizzle process in PI, then point to the generated drizzle files, they are under the fastintegration folder.
Interesting. The drizzle files have all identical weights. In WBPP it measures every file and weights them accordingly. In FBPP it just assigns a weight of 1.0 to each drizzle file it produces. It does make individual Scale Factors and Zero Offsets for each file. I'm curious how that will affect the quality of the final image. Working on that now.
@@setiv2Really interested to see how that goes - my rig is under sampled but would love to speed things up.
@@setiv2 well because there is no weighting right as this is not a weighting prozess? Or should drizzle also have a weight without that?
The lack of prominent structure different since too surprising since the only thing really targeting that is local normalization, right? You’d probably see a much bigger hit there, losing local normalization, if the gradients varied more across images.
I think it does do pedestals, but defaults to auto? I’d have to double-check. I think I just saw that in the release notes.
A lot of the extra stuff happening is to improve signal vs noise and rejection.
It has to do pedestals, i see warning in the console if the calibration dips negative. My gradients varied a lot, these were all multi night images spanning may hours.
The other thing I looked at was SNR in all images. SNR is right in line with WBPP both with no normalization and with local normalization. Again, i was expexting WBPP to beat out FBPP in SNR but it just doesnt.
Regarding local normalization, it is easy to set up a case where it is able to significantly alter or simplify gradients. And if it is not done, you will get the weighted averaging of those gradients. Since the fast integration method does not employ local normalization the gradients you were left with were a product of that simple averaging, so they must not have been so bad in practice. Kind of a simple if/else sort of scenario.
Agreed especially true if you are stacking a small number of frames with heavy gradients.
Interesting. So how does this one stack up.
WBPP has a similar option, and as I understand it is based on or incorporated from the FBPP. So, in WBPP , It only needs to be turned on; and this is an option is under POST-CALIBRATION - Fast Integration.
It only has two options, ENABLE-SAVE IMAGES you need to select them both. But before doing that you will need to select the image stack that you want to apply it to.
For instance, If I only wanted to apply it to my HA and not my SII or OIII then I would only select HA, and turn the feature on. HA would be processed at the very fast rate and the SII and OIII would be processed at the normal WBPP rate-slow. Else, apply it to all Filters.
Correct, in wbpp you can have fast integration on one or more of your channels. Some caution is you are drizzling, the fast integration if checked will not calculate weights for drizzle files for that channel. So still good for a quick view, but full wbpp will be needed for drizzling
Good video - but why not use the FI in WBPP? In WBPP, you can check the Fast Integration box in the Post Calibration tab, and you still get a drizzle option. I run Subframe Selector first before anything (yeah, old school, I know), and I assign my own weight calculation into WBPP under the calibration/integration tab.
That's a great point, although this video is comparing FBPP to WBPP, you can run Fast Integration in WBPP. This will measure every subframe instead of the first 15 and will select the best out of all vs just the best out of the first 5. The main problem is drizzle weights are still set to 1.0 in all the drizzle files from Fast Integration even when running it from WBPP. So as far as drizzling goes you still need to run the normal full WBPP (or using some manual option like NSG or SubFrameSelector) if you want the correct drizzle weights applied during the drizzle process, which none of that is available in FBPP.
@@setiv2 I will give this some thought. Surely there must be a way to devise a workflow that gets the best of both worlds using subframe selector, WBPP/FI, and the drizzle process. Maybe the result is to simply stick with WBPP, and reject the FI temptation need for speed until PI presents a solution.
@@SteveKennedy2902 I think your latter thought process is the correct one right now. Once you start doing manual weights and stuff you can just run WBPP
Probably the difference gets less with more data, how would it compare with less number of images?
I didnt run it with very few images. 48 exposures was the fewest in my test.
Shouldn't you have calculated the absolute value of the difference (WBPP-FBPP)?
No, you dont have to. You cant do a straight subtraction becuase of clipping below 0, that is why I added that 0.02 pedastal (pixelmath internally uses negative numbers, just at the time of output does it clip to zero so if you add a small value in your equation you can do a traditional subtraction) If you choose not to add a pedastal then you have to do an absolute value. The reason i did it this way is that the brighter areas reflect brighter areas in the one image and dark areas are brighr areas in the other. If you use absolute value you lose that ability to discern which image was brighter than the other
@@setiv2 Maybe I'm missing the evaluation of the minimum value of WBPP-FBPP. Have you validated that (WBPP-FBPP+0.02) is greater than 0.02 for all pixels?
If WBPP and FBPP have both brighter areas compared to the other, you could display both differences simultaneously by creating an RGB image, let's say R=WBPP-FBPP, G=0, B=FBPP-WBPP.
I think that could be an interesting test to run!
(I'd do it but I'm waiting a little longer before updating to 1.8.9-3, it wasn't a clean update when I tried on the release day...)
After subtraction the variance in background ranged from 0.0190 to 0.0210 so yes, 0.02 in my examples were more than sufficient. You can also do a split of color too, but that makes removing global gradients harder like I did in my example. All great suggestions though! Use that knowledge and use it to investigate gradients extracted, stacking, etc. Glad to see someone out there wanting to analyze too :)