What causes stars to look like that ?

[Seven007]

Hi Guys,

I did some further testing and compared Autodev and Filmdev.
For this testing I choose a Stack of M31 which was done with the same setup and stacked in APP.
I minimal cropped away the corners for wipe and reduced the FOW so that processing will be faster, afterwards Autodev or Filmdev followed.

The results are below:

1 Start – Crop - Wipe – Crop – Autodev - No ROI – Full FOV
2 Wipe-Crop-Autodev-No ROI
3 Wipe-Crop-Autodev-ROI-M31 Core
4 Wipe-Crop-Autodev-ROI-Star

5 Wipe-Crop-FilmDev-70%
6 Wipe-Crop-FilmDev-80%
7 Wipe-Crop-FilmDev-90%
8 Wipe-Crop-FilmDev-95%
9 Wipe-Crop-FilmDev-98%

Mike is right Autodev is doing something more with the image, which works usually very well but seems to alter the stars in my case. I don’t know if this ring is already there and Autodev brings it out?

I also tried a DSS stack of the same Data, same result. I tried GraXpert just for stretching same result like Filmdev no ring.
So way to go use Autodev for DSO-Object and combine with stars stretched in Filmdev?

Best Regards
Sven

[Seven007]

image 4 to 6

[Seven007]

image 7 to 9

[Seven007]

Hi Jochen,

thanks for your reply .

I think too that stacking is ok and hope the APO is ok as well:-). My testing showed that Autodev seems to bring in this rings in my case.
I will try to reduce them like you suggested in SVDecon later or avoid them by different star processing.

Best Regards
Sven

[Seven007]

Hi everyone,
Sorry the images in my post above are not in a good structure to read.

Therefore again in one post, hopefully better organized.

1 Start – Crop - Wipe – Crop – Autodev - No ROI – Full FOV
2 Wipe-Crop-Autodev-No ROI
3 Wipe-Crop-Autodev-ROI-M31 Core
4 Wipe-Crop-Autodev-ROI-Star

5 Wipe-Crop-FilmDev-70%
6 Wipe-Crop-FilmDev-80%
7 Wipe-Crop-FilmDev-90%
8 Wipe-Crop-FilmDev-95%
9 Wipe-Crop-FilmDev-98%

[Mike in Rancho]

Hi Sven,

My suggestion to use FilmDev was more for experimental purposes, rather than to say it should be used. As is noted, the stretch produced therein is not optimized for your image's overall dynamic range, as defined by the settings you choose. I suppose it can be used, and we have had discussions of that in prior threads. Mostly though about those who prefer a "classic" fuzzy balls look to stars, and are willing to give up an optimal target stretch to achieve that, compared to the more well-defined and pinpointed stars of a proper AutoDev.

I'd also note that FilmDev probably works best, in its own way, with a more precise digital development (it goes to the hundredths) than things like 80, 85, 90.

I'm also not sure if "core of M31," which can often be nearly star-bright on its own, is a good test of using the ROI to avoid say, saturated cores. I would slice it a different way. Again, avoiding areas that are possibly fully saturated, meaning bright stars and yes, maybe M31 center core. Also, did you utilize IFD?

If you'd like to link your stack, and perhaps a single light sub, we can examine the files and perhaps see if the stars are overexposed, and if so to what extent. Are the subs FITS files with completed headers (taken through say, NINA)?

I presume you are using the DSS autosave or save as (embedded) at 32-bit depth, and no use of cosmetic correction (DSS' clipping handling)?

You can for sure see the other differences between AutoDev and FilmDev in your posted examples though - as the FilmDev bright stars appear as large fuzzy cotton balls and do not begin to resolve in towards a point surrounded by diffraction effects.

[hixx]

Hi Sven,
I'd recommend AutoDev, as it optimizes the global stretch against the ROI rather than applying a fixed "film" dynamic response.
However, finding a good ROI on M31 might be tricky, as it is a challenging HDR object for sure.
My best attempts were vertical rectangles which included the core, M110, and at least one bright star, but also extended up/downwards to include the outer spiral arms. Try to experiment. Once You dragged a square yielding a result close to Your expectations, try working with the sliders, to slightly enlarge/reduce the area. Once You'll get a feeling for the ROI, you'll be able to yield much better results from AutoDev (and also the following local stretching tools).

Another tip for M31: try to add an NBA dataset from Ha or Duoband into Compose to bring out the Ha regions. In APP, You can stack both onto the same registration, by loading all lights as 2 sessions and on tab6), use Multi/Channel filter option "Integrate all" plus Multi Session option " integrate per session". This will produce 2 integrations registered against the same reference frame which You can load in ST Compose as R, G, B resp. NBA
Clear Skies,
Jochen

