When github.com/rlancaste/stellarsolver.git is used, does it pull version 2.0? Or do I need something to pull that release tag?

Although your build script should have taken care of it, I've just compiled Stellarsolver all on its own. If KStars complete's its build after this, I'll bring this issue to the AstroPi3 script thread. At this moment, it appears to be going well.

Edit: It all compiled successfully this time. Thank you.

Since the introduction of Stellarsolver, all the star related operations are delegated to this library. Now I'm facing an autofocusing problem and I think that I can try to track back a fix for it into Stellarsolver... but I'm nor sure, so, here I'm asking for advice.

First, the problem. I've a fast newtonian (150/600, so f4) that has a very shallow CFZ. I've put a coma corrector on it (TS-Optics GPU). And this corrector is introducing chromatic aberration. I'm using a OSC (the ASI533MC), so the images that I capture has the bayer matrix pattern over it. Now, when I use the autofocus module with the ZWO EAF it works fine... only for the red pixels.

I suspect that Stellarsolve is using only R channel to compute HFR and then the autofocus algorithm is focusing on the red extreme of the spectrum. The problem here is that the chromatic aberration shift the focus and I end with a G channel slightly unfocused and a B channel completly unfocused.

You can see the problem if you look at the three channels (show in order RGB)



They are extracted from one single shot. The one chosen by the autofocus module seems to be the first one (R). You can see, that forgiving about the remaining miss-collimation, the R channel has an acceptable focus that deteriorate to G and it's almost completely unusable on B.

My proposal is to change the channel used on OSC images for all the quick computation to G. This way if you have chromatic aberration you will have a perfect focus on G (where you have half of the pixels) and then, then same amount of error for R and B, but overal the image will be on better focus.

I believe this a relic of the KStars code that existed prior to StellarSolver. So when I moved all the plate solving and star extraction code into the StellarSolver library to make KStars simpler and work out all the issues we had with plate solving and star extraction, some of the code was fine the way it was and I left it alone when I copied it. The default for Plate solving and HFR has always been just the red channel for an RGB image. I don't know why this is since it predated my changes. It has been that way sine I started working on this stuff. You have a good point in that the Green channel might be more appropriate for telescopes like refractors and SCTs. Let me make sure there was not a reason the red channel was used before we change this though. Also it might be good to make it an option so that people can choose which one they want to do. I will check into this.

Rob, no regrets, don't worry. You have done a wonderful work with the isolation of all this code inside StellarSolve. Perhaps, this change is one of the most important things on Ekos in recent years,

I've suspected that this was in this way for historical reasons as you have confirmed. Obviously a change like this should be parametrised, I don't want to change one adhoc criteria for other one, so a way to choose the channel used to compute centroids and HFR will be the way to go.

Please, if you find any reason (apart for the historic one) to support the channel R over the other 2, share with us.

King regards.

