StarTools vs Siril - A challenge

[dx_ron]

Alex, here is the log

StarTools_log.zip

(125.96 KiB) Downloaded 67 times

[admin]

Thanks Alex,

My Siril image had nothing done to it that should have synthesised anything.
...Starnet...

Starnet is one of the worst culprits for artifacts and blatantly making stuff up. It reinterprets the entire dataset.
Fortunately it is the least sophisticated at doing this, so it is easy to spot. It has no place in a documentary workflow and doesn't solve anything that needs solving; separating stars and nebulosity is not a useful or recommended practice (if you aspire to do documentary photography) for a great number of reasons some of which include;

• It introduces detail/signal that was never recorded.
• It reinterprets detail (including noise) into detail that was never recorded.
• It makes measuring point spread functions impossible.
• It creates final images that do not resemble reality nor can be compared to other images of the same area.

some artifacts

I would consider the "some" qualifier to be somewhat optimistic... There is very little original detail left.

My recent disappointment with my StarTools images have been due to a couple of things that I have never been able to resolve.
First, stars look "hazy" when using AutoDev - the centre coaleces nicely into a point, but leaves a coloured halo that makes it look like we're seeing through fog.

It's the software's job to optimise the dynamic range. Being able to see the point spread function accurately reflected in your stars is a (hard-won!) feature - not a bug. If your stellar profiles are especially "fuzzy", then a number of things may be at play. It is better to understand those than to paper them over, as this affects the quality and appearance of your entire dataset.

Some typical causes may include;

• Transparency may have been poor on the night (you may, indeed, be imaging through "fog").
• Filter coatings may be poor or compromised.
• Dew may be compromising some frames.

As for quantization, I noticed the Dropbox ZIP file compressed an enormous amount. This can be an indication of poor data depth (making it easier to compress), which may indicate a fundamental issue with the way the dataset is stacked and/or acquired. What sort of stacking algorithm and how many frames is this? Are you using recommended exposure times, and what exposure time did you use for these datasets?

StarTools 1.9's OptiDev allows you to choose brightness tranche bit-depth, which can help deal with aberrant discontinuities in the highlights (introduced by some sensor/stacking algorithm combinations). For your dataset, you could try increasing this from the default 12-bit to 13-bit or higher and see if the stars are more to your liking?

[ajh499]

Alex, here is the log

StarTools_log.zip

Thanks, I'll take a look through and see if I can use any of your techniques.

I would consider the "some" qualifier to be somewhat optimistic... There is very little original detail left

Would you mind showing me what you mean? That Siril image is literally the only image I've processed using that software, and while I may or may not stick to it, I'd like to understand what you're referring to so I can avoid it in the future.

It is better to understand those than to paper them over, as this affects the quality and appearance of your entire dataset

Understanding the issue would help, I might not be able to do much about it, but it would help. However, when this data set is from the first time in two and a half months that we've had clear skies, papering over issues is about all I have left

Some typical causes may include;

Transparency may have been poor on the night (you may, indeed, be imaging through "fog").
Filter coatings may be poor or compromised.
Dew may be compromising some frames.

Those things may all be true, but every image I've processed with StarTools, over years has the same look to it (with AutoDev/OptiDev). Regardless of exposure time, sub length or even scope. The only things the same are the camera and filters. This is the first image after having cleaned the filters and nothing has changed.

What sort of stacking algorithm and how many frames is this? Are you using recommended exposure times, and what exposure time did you use for these datasets?

These were 30 second exposures for LRGB which was already giving around 20 stars clipping, I don't think I could go much longer.
The subs were stacked using SirilIC with winsorized sigma clipping. I've played around with the stacking algos in the past and not seen much difference.
I've had another go at stacking, there are a few subs that should have been rejected originally that were not and taking them out does improve sharpness a bit, but doesn't fundamentally change anything

StarTools 1.9's OptiDev allows you to choose brightness tranche bit-depth, which can help deal with aberrant discontinuities in the highlights (introduced by some sensor/stacking algorithm combinations). For your dataset, you could try increasing this from the default 12-bit to 13-bit or higher and see if the stars are more to your liking?

I'll give that a try, thanks for the suggestion.

Thank you Ivo and Ron for looking at this for me. I really appreciate the input and the sanity checking.

Alex

[admin]

I would consider the "some" qualifier to be somewhat optimistic... There is very little original detail left

Would you mind showing me what you mean? That Siril image is literally the only image I've processed using that software, and while I may or may not stick to it, I'd like to understand what you're referring to so I can avoid it in the future.

While it's hard to critique such a small image, even at that resolution there are obvious areas of "tampering" (besides the copious missing stars that have been replaced by synthesized background);

I cannot, for example, replicate lots of the detail around the Bok globules (dark areas), for example here;

2025-01-03_10-46.png (108.05 KiB) Viewed 3077 times

