Not getting the results I'd like with LHaRGB

Questions and answers about processing in StarTools and how to accomplish certain tasks.
Stefan B
Posts: 422
Joined: Sat Oct 31, 2020 8:59 pm

Re: Not getting the results I'd like with LHaRGB

Post by Stefan B »

Hi Brendan,
BrendanC wrote: Wed Apr 27, 2022 8:39 am @Stefan B - when you say 'That's a huge issue', are you talking about my data specifically, or just generally?
In general. My experience is limited but I guess it's a general problem. Galaxies have a bright core that's emitting light in the Ha line but which does not come from Ha, it's just part of the contiuous emission of stars which we do not want to include but which of course passes the filter and hits the sensor. This red light from the cores may even be brighter than the HII regions in the spiral arms. So the question is how to isolate the signal of the HII regions from the light coming from broadband emitters. One way appears to be continuum subtraction. Maybe there's also a way in the ST workflow.

Sorry for this slight off topic in your thread ;)

Regards
Stefan
BrendanC
Posts: 113
Joined: Sun May 17, 2020 12:23 pm

Re: Not getting the results I'd like with LHaRGB

Post by BrendanC »

Don't apologise! I'm learning a lot here. :)
Not so much boldly going as randomly stumbling where plenty of people have been before
Mike in Rancho
Posts: 1141
Joined: Sun Jun 20, 2021 10:05 pm
Location: Alta Loma, CA

Re: Not getting the results I'd like with LHaRGB

Post by Mike in Rancho »

Great discussion everyone! And Brendan thanks again for providing some interesting HaLRGB sets to kick it off. :thumbsup:

I too am in "new camera" learning mode and am interested in these techniques and pitfalls. I'd like to try out some NBAccent on the famous M81-82 myself, though will add even more complexities since I don't yet have an Ha filter. Hmmm. :think:

Brendan let me see if I can attach my log file here. If it fails I will make it a drive link. Full log so you can see and deal with any masks if interested. Though really they are all auto-masks except the custom undo buffer, which I wasn't super careful here in creating for just these test purposes. That said, you can see how some of the workflow progressed since the log writes out mask "changes" -- i.e. before Color the first mask code is just the star mask, which I hit the sample button on, and the second mask is after I did a clear-invert-keep.

