Want unlinked stretch

[dghent]

Hey Robin

I realize that this likely isn't your current area of focus right now, but I just wanted to toss this suggestion into the bucket since, AFAICT, there hasn't been a mention of it before:

It would be quite handy to have the option to perform an unlinked stretch, at least when it comes to live stacks of OSC/color sensors. I realize this has the potential to balloon memory usage, especially with high pixel-count sensors, so its usefulness might be the domain of 64bit sharpcap in those cases.

I bring this up because I'm trying to make Live Stacking a normal part of my club's EAA-based outreach, which uses an ASI071MC-Pro on a large refractor. SharpCap is normally used to show the audience what the telescope is pointed at, but it traditionally hasn't been used in conjunction with Live Stacking. I'm looking to make Live Stacking a normal part for the club's telescope operators to use when doing public outreach, and unlinked stretch would be an "ez button" for the operator to get a pleasing and balanced result. Otherwise, a regular stretch produces the typical green tint to the image that then needs to be manually adjusted out.

TIA and keep up the great work

[admin]

Hi,

just to be sure I understand this correctly, this would stretch each channel individually, rather than them all having the same stretch, yes?

I think the biggest problem here is not making a 'magic' button to create/apply this stretch, its working out a way to dispay the results and allow the user to interact with/adjust the unlinked stretch settings.

cheers,

Robin

[dghent]

just to be sure I understand this correctly, this would stretch each channel individually, rather than them all having the same stretch, yes?

Correct. The problem with all channels being linked to the same transform value is that a debayered RGGB image assumes a green cast due to the overrepresentation of green pixels, as the histogram target is first reached by them. Stretching each color channel individually to the target histogram value will "normalize" the combined output, giving a more natural result without green overpowering red and blue and thus no green cast to the image.

Programmatically, the downside is that you're stretching each channel individually instead of the bayered source and its single channel. This can cause memory issues with high pixel count sensors with 32bit processes and on memory-constrained systems. We've made this the default in NINA now for OSC cameras because it's just what people expect to see when it comes to a debayered and stretched image. It can be turned off if it's too much for their system, though.

[admin]

Hi,

thanks for confirming - I'm still concerned about how this might work in the UI. Would an 'advanced' colour balance mode where you have a second set of colour balance sliders that are applied before the stretch help? You could use those sliders to normalize the green level down, then apply the same stretch to each channel.

cheers,

Robin

[turfpit]

An alternative approach might be to apply SCNR (as in Pixinsight) or Green Noise Removal (as in Siril) after the stretch? That is all I do in post processing with Siril.

Dave

[dghent]

thanks for confirming - I'm still concerned about how this might work in the UI. Would an 'advanced' colour balance mode where you have a second set of colour balance sliders that are applied before the stretch help? You could use those sliders to normalize the green level down, then apply the same stretch to each channel.

Eh, the point of unlinked stretch is to automagically get a stretched image where all color channels meet the histogram target, not just the green one. This avoids demanding that the user futz with channel balance sliders, a finicky experience that is exacerbated by the slider settings not persisting across sessions. Slider manipulation would still require continuous tweaks by the user over the course of the Live Stack session as the image's color cast changes due to the moon setting/rising, light pollution variance, etc. Providing an additional group of pre-stretch mixing controls would be confusing because other apps offer up as a simple boolean button (control-click the STF button in PixInsight, or on/off slider in NINA, for example) to turn unlinked stretch on.

I don't know how SharpCap goes about calculating the stretch transform and applying it under the covers, but you might be able to get that amount on a per-channel basis and adjust the color mixer sliders appropriately using those values instead of 0db/1.00x. It's not clear (to me at least) whether the current color mixer sliders affect the image pre- or post-stretch, anyhow.

[admin]

Sorry, my mistake. I had temporarily forgotten that the colour balance settings are currently applied *BEFORE* the stretch, which means that they are in theory able to adjust for varying channel sensitivity. On the other hand if you have both colour cast in the sky glow *and* a sensor that needs adjustment then there is an issue as I don't think there is enough adjustment available to correct both.

I will consider this further - I still think separate stretches introduces too much complexity (both from a conceptual point and in the UI).

cheers,

Robin

[dghent]

Hi Robin, Apologies for resurrecting this thread; I wanted to avoid making a duplicate on the same topic.

I wanted to re-raise this as a really highly desired feature, and I thought that I would add some more purpose/reason context to help convey why this would make life easier for us. We use SharpCap at our observatory during my club's monthly and special event star parties, so the "us" I'm referring to are myself and any of the club's telescope operators, all of whom vary in their imaging and image processing skillsets.