Bok globules tend to attenuate ionized radiation, not excite it (except at their exact boundaries, giving rise to the BRCs / "Bright_rimmed Clouds"). It appears something (that "something" likely being Starnet) has converted noise and stars into nearby structures, such as this new "arc" feature...

2025-01-03_10-47.png (2.27 KiB) Viewed 3077 times

...has cut continuity between two - in reality - connected cloud filaments...

2025-01-03_10-47b.png (3.47 KiB) Viewed 3077 times

...has created new distant galaxies(?) out of colocated stars...

2025-01-03_10-48.png (3.39 KiB) Viewed 3077 times

...and is inventing all sorts of swirls, stringy bits and shock waves that have no basis in reality...

2025-01-03_10-49.png (10.28 KiB) Viewed 3077 times

Pleasing/plausible detail? Sure. Reality? Not so much. It's possible that some of this is exacerbated by the JPEG compression, but certainly not all of it.
FWIW, this is what an "honest" StarTools processing yields for the region;

final_Rosette_L_crop_nr200.png (288.63 KiB) Viewed 3077 times

It makes it quite clear how various features (noise, stars) have been reinterpreted and synthesized.

And compare both to an Ha image excerpt (full image by M. Figenwald) which show use what near-"starless" would truly look like at a much higher resolution.

ha.png (190.99 KiB) Viewed 3077 times

Those things may all be true, but every image I've processed with StarTools, over years has the same look to it (with AutoDev/OptiDev). Regardless of exposure time, sub length or even scope. The only things the same are the camera and filters. This is the first image after having cleaned the filters and nothing has changed.

Consistency is a feature, not a bug. However, since you are reasonably far down the process of elimination list, for finding out why your stellar profiles "look the way they look", the camera window or filter coatings could be of influence. Have you imaged without filters?

These were 30 second exposures for LRGB which was already giving around 20 stars clipping, I don't think I could go much longer.

That is *very* short (unless you image from extremely light polluted skies). Are you using some sort of extremely high gain? That would explain
potential quantization and very high noise despite long total exposure time... You should always aim for unity gain where one detected photon is counted as one data number...

[ajh499]

Thanks Ivo, that's a really enlightening look at what Starnet gets up to.

the camera window or filter coatings could be of influence. Have you imaged without filters?

That is something that I'm wondering. I've not tried imaging without filters, I'll have to give it a go if I ever get a clear night to try it out

That is *very* short (unless you image from extremely light polluted skies). Are you using some sort of extremely high gain? That would explain
potential quantization and very high noise despite long total exposure time... You should always aim for unity gain where one detected photon is counted as one data number...

No, not extremely light poluted (Between Bortle 4 and 5, I think), or crazy gain. 1/2 unity, I think. It was ages ago that I set it and just left it. The 30 seconds for RGB was a mistake, I'd usually use 60 seconds for colour but I swear that the UI of KStars is set up to cause mistakes to happen

I used to use longer exposure lengths but have reduced them over time, I'll have a look at increasing them and the gain again.

Do you have a feel for a limit on how many stars/pixels can be allowed to clip? These luminance frames were reporting about 300-400 pixels or ~20 stars clipping depending on the software and the measure that it uses.

[admin]

No, not extremely light poluted (Between Bortle 4 and 5, I think), or crazy gain. 1/2 unity, I think. It was ages ago that I set it and just left it. The 30 seconds for RGB was a mistake, I'd usually use 60 seconds for colour but I swear that the UI of KStars is set up to cause mistakes to happen

I used to use longer exposure lengths but have reduced them over time, I'll have a look at increasing them and the gain again.

Do you have a feel for a limit on how many stars/pixels can be allowed to clip? These luminance frames were reporting about 300-400 pixels or ~20 stars clipping depending on the software and the measure that it uses.

The gain (or ISO) should be set to the value that corresponds to perfect 1:1 counting of electrons as pixel brightness increases.
If you are using an OSC, this usually corresponds to 1.0, if using, say, a DSLR it gets a bit tricker (as the equivalent ISO values that achieve this vary per manufacturer and model).

Normally, under reasonably dark skies, most instruments would capture 3 minute subs or more without issue, so being able to record only 30 seconds is rather sus, and I suspect something is artificially blowing out the pixel values (e.g. analog or digital gain).

You could use the old DSLRs histogram trick for determining best exposure times; acquire one sub, normalize it, stretch it with a 2.2 gamma (to mimic an sRGB conversion, which DSLRs do before showing you the histogram) and inspect its histogram. The peak (usually corresponding to the background) should be at around 1/3 from the left of the histogram, with the remaining 2/3rds containing your detail. If the peak sits closer to the left than that, you should be increasing your exposure times.

[dx_ron]

The gain (or ISO) should be set to the value that corresponds to perfect 1:1 counting of electrons as pixel brightness increases.

