Bayer drizzle

[dx_ron]

@Mike in Rancho Thanks for digging into this on CN! Turns out there is a 45-day expiration on using the trial link, so I either need to ask for a new one and hope they can see that I never downloaded it, or just decide I need a good CFA drizzle and pony up the bucks.

[jlh]

Or instead of the expense of PI, consider Astro Pixel Processor. It has a good bayer drizzle and generally is considered to stack better than DSS or PI.

[Mike in Rancho]

@Mike in Rancho Thanks for digging into this on CN! Turns out there is a 45-day expiration on using the trial link, so I either need to ask for a new one and hope they can see that I never downloaded it, or just decide I need a good CFA drizzle and pony up the bucks.

No worries! I had to get to the bottom of the mystery, and as you saw I was thoroughly confused. And then surprised, but in a good way. Good grief nobody can be obtuse like the PI dev team. Nobody!

But as Derek explained it seems CFA Drizzle is now painless and automatic in WBPP as long as you turn that drizzle feature on. Now, how do you get "normal" undersampling drizzle if that's what you want instead? Simple as choosing something greater than 1.0x? And if so, what then happens to the CFA drizzle vs interpolation? Yep, clear as mud.

But I wasn't undersampled and only interested in CFA Drizzle anyway. So good enough.

Tonight I ran ST through the stacks I made in ASTAP way back when, AstroSimple debayering algorithm. I followed my log and tried to process as identically as possible. Which is never a perfect match, with ST being dynamic and the data being slightly different.

The differences are quite incremental, really just a thing for pixel peepers, and I guess those who want all pixels to be as real as can be without debayering filling in the grid. The ASTAP result was a little brighter, and a little noisier, though that could be related and a perception issue. Detail was slighly better with PI. The stars were noticeably sharper in the PI version, compared to relatively a bit bloated in the ASTAP file. I used the same settings in SVD and the same number of samples (if not the exact same stars, they were close), but perhaps SVD liked the PI data better. It's also possible that star alignment was better in PI when the duoband and SII files were registered.

So, at least with this data, yes a bit better. Would CFA Drizzle extend its lead over debayering with more integration? Possibly. I mean the more real pixels that get rained down across the entire RGB grid, the better the real resolution should be compared to interpolated guesses.

[dx_ron]

Or instead of the expense of PI, consider Astro Pixel Processor. It has a good bayer drizzle and generally is considered to stack better than DSS or PI.

I don't think I've seen a straight-up comparison of stacking in APP vs PI (unless by 'better' you mean 'faster', which I think I have seen). I have also seen that APP is great for mosaics, but that's not something I've moved in to yet.
Is there an active APP community and active development? There's not much discussion about APP on CN that I have noticed.
Finally, I'm a bit put off by the pricing model. $65 to rent for a year might be tolerable if it was "updates and support for a year, then it still works but you're on your own". "Stops working after one year"? No thanks. So the real price is a pretty decent fraction of the PI price

[jlh]

I don't think I've seen a straight-up comparison of stacking in APP vs PI (unless by 'better' you mean 'faster', which I think I have seen). I have also seen that APP is great for mosaics, but that's not something I've moved in to yet.
Is there an active APP community and active development? There's not much discussion about APP on CN that I have noticed.
Finally, I'm a bit put off by the pricing model. $65 to rent for a year might be tolerable if it was "updates and support for a year, then it still works but you're on your own". "Stops working after one year"? No thanks. So the real price is a pretty decent fraction of the PI price

APP can be purchased for €165. It has extensive forums and is being actively developed further. https://www.astropixelprocessor.com/community/

[dx_ron]

So here's an image that surely does not deserve to see the light of day - but it comes with a story related to my quest to someday properly use bayer drizzle.

Last year I shot M42 at super-low gain, but it was when I had not yet sorted out the quirks of my AT130. So some subs were shot with the wider uv/ir-cut (purple stars) and I had not yet chased down the light leaks so I had all manner of problems with flats.

The other night we finally had a bit of clear forecast (albeit the temperature was 15°F - and the wind was blowing 10-12mph).
But I got set up and once M42 got sort-of, but not really, high enough I started taking 15s subs, dithering after each sub. That didn't go to well. With lousy seeing and the wind, I was losing more than half the time to settling after all those dithers. In the end, the clouds arrived sooner than expected. In fact, at least half of the subs I did collect have thin clouds visible. But when you're whole night's effort results in all of 15 minutes worth of data (60x15s) - you just stack it all, obviously.

M42_HCG_60x15s.jpg (478.5 KiB) Viewed 1683 times

Did I learn anything? Yes, I think so.

1) I can take 15s subs at high-conversion gain and still preserve the Trapezium using ST's HDR. Not as neatly as last year with 15s subs at super-low gain, but hopefully I will gain quite a lot of SNR in the dusty bits this way.
2) Dithering every 15s is a disaster. At least with PHD2. Next time I will use the Ekos internal guider. Why? Because it has this smart setting called "1-pulse dither". They figured that if each dither move is to a new position chosen by a random-number generator, why put any effort at all into trying to land at exactly the new chosen position. Anywhere close to it is just as random - so give the mount one move command per axis, and call it good.
3) HDR created black holes in the middle of a bunch of stars. No idea what's up with that or if it will also happen with an actually serious stack, but worth keeping an eye on and maybe being ready with a pre-HDR star mask for an undo.

[Mike in Rancho]

A dither every 15 seconds? Yikes.

Whatever my subs are, I aim to dither every 5 minutes, so 12x per hour. That has seemed to work fine keeping walking noise and hot pixels (if not handled by the darks) away.

Interesting take on dithering in the Ekos. I guess they've tested it so it must be okay.

So they just pulse the axes per the random generation, and then go find the new centroid position of the chosen star and make that the new lock, instead of resetting the lock position like PHD2 and then guiding over to it i.e. settling?

Seems reasonable, though I would worry that if any backlash needed to be taken up, the mount would not end up moving as much as Ekos intended it to, or maybe not at all.

Anyway on CFA Drizzle, I believe PI now recommends it for 20 subs or more. Seems low to me, but w/e. I do recall Eyal's simulation also coming up with 20 random dithers for a test region to end up with at least one true sample for every pixel. Of course I think you really want much more, to start upping the SNR per each said pixel, and take real advantage of floating point averaging and going to 32-bit.

I imagine it's also important for the algorithm to have good "hole filling" backstops built in, and you'd likely also want good normalization of subs.

[dx_ron]

Somewhere I remember reading that, for CFA drizzle, one ought to dither every frame. (apparently I'm not the only one who recalls reading that https://www.cloudynights.com/topic/9078 ... p=13212611). But yeah, maybe that truism was not anticipating 15s subs. I have switched to dither every frame for my other OSC projects (all 60-120s subs) in anticipation of someday trying PI's CFA drizzle - so I just went for it.

I suppose backlash could compromise 1-pulse dither. Luckily my CEM0 has negligible dec backlash.