[Seven007]

Hi Mike,

Filmdev was just used for checking the stars (no panic ). The overall outcome of M31 in Filmdev was nothing in comparison to Autodev and I usually never use Filmdev.

The only advantage was that there is not this ring in the stars. You know it is just a tiny ring but if know that it is there it bothers you. Same about the cotton ball stars (I have to laugh about that ) after you wrote that I notice them and it bothers me too.

I choose the lesser values for Filmdev to see if the ring is obvious in lower stretched version or if it is burned out and masked in a white cotton ball with stronger stretch.

I tried several regions for ROI (bright/dim stars, no stars, bright/dim parts of the galaxy,…) in Autodev but had no luck with the rings. Ignore fine details doesn’t help.

For stacking I tried DSS and APP and followed the points of the Homepage for settings. Both stacks look similar in terms of the ring in the star.

I uploaded the APP Stack and a randomly choosed light frame und would be happy if you take a look at it. It was taken with Stellarmate/Astroberry, light frames are in Sony (SLT58) native raw format.

The Stack contains two nights with about 900 lights and roughly 9,5 h imaging time.
(Calibrated with Flats and Bias)

You will see Bortle 5 and light pollution ☹

light frame
https://drive.google.com/file/d/15wSobJ ... p=drivesdk

APP-Stack
https://drive.google.com/file/d/15pi-Eg ... p=drivesdk

Best Regards and thanks
Sven

[Seven007]

Hi Jochen,

you are right M31 is challenging. Very easy to get first results but also with challenging HDR parts.
Thanks a lot, I will try the vertical rectangles

My best attempts were vertical rectangles which included the core, M110, and at least one bright star, but also extended up/downwards to include the outer spiral arms. Try to experiment. Once You dragged a square yielding a result close to Your expectations, try working with the sliders, to slightly enlarge/reduce the area. Once You'll get a feeling for the ROI, you'll be able to yield much better results from AutoDev (and also the following local stretching tools).



Another tip for M31: try to add an NBA dataset from Ha or Duoband into Compose to bring out the Ha regions. In APP, You can stack both onto the same registration, by loading all lights as 2 sessions and on tab6), use Multi/Channel filter option "Integrate all" plus Multi Session option " integrate per session". This will produce 2 integrations registered against the same reference frame which You can load in ST Compose as R, G, B resp. NBA

I am looking to that in future to get NB data, my Sony SLT58 is quite old and will be replaced but i am still looking for the right cam.

Best Regards and CS
Sven

[Mike in Rancho]

Hi Sven,

Sorry it took so long, but I did finally get a look at your files. I didn't see anything wrong with the single sub, there are a few star core oversaturated pixels, but pretty much within reasonable bounds in my opinion. Is it a 12-bit camera? I'm not quite sure what the bias level is supposed to be.

One thing I did notice is that with binning, the ringing issue substantially if not completely goes away. I know you may not be undersampled for good seeing, but is there any other reason for maintaining the full resolution?

While maintaining the original dimensions, I could see the ringing and wasn't really able to make it go away in AutoDev settings. I suppose it could in fact be the handful of brighter stars that oversaturated. You could always try a few comparison tests - get the same total integration but maybe try one with 30 second subs. Or, if it is viable for that camera, drop to ISO 100 for greater well capacity. I'm not sure what "unity" gain might be for the Sony there, or if ISO 100 might get a bit wonky.

Some fiddling with settings did seem to minimize the star ringing, but if that was otherwise hampering the overall AutoDev optimized stretch I am unsure. But you could try a thin slice ROI through the galaxy, horizontal or vertical, avoiding those bright stars (and perhaps the core as well) so that they would not be taken into account aside from the outside-ROI parameter.

Off topic a bit, in the full stack I did seem to be getting some odd artifacts on either side of your stars, typically green. Like "--O--". I did not see that in the single sub. Uncertain if it comes from other subs, or perhaps a kind of debayering artifact from APP? Weird. To account for that I did use both DAF in Wipe and IFD in AutoDev.