StarTools

Last night was clear but very moony, so I just shot a few hours of M3 with the AT130EDT+IMX571c. I stacked about half of the subs, which all had FWHM at or better than 2.3" - 220x45s Low-Conversion Gain (gain 0 to you ZWO folks).

The brightest star in the frame is mag 6 (which is possibly related to why I always have a devil of a time star hopping to M3 - that plus the fact that I don't do star hopping very often). It ended up with the typical flat core + donut ring, so I thought I might go back and start from the beginning to see how/if the star's profile evolves.

First, the linear file. I guess I should have Dietmar's cool profiling tool, but instead I just had the linear file in Siril and manually panned away from the star in one direction to see if there was any sign of a hump. I could not detect any hint of a donut hiding in the black parts near the star based on the reported pixel values.

In St, here is the star blown way up while linear (Cropped only) Note that this is blown up to 3200x, so it's not really comparable to the next images. There's no sign of donuting, but the donut to come would be off in the inky blackness of linear space.

Next, into Optidev with no IFD or RoI. This is at 800x, so 1/4 scale vs the first image And - there's already a donut effect.

In the Wipe module it is too blown out to see if the donut is there or not.

In the post-Wipe OptiDev, it is back - unsurprisingly (now down to 300x): I can affect the relative brightness of the outer ring by doing weird things like making an RoI around just the star - but that totally screws up rest of the image, of course.

Ah, glad you started researching here. Been wanting to get to this one. I sorta did months ago with those 3D star graphs, but never dove back into it.

Now, I'm reasonably sure none of us are picking up the first dark Airy ring and then stretching/enhancing it?

I do think the scaling will need to start matching, so we can follow along spatially with where things are happening. I also think the next step will be other stretches. Back when I made those graphs I just did one of OptiDev (or maybe it was AutoDev) and one of FilmDev. Of course FilmDev had a nice graduated profile, albeit while being blown up the way traditional stretching handles stars.

Perhaps begin by staying in the linear realm, and thus a linear stretch -- just adjust black and white points enough to (hopefully) begin seeing what's in the pixels where the fluctuations would start happening. Siril should be able to do that readily in linear with the user sliders. If there's no donut, then we keep digging.

And yes, along with sample pics, the Dietmar viewer could also give us nice profile slices.

Mike in Rancho wrote: ↑Fri Mar 22, 2024 2:03 am Perhaps begin by staying in the linear realm, and thus a linear stretch -- just adjust black and white points enough to (hopefully) begin seeing what's in the pixels where the fluctuations would start happening. Siril should be able to do that readily in linear with the user sliders.

Yep! I too think, that should be the way to go. First step.

Figured I would add a few more thoughts.

First we probably need to break things down into a few different considerations. One would be saturating vs non-saturating stars. Another would be composition, whether looking at mono, and if LRGB mono or even OSC, query how the channel averaging that generates the synth L might work in this regard. And third possibly look into stacking settings.

I also now note on reread that you already tried the linear sliders in Siril, so you were ahead of me there.

No images, graphs, or numbers yet, I'll try for that on the weekend. But I did toy around a bit.

Using M33 data, I inspected the star HIP 7123. Mag 8, somewhat reddish. For me, both 20-second L and 60-second RGB slightly saturate.

Using OptiDev on both mono L and a composed RGB, I got the same donut appearance.

I then tried out several things in FilmDev with both gamma and development, no donut. Likewise in Siril, using numerous viewing stretches, linear slider settings, and L vs RGB. Finally I stretched the image using GHS after neutralizing the background. No donuts. I still need to try PI, which to me has a better implementation of GHS, but I imagine it will turn out similarly.

So what gives?

Now here's a kick in the pants. I took a number of screenshots and pasted them into Gimp, so I could put a levels pointer on things. And...it's an illusion.

At least during this quick test. When I moved the pointer, no matter what vector, away from the saturated core, I would start at 255 and always continue downwards.

I'm baffled. Again, this "seeming donut" is only out of OptiDev. Not FilmDev, not GHS, or anything else. But the numbers don't give me a donut. Do I need an optometrist?

Maybe there's something about the size and shape of the way OptiDev is stretching stars. On the weekend I'll try putting a similar pointer on stretches from FilmDev, GHS, and whatnot. And maybe looking at comparative stellar profiles using the Dietmar viewer will give a clue.

Wow! Indeed an illusion. My work is calling ... will reply again on the weekend.

Of course, the outer bright ring is an illusion. But this 'plateau' around the inner core doesn't seem to be correct. Probably indeed an OptiDev issue, which maybe would explain the reported problems with HDR and SV Decon as well ... ?

But we have to dig deeper into it. I would suggest we all should do the next evaluations using the same dataset. Would you mind to share your dataset? You could send a PM to Mike and me ...

Live long and prosper

No need to share, Ron. I was able to reproduce this easily with my latest own dataset containing saturated stars:

Stellar profile as displayed in Fitswork (this is independed of the actual active stretch!): FilmDev: OptiDev (full ROI, only IFD set): The 'plateau' causing this ring is easily visible.

Now we have to think about why this is happening. A 'plateau' means, that a range of input brightness levels is mapped onto the same output brightness level. I suspect that OptiDev constructs its stretching curve depending on the distribution and weighting of the input brightness levels.

So OptiDev probably analysed that above mentioned input brightness range plays no role in this image and assigned no or only very little dynamic range.

Perhaps OptiDev's mapping algorithm is too aggressive?

This is more obvious with larger stars, where the ring or 'plateau' becomes wider and better visible.

Does this make sense?

Best regards, Dietmar.

Yes, it seems only two distinct values are assigned to the core regions of bright stars. The max value to the 'inner core' and then just one slightly lower value out for a distance surrounding it.

It feels weird to realize how much time I've spent chasing an optical illusion (usually with fuzz in SVD) - yet the optical illusion really does degrade the appearance of the images.