In our setup, SharpCap is driving an OSC camera (ASI6200MC) with filter wheel and mount control is shared between SharpCap and Stellarium. SharpCap's screen is put up on a large 65" OLED TV in the viewing area next to the telescope. What we do is slew the telescope to a target and start live stacking it in SharpCap, with exposure times for a DSO target ranging from a few seconds to no more than 1 minute in length. The exposure times are kept short so that we get something presentable up on the display for the audience in short order as no one wants the audience to spend minutes looking at a blank screen while the first image exposes. Once that is sorted, we interpret the object for the audience, explaining the science behind it and answering their questions. While we are doing that, the object comes into more and more detail on the screen as SharpCap live-stacks frames which allows us to turn to the screen and point out the emerging dust lanes in galaxies, features of nebula, and so-on. This creates a lot of opportunities to teach the audience not just about the object itself but also basic astrophotography concepts. Audiences appear, at least, to really like this format of presentation. Once we've spent enough time talking about the object, we move to the next one where this process is repeated. I guess it's like EAA, but for an audience in a presentation kind of format.

But one of the primary detractors of this is having to manually futz with the stretch and levels of the of the image. There is often confusion between Live Stack's own stretch and histogram adjustments and the "main" histogram and stretch adjustments in the side bar. This generally devolves into the operator madly clicking around in both areas to get something that looks somewhat natural. But, all too often, they get frustrated as the end result is under or overstretched, colors get posterized, one of R, G, or B gets over-emphasized and, exasperated, they settle on something alright but certainly not great. Ultimately, this exercise becomes a distraction for the presenter and audience. It's as if all the fine-grained and seemingly duplicative controls conspire to get in the way.

Something more automatic and intuitive would be appreciated for a setting like this. Stretching each color channel individually (unlinked stretch) would be good start and minimal attention would be required to maintain a good view as more data gets stacked. The stretch for each channel would be automatically recalculated after a new frame is added. The stretch could be a midtone type, such as what is used in PixInsight. Some basic adjustments such as a stretch factor, saturation, and contrast can be supplied, and the confusion between the live stack's own and the "main/global" histogram adjustments be minimized. I have no actual implementation ideas to offer, but would be interested in hearing your thoughts on this.

[admin]

Hi,

I have actually been thinking about the issue of colour balance in deep sky stacking recently and have been prototyping some ideas to make the adjustment easier (and potentially a much better automatic adjustment). I'm still not convinced by the need to stretch the channels individually, but what I have come to realise is that the current, purely multiplicative colour balance adjustment is insufficient.

The problem is that almost invariably, there is a significant background brightness in amateur images - most of us image from light polluted environments, and we are talking about colour images here, so the ability of filters to cut out the light pollution is limited. Added to that background (which is probably coloured in some way) is the astronomical image that you want to see. If you adjust the colour balance so that blue pixels are multiplied by 1.05, then the entire pixel value is being multiplied, *including* the background - that tends to make the colour balance as seen in the image over-sensitive to the adjustments, and in some cases may make balancing adequately very difficult.

The area I am exploring is to add an additional, subtractive, background removal adjustment into live stacking - this allows the background to be largely removed, and since the adjustments are on a per-colour basis, this can deal with a coloured background too (providing it is relatively uniform across the image). The subtractive colour adjustment is applied first, then the current multiplicative adjustment, then the stretch.

In testing, this seems to work very well - although there are an extra set of adjustments to make first, the subsequent adjustment of colour is much easier, with less extreme sensitivity to the position of the colour balance sliders. The user interface still needs more work before this gets released to end users, and I also have a plan that *might* give a way to auto-set all 6 colour balance controls in a fairly robust automatic manner - this is still under exploration and investigation.

cheers,

Robin

[Gfischer]

Hi robin,
I have thought of the background subtraction based on current color balance. If I am looking at an over exposed area without background nebulous contributions the view should be a balanced gray. If the difference between the balance point of the curve is subtracted from observed value you can use those to create a mask to bring background to neutral. Of course depending on sky conditions in various areas this would change.
Like the previous poster stated as the livestack builds the histogram moves as the image brightens. This requires moving the black level to new peak position. To have the original histogram level settings track this by realigning the black level to peak and keeping distance between black and midtones constant for each new frame would be helpful.
Looking forward to your new ideas. Sc just keeps getting better