DSS set black point to zero now automatic

[almcl]

For those who use Deep Sky Stacker (DSS) the latest editions (5.1.4 and on) are automatically setting the black point to 0 and there is now no option to disable this. In previous versions (eg 4.2.6) a check box was available to prevent this happening, but this has now been removed.

( Discussion on the DSS board: https://groups.io/g/DeepSkyStacker/topi ... 4092736645 )


I believe this only affects raw files from DSLRs and not .fits files from dedicated astro cameras but would welcome anyone's thoughts on how this will affect the input for StarTools?

[decay]

Not sure, if I should be the one to talk about, since I switched to ASTAP some time ago. But I do use a DSLR and sometimes I still use DSS for quick stackings as DSS is _much_ faster than ASTAP. And so I recently updated to DSS 5.1.3. I was not aware that this option was removed, but it _is_ already missing in 5.1.3. But I haven't encountered any issues. Everything worked fine. If I remember correctly somewhere in the ST documentation there's a sentence like "Some users reported that this option has to be disabled (?) to get reasonable results". Having a quick view, I haven't found this again. It's not in the official recommended ST DSS settings

I read the discussion you pointed out, but I admit, I would need some time in order to get all the details. For me, it's always annoying to see such options being removed "because most users are probably too stupid to use it right".

Do you actually encounter any issues? If so, you maybe could try to reactivate the discussion? (Interestingly they are talking about "this guy" instead of talking with him )

As a last resort, we could make a "StarTools fork of DSS" since it now is open source and then we could re-instantiate this option Yepp, that's one of the downsides of open source software.

Best regards, Dietmar.

[almcl]

Hi Dietmar

I must confess, I haven't used my DSLR for astro imaging for a while now, so haven't seen any problems as all my images come direct from the ASI 2600mc as .fits files.

Interesting idea about making a StarTools fork of DSS which, as you say, is lightning fast now compared to ASTAP. (It handles multiple nights' images a lot better as well.) I had forgotten it went open source back in 2018 so wonder if anyone has the skill and time to have a look?

[Startrek]

I’ve used DSS for 6 years over 3 version upgrades ( currently using 4.2.5 ) , initially with a Canon 600D DSLR and RAW files for first 3 years , then a OSC 2600MC and fits files for next 3 years. When started using the DSLR I followed advice from Jerry Lodriguss the Guru of DSLR Astrophotography in the US and he recommended not to set blackpoint to 0, regardless of whether you use Bias frames or not in calibration. I’ve left set blackpoint to 0 Unchecked ever since, even with my OSC 2600 MC.
Now I image with a 2600MM Mono and filters and still leave the set blackpoint to 0 , Unchecked.
Just recently I’ve moved from DSS version 4.2.5 to ASTAP as I’ve found it less complicated than DSS when stacking multiple nights using multiple filters. Both DSS and ASTAP give good results , ASTAP seems a lot cleaner though with less stacking artefacts at perimeters.

Now to answer your enquiry, I just stacked a LRGB data set ( M30 Globular Cluster ) from my 2600MM ( Calibration Flats and Bias only as that works perfectly for both 2600MC OSC and 2600MM Mono ) with the blackpoint set to 0 , Checked and then with the blackpoint set to 0 , Unchecked , and results when processed identically in Startools V1.8 ( loaded via Compose L + Synthetic L , RGB ) we’re exactly the same.
So from my initial test with fits files and DSS , checking or unchecking blackpoint set to 0 didn’t make any difference.
Hope this answers your query
PS: The blackpoint set to 0 checkbox is in the RAW files section of Digital Development of DSS ( not Fits section )
It may only affect DSLR RAW files ???
Maybe someone can do some testing with their DSLR ??

Cheers
Martin

[decay]

Interesting idea about making a StarTools fork of DSS which, as you say, is lightning fast now compared to ASTAP. (It handles multiple nights' images a lot better as well.) I had forgotten it went open source back in 2018 so wonder if anyone has the skill and time to have a look?

Maybe both. They're using Visual Studio and hopefully the Community Edition will do? But that should be a last resort. Forking would not be very friendly, I think. It would be much better to get back the option into the 'normal' version of DSS itself. I remember that Ivo asked for an option (Background normalisation?) some years ago and that should now be a way to go, too?

But first of all we should know, _if_ there's a problem at all?

So from my initial test with fits files and DSS , checking or unchecking blackpoint set to 0 didn’t make any difference.

If I remember correctly, this was true for me (using DSLR RAW files) as well.

The blackpoint set to 0 checkbox is in the RAW files section of Digital Development of DSS ( not Fits section )
It may only affect DSLR RAW files ???

Both is true, I guess. (And almcl already noted that, too.)

Maybe someone can do some testing with their DSLR ??

I already had a run with the latest version (pls. see my post above) and I did not encounter any problems. Not sure, what I could test on top?

Best regards, Dietmar.

[KlausKlaus]

Hi,
IMHO first of all we should try to understand what this “set black point to zero” option is supposed to do, shouldn’t we? Luc explains it here: https://groups.io/g/DeepSkyStacker/topic/17013739#5580

CS, Klaus

[Startrek]

I found a good article in the ASTAP manual relating to zero black points , the pedestal and Bias / Flat Dark frames

https://www.hnsky.org/astap#why-flat-darks

To hopefully add further understanding of the DSS blackpoint 0 issue

Clear Skies
Martin

[Mike in Rancho]

Ah the infamous SBPTZ.

Martin I think Han's write-up is more generic calibration explanation, while this issue is more arcane.

A few years back, when I was using both DSS and DSLR, I read this discussion on the DSS group, which might get a bit more into the nuts and bolts: https://groups.io/g/DeepSkyStacker/topi ... 2C76212692

I admit I still don't really get it.

Note that the situation arises only with certain calibration setups, and certain DSLR's. The SBPTZ box specifies a certain command that is sent to the DCRAW call, and thus is inapplicable to astrocam FITS.

That isn't to say that the underlying situation doesn't affect all cameras, but I believe most astrocams/drivers handle the potential issue under the hood, and of course there's no call to DCRAW to untangle the various proprietery RAW formats, which to my understanding are TIFF wrappers.

Based on that io discussion, back in the day I always checked the box when I used bias frames, which I always did as I used those in lieu of both darks and dark flats. Was that error? I have no idea.

I do recall one thread on CN where I think Mark Shelley (known astro/DSLR guru) ran some data through DSS both with and without SBPTZ checked off. I can't remember if he found a minor statistical difference in the results, but no visual difference was noticeable. Of course, I don't know if the particular calibration setup and/or specific DSLR used in that case actually triggered the need (or lack thereof) of using SBPTZ anyway.

Trying to chase down what SBPTZ actually means is no easy task. But, from the DSS experts who have these discussions, the warning was that certain (maybe rare) situations of a particular DSLR, particular calibration setup used, and also the potential concurrent use of another checkbox setting in a different DSS options window, could cause bad results.

But to this day I remain baffled whether SBPTZ is just forcing (or not forcing, who knows) either what amounts to a small offset to handle possible negative pixel values (similar to use of actual offset in astrocams), or is somehow using a synthetic bias (in the manner you can set up Siril to do). So, are we talking very low offset-type values here, or is it up near the (higher) bias or base darks value?

Note I have not yet downloaded and tried the new 5.x versions of DSS, but I don't know if it is substantively any different or has just been ported over to a new coding system.

[Startrek]

Mike,
I agree the ASTAP article in the manual didn’t address the specific SBPTZ issue in DSS but I thought it provided a bit more understanding about blackpoint and Bias.
Anyway your explanation of SBPTZ was excellent , clear concise and easily understood without the need to go into deeper technical stuff.
Well done !!
Martin

[decay]

Meanwhile I read the linked threads and it is interesting to see, how much confusion such a tiny checkbox can cause At a first glance and having read Luc’s first reply on the thread that Klaus linked the whole thing seems to be quite easy. But boy, the other two discussions – I don’t know if I just don’t get it … something goes around in circles and I’m not sure, if it’s only my mind.

But: I would assume that the DSS guys know what they are talking about and the decision to set this automatically seems to be somehow profounded - as far as I can judge. So unless there is any reason to think that this automatically setting does not work in all cases I don’t see any problem.

And: I just realized (Yep - late, I know!) that this is a pure DSS topic only. Or not? At first I thought that it would be somehow related to special ST needs regarding a ‘clean’ dataset (like colour / background calibration etc.), but I cannot find this connection to processing in ST … ? @almcl , do you think that there is any special relevance of this setting for processing in ST?

Best regards, Dietmar.