So the plot thickens. I had remembered that KStars was sometimes just using the red channel for certain operations, but it looks like it is sending an RGB buffer to StellarSolver for this operation. Then when I looked at the code again in StellarSolver, the image buffer in the SEP call is in fact RGB at that point as far as I know (though possibly KStars could send it a monochromatic buffer at some point, but I didn't see that). But even though it could be RGB, I don't think SEP is actually using the G or the B part. I found this note on the SExtractor website:

For images with NAXIS>2, only the first data-plane is loaded. In SExtractor, as in all similar programs, FITS axis #1 is traditionally referred to as the x axis, and FITS axis #2 as the y axis.

So from this I take it to mean that SEP would just ignore the fact that there are other channels and just use the first region it encounters in the file which is the R channel in a FITS file. I want to check it out and actually verify that all of this is true first, but I thought I would share what I found. If this is in fact true, then we could certainly change StellarSolver so that it has the ability to send to SEP whichever channel you want or maybe an average or sum of all the channels. For Star Detection for plate solving, I wouldn't think it would matter at all, but for Photometry calculations, this is pretty important. Also as you pointed out, for Focusing it could be useful if you have a Refractor to use the Green channel insteadl.

Note that none of this will affect folks using single channel fits files which many scientists use for their data, this only affects those using an RGB fits file or an OSC camera. So maybe that is why it hasn't really come up more often with SEP or SExtractor.

Thank you for sharing all this info. It's fascinating how the history and the play between profesional and amateurs astronomer has mixed on this issue. As you have pointed on, for professional or "serious" amateurs there is no problem, because they always use monochromatic sensors. But for the low level amateurs, with DSRL or OSC and imperfect optics, this issue could mark the difference between good and bad focus experience.

For photometry, as you have commented, perhaps the best approach is going one step earlier: do not debayer the image, but extract the CFA components for each colour. It has been done with OSC cameras for a long time. For example, when I use Tycho Tracker to perform astrometry or photometry on asteroids, it automatically extracts only the G pixels for the CFA and average them. It produces a 2x2 binned image that discards R and B pixels. This way, the photometry is more consistent.

Prior to Tycho use, I've been extracting each CFA components using SiriL to process images acquired with L-eXtreme filter: CFA red pixels have the Ha signal and the other 3 CFA components averaged, have the [OIII] signal

But as currently you are receiving a RGB buffer from Ekos, I assume that debayer is something that Ekos is performing on its own, so for now we can restrict to R, G and B channels

Regards

First though we need to confirm these suspicions. So I will try a couple of experiments and see if it is true

Hi Rob,

How are those experiments progressing?. Did you manage to advance on this issue?

Regards

Yes I made 3 images in Pixinsight. I took a monochrome image of stars and in each of the 3 images, I put the stars in one of the color channels and left the other two completely blank. As I suspected, when the stars were in the red channel, star extraction worked perfectly and so did plate solving. When it was in the other two channels it did not. The reason is because SEP seems to ignore the other channels as I suspected. I haven’t had time to do more, but I think it should not be too hard to extract whatever channel is desired from an rgb image, put just that channel in a monochrome buffer and then feed that to SEP instead of the rgb buffer

I have made some significant progress in addressing your issue. I made a new branch where I am playing with this. Here is what I have done:

github.com/rlancaste/stellarsolver/tree/colorChannels

If there is an RGB image, it will be possible to select which color channel to use for Star Extraction or Solving for all the methods of doing those. For SEP, I was able to just send it the part of the buffer I want it to look at. For External Solvers, this will actually be helpful since we can just export the part of the buffer we want to solve instead of the whole RGB image. That will reduce the writing of larger files. It also allowed me to simplify the code in several places because now I know that SEP and the solvers are actually ignoring any other channels except the first one you give them, so when I am down sampling and exporting, there is no need to include the other channels, just the one we want it to use.

As requested, when given an RGB image, the default channel to use will be Green instead of Red, which is what seems to be the default everywhere else. I agree though most telescopes will be best corrected in Green light. For reflectors it doesn't matter, but for refractors it really does.

One benefit to this is that when I make the photometry tool I want to make with StellarSolver, I will now have the ability to get the magnitude separately in each color channel which is very useful.

Good to know about your progress. Very encouraging indeed . I've been looking at the sources, so now I have more questions:

* I like the approach to use only monochromatic images. I've seen that you have limited the code, by now, to the individual channels (ColorChannel enum and the new m_ColorChannel property), but with the current the implementation it will be also posible to change the InternalExtractorSolver::getFloatBuffer and ExternalExtractorSolver::saveAsFITS to easily handle the "average" mode (in which the three color channels are averaged to generate a "Luminosity" channel). It's still not clear for me which approach will be the best: use the green channel or compute a synthetic luminosity one and work with it, and it's encouraging to see that the current implementation will allow to experiment with this also.

* How is StellarSolver linked with KStars?. Dynamically or statically? As I'm an Astroberry user, I've setup a Raspberry Pi to build KStars / StellarSolver. But it's a real pain to build KStars each time (it takes multiple hours)... do you have any trick to accelerate build times?

Thanks a lot for all the work on this issue!