Want unlinked stretch

Got an idea for something that SharpCap should do? Share it here.
Forum rules
'+1' posts are welcome in this area of the forums to indicate your support for a particular feature suggestion. Suggestions that get the most +1's will be seriously considered for inclusion in future versions of SharpCap.
Post Reply
dghent
Posts: 10
Joined: Thu Mar 26, 2020 4:48 am

Want unlinked stretch

#1

Post by 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
User avatar
admin
Site Admin
Posts: 13177
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

Re: Want unlinked stretch

#2

Post by 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
Posts: 10
Joined: Thu Mar 26, 2020 4:48 am

Re: Want unlinked stretch

#3

Post by dghent »

admin wrote: Tue Apr 27, 2021 5:32 pm 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.
User avatar
admin
Site Admin
Posts: 13177
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

Re: Want unlinked stretch

#4

Post by 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
User avatar
turfpit
Posts: 1779
Joined: Mon Feb 13, 2017 8:13 pm
Location: UK
Contact:

Re: Want unlinked stretch

#5

Post by 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
Posts: 10
Joined: Thu Mar 26, 2020 4:48 am

Re: Want unlinked stretch

#6

Post by dghent »

admin wrote: Tue May 04, 2021 3:09 pm 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.
User avatar
admin
Site Admin
Posts: 13177
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

Re: Want unlinked stretch

#7

Post by 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
Post Reply