DSS set black point to zero now automatic

[Mike in Rancho]

So, just for clarification: This is right now the only case we can think of where it is useful (or even necessary) to uncheck SBPTZ, right?

Oh, potential scenarios can always be dreamed up. Maybe silly stuff, if somebody gets themselves in a pickle.

Let's say you got a master flat you want to reuse (who knows why) but you know it was bias or dark flat subtracted already when generated, so you need to subtract the "black point" off your RAW lights. That should work.

But yeah the only reasonably common possible use situation would be just having lights and flats so you need a quick analogue for bias. Maybe you know you have a light leak for darks, or it's bright daylight and the camera can't be taken off the rig.

[decay]

Yes there may be such very special scenarios, but I wonder if this should be handled with such a checkbox. Maybe more something where I would thinking of using pixelmath or likewise. But nevermind ...

But I'm still with you (and still with myself ) that it would be better to have such a box and the possibility to decide and/or override. Even if the main scenarios work well with this automatic setting as we now proved. But that's not up to us, I guess ... but nevermind again

To get back to ST and to this topic: I think we now can say that there is no impact of this automatic setting for processing with ST. Maybe one fine day Ivo decides to update the screenshot in the documentation with a new one which lacks this famous SBPTZ box ... RIP Or Ivo draws a bold red X across it

[dx_ron]

So here's little ole me a long-time Siril user just wanting to try dss Bayer Drizzle on my shiny new OSC-dithered-to-all-get-out data from last night so I fired up that old copy of dss 4.2.6 I installed years ago and saw a notice about 5.1.3 and downloaded that and remembered that there's this thread with its urgent-sounding title so I read the first page and jumped right to the dss board link and got confused so came back here and read the rest of this thread and got more confused and now I've spent the evening just reading and getting confused and oh heck I'll just stick with 4.2.6 and hope Bayer Drizzle sucks so I can go back to Siril.

[dx_ron]

I'm saved! The initial dss result sucks!

1st_dss.jpg (489.96 KiB) Viewed 23518 times

Though I guess I probably have some basic dss setting totally wrong. Maybe I'll start an Image Processing Troubleshooting thread over the weekend

[Mike in Rancho]

What is that result screenshot from? Wipe, or OptiDev, at < 100% scale?

That may not be unexpected. CFA Drizzle is a strange bird.

The options are pretty much only DSS and PI. I've never tried the PI version. But you have to have a lot of dithers, and lots and lots (and lots) of subs overall. You also can't use sigma rejection, only averaging. And thus also, good darks to remove hot pixels are a must.

Even so, the stack comes out weird, and with unusual anomalies. Like your grid. That's why I asked about the scaling. If you take it up to 100%, some or all of that may vanish. It's a hint that oddities are there though.

I went back to the one time I used CFA Drizzle, in DSS 4.x, for some duoband Rosette, and gave it a new quick run in 1.9b. You can't take the first OptiDev at face value. Nor would you want to! It's going to need a crop most likely, but it's hard to see where. So IFD and an ROI are required, even on OD1. From there you should be able to crop off the bad edges. After that, a 50% bin will hopefully take care of the gridding anomalies. Then you need a Wipe of course which helps clear out the channel casting. And it should OptiDev decently enough after that.

I just put my Rosette through OD1, Crop, Bin, Wipe, OD2, Color, and DN for the test. Not bad really for not using any SVD or enhancing modules.

Better than debayering? I dunno.

[Startrek]

Apologies for deviating off the blackpoint topic …..
I’ve had the dreaded checker pattern too in Startools after an initial AutoDev.
Here’s the post and threads on the DSS forum a month ago

https://groups.io/g/DeepSkyStacker/topi ... 3285587002

The same data set stacked in ASTAP never had the checker pattern issue in Startools and what’s even more strange, subsequent captures in Broadband stacking in DSS didn’t replicate the issue either ??
This issue remained unresolved but didn’t occur again and I’m using a Mono camera so nothing to do with De Bayering with DSLR / OSC scenarios.
CN had loads of posts from folk with a similar problem.
My best guess is Stacking / Calibration parameters on these super sensitive Sony sensors may be the culprit.
Clear Skies
Martin