Is there a version of SGP that offers debayering for subs? Or maybe I missed an option somewhere?
C’mon SGP authors and owners. I don’t know if you visit forums such as CN but there are more and more people going to other imaging alternatives because they see their request for features are just frowned upon. Debayering is one of them.
Helen this looks wonderful, is this a plug-in? If yes, can you share it ?
Anxiously waiting you reply 
Unfortunately they API not so rich and I cannot implement plugin for this. I have experience in software development, so I managed to change application by myself. I’ve added debayering and star center mode for preview windows; fixed some crashes related to switches cache and profiles; made app as single EXE file. But you should understand that I cannot share this mod as I have no rights to do so 
PS: I’ve asked SGP owners to get access to repository to integrate my code for debayering into they app, but they refused this idea.
It’s sad that they won’t accept help get debayring in SGP.
Without fixing bugs and adding new features the advanced users will move on to other software and leaving the SGP forum which will take away a lof of the support for new members too.
In the end this will kill SGP
I cannot understand how it is possible not to accept such an addition, I believe the developers of SGP have now lost that initial spirit which, in the face of economic affairs, tends to fade. Thanks anyway Helen for sharing with us the demonstration that this is feasible.
For info, this is not a new request. It occurs regularly. Just because it could be done is not a reason that it should:
There is a debate among users as to whether this is useful or not. On the one hand, SGP is as an image acquisition application, not an EAA application, which should not be burdened with unnecessary clutter and diluted development resources. On the other hand, there are more users with CFA cameras, who want to see a color image after each exposure.
I use mono and CFA cameras. In practice, light pollution and the very dim nature of nebulosity make it of limited value for all but the brightest deep sky objects. For instance, judging exposure on screen is a risky business and it is better to use data readouts.
For framing purposes, it is more reliable to use the framing wizard with a nice clear DSS image. Consider that many monochrome NB images, especially S2 or O3 and even with a 20-min exposure produce an image whose nebulosity is barely visible in a stretched state. A color image would be a red noisy mush.
1 Like
I’ve never understood what benefit there is to debayering inside of SGP. We would never save a debayered image so you’d still need to post process it. Most of the time a CFA image will have pretty significant color gradients and be fairly off color anyways. This generally requires background calibration and careful color calibration to correct. So in SGP you’d basically be left with an off color image that is really no more representative of the object than a grayscale image. Helen’s “very blue and green” images highlight this above. So just for curiosity sake…what does a non-normalized off color RGB image provide that a grayscale does not? SGP’s focus is on acquisition and not processing … would you throw away or re-frame based on a color image where you would not a grayscale?
I could also make the argument that when your eyes are dark adapted that they’re much more sensitive to luminosity than color, so there’s at least one benefit to grayscale. And if you’re using a red film over your laptop at a dark site then you could end up removing features completely from a debayered image where you would leave those features intact if the image were grayscale.
Jared
You still don’t get it… That is why you will end up with SGP replaced by NINA or Voyager by everyone. User requests is more important than you think. And for color preview - it is pretty usable, because you can more or less see what you get. For example, it let me see that subexposure contains enough OIII too, not only H-a. So I always prefer color preview in SGP and never even think to turn it back to grayscale. I understand that this feature completely useless for people with mono sensors, but if someone has OSC camera, then 99% that this person will prefer to have color previews.
I second what Helen said. As soon as the version of SGP I have doesn’t support a new piece of gear I buy, I am switching to NINA.
And since Jared brought the topic of dark adaptation, this is always completely shot when using SGP as it offers no dark interface, unless this was added in a more recent version. When I am out in the field, as soon as I check on things with SGP, my dark adaptation is shot.
To come back to the debayering topic. Since my dark adaptation is gone all night long, I would prefer seeing my subs with some colors than in a gray scale.
I am using OSC cameras exclusively. In my view, each of the arguments that Jared brought forward are absolutely correct. I, for one didn’t miss debayering in SGP so far and I never will.
A different feature would be much more appreciated by me, and I don’t understand why not more users of OSC cameras are demanding it: the Bayer/mosaic pattern in the FITS header (keyword BAYERPAT). Thereby the BAYERPAT value could be used in the preprocessing, rendering its manual input unnecessary. This was put as a feature request in July 2019, and we don’t have it in May 2021 - what a pity.
Bernd
we are discussing a feature that is not impactful, I want it and activate it, I don’t want it and deactivate it. simpler than that what else is there to discuss.
Common Jared, surprise us.
I get it completely. There is a balance to be struck between usability and features. No application gets it right. Every one of us thinks that the feature we need is a must-have for an application to include and shame on the developer if they don’t add it in.
Well - at the same time, just peruse the forum for this or any other imaging application and see the number of users who easily get confused with their imaging application as it stands, make basic mistakes (in the minds of more experienced users) and are completely non-plussed by all the myriad controls, settings and logical decisions to be made.
Some of us are engineers, (hardware or software) and we are perhaps hard-wired to work around the ins and outs of an application. Others are completely struggling and adding features just makes their lives more complicated.
There is a simple solution, if you want SGP to be like NINA or Voyager, use NINA or Voyager. They still experience the same issues caused by ASCOM driver behavior and it is wishful thinking to believe their own drivers are faultless.
For the power-users, (for SGP or other apps) there is perhaps a better approach, in which the API is sufficient to allow customized operation, without complicating the GUI further. NINA is doing just that with its plugins - but then the astrophotographer has to write their own scripts- with the danger of astrophotography being an elitist pursuit. This is where TSX with Orchestrate and MDL went with the budget-priced ACP.
As engineers, we should also be aware of the need for a clear direction, not design by committee. A certain other application has IMHO, already reached a critical mass of complexity and is potentially alienating some of its customers. The developers express clear views on which customer wants they will or will not implement, rejecting some, which to me are quite reasonable.