Is the reason for that to have the noise distribution be reasonably Gaussian (and does that refer to only read noise)? How important is that, compared to having less noise overall?

Many, possibly most, current amateur astrophotos are not captured at unity gain, because unity gain for the very common IMX571 sensor is reached only in a particularly low-gain mode that most people only use in special circumstances. The most commonly used mode is ~0.25 e/ADU, where the read noise is quite low (below 1e), while read noise at unity gain is ~2.5e.

Alex is using an IMX183, however, which is a quite different animal. Back when the 183 was new, the fairly knowledgeable people on CN were using primarily the gain Alex chose for broadband in order to allow longer exposures. I agree that 30s at gain 56 sounds rather short, and so you risk having the read noise be a significant fraction of the overall noise.

I think we each eventually get a feel for how many saturated pixels/stars to allow in a frame based on how the stretched image ends up - and it varies by target. I have gradually accepted more saturated stars. Not huge numbers, but I don't stress about them like I once did.

[ajh499]

Ivo, Ron

Yes, I'm using an ASI183MM-Pro mono camera.

I was under the impression that unity gain is pretty irrelevant. See the 3:50 mark in this video from Robin Glover, the Sharpcap author.
https://www.youtube.com/watch?v=ub1HjvlCJ5Y

When I first got the camera I used a spreadsheet developed by the people on CN to calculate the optimal sub exposure from measurements of my own subs. The estimator tool that has since been built into KStars also comes up with the same number of ~30secs @ gain 53 if we are attempting to swamp read noise by a factor of 5 or ~60 seconds for a factor of 10.
You can jump to the 50 second mark on this video for a table
https://www.youtube.com/watch?v=3RH93UvP358

Ivo, by the way, do you think it would be worth making your post looking at the AI artifacts on my Siril image a sticky post? It might be useful for others to have a look at.

Ron, thanks for your log file. I've had a look through it, you've applied modules in a slightly different order from the way I do, which seems to work a bit better, and you did more star reduction passes than I think I've ever tried. I haven't managed to replicate the effect you got with the stars though, you must have masked them much better than I did. I'll have to see if STReplay can get the masks you used from the log so I can try to see what you did.

I've never had any real luck shrinking stars after stretching. That was one of the reasons I wanted to separate them and stretch them less in the first place.

I think I have discovered one of my issues though - although my filters are supposed to be parfocal, they definately aren't, and if I don't refocus on filter changes I end up with a chromatic aberation issue that this data didn't have but a lot of my other data does. StarTools shows that aberration up badly, where other software hides it, but at least I know the cause now.

If I can just get rid of the coloured halo around my stars, I'd be much happier

Alex

[dx_ron]

Out of curiosity, I downloaded a linear fits from the CN "Process my data" thread. The image as processed by the photographer in PI was an astrobin Top Pick, I believe. With a simple ST workflow: Wipe (using *very* minimal settings, as the data were collected under extremely dark skies), Optidev, SVD, Color; the medium-to-bright stars have the familiar StarTools look:

stars.jpg (68.51 KiB) Viewed 2324 times

I downloaded a fairly high-quality jpg from astrobin, and scaled to the same screen size as my simple ST version. This is a tight crop of the brightest star in the image:

star.jpg (66.01 KiB) Viewed 2324 times

The blue color "halo" extends farther in the ST version, though it could be tamed in Shrink with un-glow.
I assume (but have not asked) that the photographer used BlurXT to "deconvolve". The fully saturated core is much larger in the PI version, but the current fashion in how stars "should" look favors the PI/BXT look.

[ajh499]

Ron

Thanks for trying that. I had been meaning to do the same, but hadn't had a chance to find any suitable data to test with.

As you say, StarTools stars have a distinctive look that you don't see elsewhere. I know we are used to seeing brighter stars as larger and that is what we now view as what a star is meant to look like. I suppose that dates from the days of film photography, regardless of today's software and algorithms that emulate the look.

In a way I find the very bright stars less of a problem than the mid-to-bright ones. A very bright star is a bit overpowering regardless of whether it is "blobby" or it has a tight core and an extended "halo".
The mid-to-bright ones I think are the ones that spoil StarTools images for me. The extended halo makes them look either "pasted on" or hazy.

I guess it's not a deconvolution issue, the large halo is there regardless of how tight the core is and doesn't change much regardless of settings.

The issue has to be to do with the way that OptiDev stretches the brightness around those mid-to-bright stars. I've tried playing with the ROI and other settings but never had much luck with taming the halo and still pulling out nebulosity. I have also tried using Shrink to tame the halo, but again never been satisfied with the result, especially with any nebulosity behind the stars.

That was one of the reasons for trying Siril, by processing stars separately I could stretch them much less and not have to try to tame brightened stars after the stretch, I could just keep them under control in the first place. I've tried similar in StarTools, but never found a way to do it that doesn't leave even worse artifacts behind.

Alex