[yeah neither log nor txt ended up a supported filetype for ST attachment, so here's a link: https://drive.google.com/file/d/1T4_GQx ... sp=sharing ]

Slightly off-topic myself, it would be great to have a stand-alone mask code converter on the side in lieu of going on the internet. I presume one must be incorporated into SVTReplay? If so, I wonder if we could get (beg) Guy to create one to say, spit out a jpeg from a mask code we copy from a log? :?:

Stefan interesting point on the narrowband "continuous source" matter. Indeed we have (I think) discussed that more often in terms of OIII, and in particular with a wide G+B passband like an L-eNhance, as that gets picked up so much from stars being stronger in that spectral subset. Hence so many teal stars in an HOO except for the very reddest. But indeed I kept having to cancel back to screen one of NBAccent if I ended up with a M81 core little tomato, and sometimes giant tomato. :lol: I can't remember how I ended up with one that mostly blended in. I also may have made it harder on myself as I had added a little more red bias reduce in Color for my rendition.

Good point also I think on the fact that the NBAccent file misses out on some of the matching enhancements and alterations that clarify the detail along the way, which also has been discussed before regarding which modules are actually included in the multi-file "parallel processing."

I will have to read up on workflow placement of NBAccent in the docs and test out how amenable things are to switching up relation to SS.
BrendanC
Posts: 113
Joined: Sun May 17, 2020 12:23 pm

Re: Not getting the results I'd like with LHaRGB

Post by BrendanC »

Thanks again Mike, the log file downloaded fine, and I'll be going through it sometime soon.

I'm now struggling with another LHaRGB data set, this time for M101! But I don't want to keep running here sobbing and asking people here to fix things for me, so I'm going to have a real go at this one. I've been combing through the subs and among the various sat trails have found a couple of anomalies: one, a huge dirty great plane flying through the FOV and obliterating the image; another, a curious glint that only appears for about 15 minutes in one corner, then disappears, which could be any of a number of possible reflections. I'm also working on the theory that I'm getting more light pollution with the increased sensitivity of this camera than I did with my old DSLR, so I'll be reducing my exposure duration, but I'm also looking into using APP's light pollution tool to see whether that plays nicely with StarTools and helps with all this. I know this will probably cause Ivo's head to pop, but it's worth experimenting a bit.

If I still can't wrestle it to the ground, I'll share the data here.
Not so much boldly going as randomly stumbling where plenty of people have been before
User avatar
admin
Site Admin
Posts: 3367
Joined: Thu Dec 02, 2010 10:51 pm
Location: Melbourne
Contact:

Re: Not getting the results I'd like with LHaRGB

Post by admin »

Stefan B wrote: Wed Apr 27, 2022 8:06 am That's a huge issue IMHO. In my M81/M82 I unceremoniously masked M81's core and used the undo layering, since otherwise it would have looked ridiculous. Certainly not documentary...

I read about the process of continuum subtraction for cases like this. There, you subtract the red signal from the Ha signal so you aim to retain all those HII regions in the arms but get rid of the signal in the Ha line which comes from continuum emission instead of line emission. As far as I understood you use stretched data for this. But the amount of stretching isn't objective, especially when gamma etc. is manipulated (or some parts of DSOs are highlighted or tamed by HDR in (L)RGB but not in Ha).

@admin Ivo, is there a possibility in ST to do something similar to continuum subtraction? Or to avoid overly red galaxy cores?
Continuum subtraction is sort of what the NB Accent module does. Though it is really more accurate to say that the NBAccent module performs conditional continuum synthesis and replacement.

The NBAccent's premise is based on two assumptions;
  1. the NB accent data represents a continuum whose RGB manifestation may be custom defined (for example, red channel only or Balmer series across multiple channels in the case of Ha)
  2. the visual spectrum data contains a measure of the same signal already and has been color balanced correctly
When evaluating a pixel;
  • the NB accent data is stretched (AutoDev is chosen here as it guarantees the best possible dynamic range use, maximizing detail). Visual spectrum accuracy is taking a backseat to show exaggerated detail. As you point out the stretches are different, but mostly the image would not look much different if we didn't exaggerate NB detail!
  • the stretched signal is translated to the target continuum's RGB representation
  • the new value for the pixel (per channel), is the value of the pixel that is largest (original or accented)
Further constraints (or boosts) may be imposed on the accent signal. before evaluation For example, the removal of signal beyond a specific structure size, specifying a noise floor, or artifically boosting the signal linearly or non-linearly.

The fundamental workings of the continuum replacement outlined above tends to yield useful results, as long as the visual spectrum data truly already incorporates a measure of the NB accent. The emissions of other parts of the spectrum in the visual spectrum image, should typically overwhelm any accent signal (even when moderately boosted), effectively protecting star cores and galaxy cores from being touched.
Mike in Rancho wrote: Wed Apr 27, 2022 6:56 am I thought about running another SS, perhaps Isolate, afterwards, but just bumped the denoise some instead. I wonder if SS might be best off after NBAccent overall?
You can absolutely use SS with NB accents in place, but the main reasoning for not using it after, is that NB accents were added in a more arbitrary manner (for example, from the perspective of the Tracking code, such accents just "materialize" out of nothing). Having an algorithm build on something that has no "history" and was added in an arbitrary manner will make any derivatives arbitrary as well. Some modules are able to completely ignore (e.g. compensate for) the accents, but SS is not one of those modules (it's a very superficial / artistic / WYSIWYG type of module).
BrendanC wrote: Wed Apr 27, 2022 8:39 am @admin - great suggestion about vignetting in Wipe, but in that case, does this mean my subs are displaying excess vignetting?
Indeed - this is just an AutoDev of your luminance set, nothing else done to it, except a crop;
Selection_744.jpg
Selection_744.jpg (431.15 KiB) Viewed 2308 times
...which is also the reason why a basic sample-setting algorithm as found in APP or Siril will not yield correct results in a technical sense; the bulk of the "gradients" here appear to be caused by an error in division (flats), rather than subtraction/addition (light pollution). Wipe models these things separately, as they are separate issues at their core, requiring different signal processing and math to correct for.

Manual sample setting based algorithms may give you quick fix if not scrutinised too severely, but it is much closer to arbitrary "doctoring" (using the user as an arbiter of what is "background" and what isn't, rather than an objective algorithm) and is particularly destructive to datasets with "important" faint signal (e.g. the IFN in this case of this dataset, though I don't think it is deep enough yet for good IFN signal to poke through).

EDIT: I should also say that the first 1.9 alpha will come with some changes/upgrades to the NBAccent module, which are already in place. Unfortunately, I can't give an ETA on this just yet, as there is a lot to be done still on other parts.
Ivo Jager
StarTools creator and astronomy enthusiast
BrendanC
Posts: 113
Joined: Sun May 17, 2020 12:23 pm

Re: Not getting the results I'd like with LHaRGB

Post by BrendanC »

So, @admin when you say 'the bulk of the "gradients" here appear to be caused by an error in division (flats)' - do you think this is a hardware issue (how I take my flats) or software (how APP stacks them)?
Not so much boldly going as randomly stumbling where plenty of people have been before
User avatar
admin
Site Admin
Posts: 3367
Joined: Thu Dec 02, 2010 10:51 pm
Location: Melbourne
Contact:

Re: Not getting the results I'd like with LHaRGB

Post by admin »

BrendanC wrote: Thu Apr 28, 2022 8:49 am So, @admin when you say 'the bulk of the "gradients" here appear to be caused by an error in division (flats)' - do you think this is a hardware issue (how I take my flats) or software (how APP stacks them)?
This appears - to me - to be just a simple flats issue. It's not a massive discrepancy, but annoying enough to cause uneven lighting in all your subframes. Definitely not a software issue IMO.
Ivo Jager
StarTools creator and astronomy enthusiast
BrendanC
Posts: 113
Joined: Sun May 17, 2020 12:23 pm

Re: Not getting the results I'd like with LHaRGB

Post by BrendanC »

Great, thanks for letting me know Ivo. I'll have a think!
Not so much boldly going as randomly stumbling where plenty of people have been before
BrendanC
Posts: 113
Joined: Sun May 17, 2020 12:23 pm

Re: Not getting the results I'd like with LHaRGB

Post by BrendanC »

Right, I'm starting to genuinely worry now about my ability to use this ASI1600. I've been using StarTools for two years with my modded DSLR and thought it would be a fairly easy move to mono, but I just cannot seem to get the hang of it. Somewhere along the line I'm doing something(s) wrong, but I just don't know what, or where.

So, I'm now struggling with my data for M101. I've been through all the subs and removed anything that didn't look right, to give my stacking in APP and then processing in StarTools the best possible chance. Here's what I get after several hours and multiple attempts:
Honeyview_M101.jpg
Honeyview_M101.jpg (414.6 KiB) Viewed 2302 times
To my eye, the stars are bloated, there's too much noise, and the background has gradients that I cannot fix. From what Ivo says above, this could be my flats, but I've tried several different settings to get flats, and have had them looked at by other people with similar setups who say they seem fine, so I'm not sure where to go from here.

Anyway, the data is what it is, and I'd like to make this work if possible.

If I zoom in on the just the galaxy, to try and lose the gradients in the starfield around it, I get this:
Honeyview_big nr (2).jpg
Honeyview_big nr (2).jpg (298.05 KiB) Viewed 2302 times
Now, I know I'm getting 'Pacman stars' and this is because the focus tube of my 130PDS intrudes into the light path, which I'm going to fix by chopping it (yes, really - I've lived with it too long and this is the only viable fix). But again, I just think I should be getting more detail, less noise. Or am I being too picky?

(Another problem btw is that these images have to be reduced so much to view in this forum, so these issues aren't quite as visible here).

If anyone (hint: @Mike in Rancho) would like to have a play around with this data, it's here: https://1drv.ms/u/s!AqovBuVZMwj3k4poplh ... A?e=IhAJQs

I've added in the number of seconds exposure to the filenames eg M101-Blue 2160s.fits means the blue channel has 2,160 seconds of exposure.

Thanks, Brendan
Not so much boldly going as randomly stumbling where plenty of people have been before
User avatar
admin
Site Admin
Posts: 3367
Joined: Thu Dec 02, 2010 10:51 pm
Location: Melbourne
Contact:

Re: Not getting the results I'd like with LHaRGB

Post by admin »

Hi Brendan,

I had quick peek last night on my laptop, and it definitely appears the big thing letting you down right now is your flats. They seem to introduce all sorts of swirls en areas of unevenness. :(

Given this is a small-ish object on an otherwise "uninteresting" background devoid of nebulosity, it's definitely possible to nuke the swirls by using the Vignetting preset + bumping up the Aggressiveness. You will get a nice, even background without too much hassle or loss of detail (you can mask out the galaxy for good measure to be safe).

That said, you shouldn't have to be doing this and priority #1 should be to figure out how the swirls and uneven lighting is making it into your final stack. I'm 99.9% convinced new/better flats are needed.
Ivo Jager
StarTools creator and astronomy enthusiast
Post Reply