Autodev: star halos I can't seem to handle properly

[rodolgo]

Maybe this is me improperly using the Autodev module.
In my experience/conclusions, once the image leaves the Autodev module to the next processing steps, there's little that can be done to manage the dynamic range.
When stretching the image, I have to leave a small halo around mis-size stars, otherwise I lose valuable faint details in the main object.
It's a bit like: have the stars looking right or have the main object looking right - but not 2 at the same time; no win/win.
I'm pretty sure I'm doing something wrong - would appreciate guidance.
I can also provide screenshots better illustrating the challenge.
Thanks

[EDIT: confused Autodev and Develop - I do mean Autodev in this post]

[admin]

Hi,

Screenshots would be most helpful.

AutoDev will indeed reveal the full stellar profiles (please note though that these are not halos) of any stars included in the RoI (that's a feature - not a bug). A global stretch will always operate... globally (e.g across the entire image). Subsequent local based processing (always after the global stretch) can mitigate the prevalence of stellar profiles.

Deconvolution is the #1 way to to coalesce non-overexposing stellar profiles into smaller areas, followed by #2, the Shrink module (definitely try the Unglow feature).

[rodolgo]

Dear Ivo,
I've been reading other threads relating to the same topic - very interesting!
Will provide screenshots momentarily.
Thanks!

[rodolgo]

Here we go, M31 captured with an ASI 2600 MM Pro, Takahashi FSQ85EDX with field flattener (first light with this camera).
Pre processing of L, Ha, R, G, B channels in AstroPixelProcessor. Gain=0 to benefit from the entire dynamic range.
Loaded the Autodev module with the corresponding channels, used L+RGB as the processing type in the Compose module.
I have made 4 screenshots available through the OneDrive link below - too large to be uploaded here.

https://1drv.ms/u/s!AvO2KZoP803ho4UhX7F ... Q?e=nonYp0

Also dropped the pre-processed channels there, if you want to have a look to them.

Many thanks in advance!
KR
Rodolphe

[admin]

Hi Rodolphe,

Many thanks for uploading that.

I'm not seeing anything particularly worrisome, and AutoDev is - as explained - working as expected.

I'm not entirely sure what the screenshots are intending to show though? They both appear to be a preliminary/diagnostics AutoDev, as the dataset appears to be vastly oversampled and stacking artefacts are still visible.

All optical trains come with a distinct diffraction pattern; the very act of imaging through a circular opening will cause point lights to spread (diffract) light into neighbouring pixels. At the very least, your optical train will show an Airy disc profile. This is natural, and will - if stretched correctly - show up spots of light tapering off into neighbouring pixels. If stretched incorrectly, however these will appears as overexposed, whited out circles.

Stars are then further "smeared out" (convolved) by atmospheric conditions (aka 'seeing') according to a roughly Gaussian pattern.

The final resulting stellar profile of a non-overexposing star, is therefore a central point of light that tapers off. Please note that they are not "halos" in the sense of the optical phenomenon.

The final resulting stellar profile of a non-overexposing star, is also virtually identical to the Point Spread Function in your image; the full convolution kernel by which the point light was "blurred" (convolved).

The proper way to deal with the above mechanisms by which stellar profiles come about, does not have anything to do with stretching. In fact, stretching has no bearing on the presence of these stellar profiles vs other detail). The proper way to address the above mechanisms, is to apply deconvolution (e.g. convolution, but in reverse). Selective editing (in various degrees of acceptability) should be considered a last resort.

Preparing your data for deconvolution is actually the focus of half the workflow in StarTools. So for your specific dataset this means;

• AutoDev to see what we got.
• Bin to convert oversampling into noise reduction (sorely needed for deconvolution!)
• Crop away stacking artifacts.
• Wipe
• Final AutoDev with RoI over a sample of the detail your are interested in.

That gives you something like this;

StarTools_2808.jpg (289.88 KiB) Viewed 4886 times

Though noisy and suffering from some coma, deconvolution still works reasonably well on your dataset;

Selection_732.jpg (58.82 KiB) Viewed 4886 times

Selection_731.jpg (76.15 KiB) Viewed 4886 times

Note how decon works two ways here to alter the dynamic range locally at a very fine (finest) level;

• It reduces the area the stellar profile occupies (ST's implementation even does this for overexposing stars to a degree)
• it increases the definition of the restored point light versus its surroundings

both help define stars better; they directly increase the dynamic range and therefore contrast of star vs stellar profile.

Deconvolution is not a silver bullet of course. As said, from there you can use the Shrink module to taste, and particularly its Unglow feature (I used the same mask Decon made);

Selection_734.jpg (246.95 KiB) Viewed 4886 times

Selection_733.jpg (245.27 KiB) Viewed 4886 times

Beyond that, you can hold out for better atmospheric conditions, particularly transparency; e.g. being free of cloud/dust/haze that can otherwise cause light to scatter, causing true halos.

Hope this helps!

[rodolgo]

Dear Ivo,
I'm impressed by the level of depth of your reply, I wasn't expecting that much!
Many thanks for taking the time to look into my question and data.

I provided the screenshots to illustrate what I see, they were taken in the Autodev module just after loading the files in the Compose module, and at the end of the processing I did. Larger screenshots show the area I zoomed in.

• ...the dataset appears to be vastly oversampled

hmmm - I'm surprised: ASI 2600 (3.76 µm per pixel) + Takahashi 85 EDX4 (450 mmFL) leads to a sutable sampling combination, even more so under the Bortle 4-5 sky quality I have here. FWHM seldomly goes under 2", typically it is in the 3" to 4" range.

• ...stacking artefacts are still visible

Correct - fixed in the wipe module. This was a first quick run with the newly acquired ASI 2600 camera.

At this period of the year, humidity is very high at my location - dew heaters run at their full capacity. I do understand the impact on the star PSF result; it is, not surprisingly, more obvious on the Blue channel.

I assumed that the Autodev module could help mitigate the problem. Now it's clear I had wrong expectations and understanding about it.

The processing steps you took are alse quite reassuring me regarding the workflow I usually follow - I do use the same steps, except for the binning, which I will try at the next opportunity.

Again, many thanks for this in-depth investigation, it's so rare these days...

All I have to do now, is hoping for better atmospheric conditions... fingers crossed.