I suspect you mean my first thought, since what we really would want is nightly builds of KStars with rebuilt indi drivers inside, not nightly builds of indi outside of kstars.

or do you mean we would add a separate entry for INDI packages similar to the one shown above for kstars?

would that mean editing the KStars entry to something like this?

Thanks! I will check on it later to see if it works out.

Hi Hannah, thank you for your help! So then will cfitsio now build on the binary server again as a dylib so that linking will work with stellarsolver, or do we need to do something to make that happen? I think it ran on the binary factory a couple of hours ago and it is still linking to a static cfitsio according to the log.

Hi Hannah,

I guess another question I have is if cfitsio is a static library, would it have the zlib functions baked into it, or would there need to be a separate link to zlib if you link to cfitsio? On my system, cfitsio is a dynamic library and it is linked to zlib, so I don't have to link stellarsolver to zlib since cfitsio took care of that. But on the server, it doesn't seem to know the zlib functions.

Yes that was my initial conclusion since on my own computer cfitsio is a dynamic library and it works. But then my question is if the binary server and my computer are using the exact same craft recipe with the same options for cfitsio, why it would install as static on the binary server, but as dynamic on my computer? Unless the server is doing something different or somehow has different settings from craft that is downloaded to a computer?

"Rob, I actually disagree that you get the accurate saturation value. E.g. your technique wouldn't work for signed shorts or signed bytes or floating point where the range is 0 to 1.0, or for that matter, cameras where Indi would put out 0-4K values, etc. In the end, I think we'll need a user-supplied input for this, but all that, I think, should get worked out when you complete your Sextractor parameter integration, and this could be one of the parameters that we offer the user the ability to modify. Until then, I believe this will be good enough. It shouldn't do any harm, and it might improve the situation over the current system. I did, though, modify my code to check to see if it was a byte type, and if so, change the saturation threshold to 250."

Looks pretty good overall. Only suggestion I have is that I did find a way to get the saturation level that you might be interested in. I don't know that it is 100% foolproof, but see what you think:

I also built a dmg with these changes for OS X: www.indilib.org/jdownloads/kstars/beta/kstars-3.4.0-beta3.dmg

Doesn't it usually become a different color when disabled like a gray color? That is usually the better way.

I just tested it. the left one works great! The auto button has an issue though. When auto is selected, its blank, and then when you move a slider, the button appears. Is it supposed to be no button at all when auto is selected?

Here are some screenshots of similar interfaces from PixInsight and Luminar.

I think its much improved!!

you answered my question about the absolute sliders adequately. I can see how the absolute slider would not be easy to use because of the fine adjustments required. It would still be nice to have some visual information about where in the range the current value happens to be, but that doesn't have to be in the form of an absolute slider.

So my suggestion for your downside: I believe you have stretch and auto enabled by default correct? So then all should be enabled, it would only be disabled if they uncheck stretch so it shows a linear image.

I'm not sure you understand my comment about how auto didn't change the sliders. What I did is I hit auto first, noted the numbers for the sliders, then I played with one of the sliders, noted the new number it displayed, then I hit auto again. The number displayed on the slider was not the one that was shown when I hit auto the first time, but it instead showed the last number I had gotten when playing with the slider. Auto clearly changed the image, but it didn't change the info on the slider.

oh one more question. What will be done with the fits filters under the view menu?

oh related to what I just said, turning on "auto" does not change the values on the sliders. is it supposed to?

That does look much better. I am uncertain as to whether highlights is needed or not, we should try it on some bright planet or moon images before getting rid of it.

Another question, why does the image get grainy when dragging the sliders? Is that to reduce the memory or processor load required? Or maybe to speed it up?

My first observation is that I am very impressed! This is an awesome and sorely needed functionality and you did it so fast!!!

But even if you do improve the internal guider, that doesn't mean folks would not want the option available to redo the calibration every time. Ok I think it makes sense.

One concern that I have about this is that PHD2 today can reuse the same calibration between different observing sessions and at many different positions in the sky. It is supposed to correct for the changes. I'm not totally convinced yet that it does, but every time I have used it since they made that change, it has worked very well. So often you don't want to reset the guiding calibration when using PHD2.

That works much better!

The toggle button does not appear to be "checked" when it is turned on like the other ones I made do. Can you make it get highlighted/checked when you click it to turn it on?

This looks like a great idea. I haven't had a chance to set up my telescope, but I did try it in the simulator. I held down the arrow button on the Mount Toolbox while it was trying to solve an image, but it still successfully solved the image. I am not sure if the CCD Simulator didn't give the same signal that a real mount would, but I would have expected the solver to not complete until I stopped pressing the slew button based on what you described and what the code looks like.

This appears to work very well! Great work!

Deleting arcsec symbol where it should not be

fixing possible crash

beautification

simplification

commas not args

Resorting getExposeLeft, and updating the summary screen timer

That makes sense, because they may want just the exposure time, not the exposure time plus download

oh ok, gotcha. I see now they are different types of messages.

It looks like this would give the user duplicate messages on success or failure of dithering. I can't test it now due to time constraints, but it looks like it would tell the user:

I like it, this is a great idea!

Ok I think these changes make a lot of sense. Making a method for checking if guiding is active instead of just checking the state is a very good idea because then we can do what you did and check a number of guide states at the same time, but also if we need to check something else besides the state we could do that too. So I like that.

I'm glad, this is a better solution than just turning on auto star.

Please see if clearing the starCenter helps.

Clearing starCenter variable

It did work for PHD2. There must be something else for the internal guider.

Please see if this is any better. Also make sure it works!

Clearing the tracking box after the meridian flip rather than setting autostar.
Also doing it for both Internal Guider AND PHD2, instead of just PHD2.

I was not aware that the tracking star still being selected when guiding resumes after a meridian flip was affecting the internal guider as well? From the forum you posted, I'm not sure I'm clear if this is part of the problem or the whole problem they were having. Clearly though the one person at the start of the thread didn't have the clear mount calibration option set and that was causing issues with the internal guider. Is it also still trying to track the old guide star after it moves/flips?
Hmm. Maybe I will try this out when I get a chance.

I'm not sure if we should change the KStars/Ekos default for checking the autostar box. Currently the default is false, I just checked.

I took the one line back out.

Taking the one line back out

Ok yes, so then I should remove that one line, I misinterpreted what you said in the first place to mean that you thought that every time it should default to having autostar checked when PHD2 is used as the guider unless the user disables it specifically. I don't think it should cause any issues except with the meridian flip and this patch will fix that anyway.

So Ekos uses the green tracking box as the coordinates that will be used to set PHD2's lock position. If the green tracking box has not been set, then PHD2 will automatically choose a star even if autostar isn't selected.

2- I'm not sure the autoStarCheck->setChecked(true); inside of Guide::resizeEvent() is quite right. I would think we'd want to default this way if the user hasn't previously set a preference, but one he/she does express a preference, then the preference should be remembered across sessions. The way I read this is that it doesn't allow the user to keep his preference across sessions. So, I'd keep this as is, if the cross-session thing is complex, but would like the end-game to be restoring the user's preference.

1- In the new method, Guide::guideAfterMeridianFlip(): Why would the issue be only related to PHD2? Wouldn't the internal guider also have the same issue? That is, after a meridian flip, the guide star's image position would change either when using PHD2 or with the native guider, so I would think you'd want to remove the "if(guiderType == GUIDE_PHD2)" test, and simply set autoStarCheck->setChecked(true); in either case.

Ok I think I resolved all those issues. It seems to be working better now. Please test again.

Removing option for external guide frames, fixing missing method, saving subFrame setting for PHD2, improving logic.

Please test again to see if I fixed all the issues. I also reduced the message spam from the configure PHD2 camera method.

I also successfully managed to get my idea of SubFrame implemented. It seems to work perfectly now, and lets you click to subframe to the Guide Star Image when you like, and go back too.

"Personally, I do not like it when the FITS viewer pops up with the image from the guiding camera - no matter in what state Ekos and PHD2 are. I am not fully aware of all the consequences what happens if it is turned off."

Fixing Linguider issues, Making SubFrame Button work, cleaning up methods, and fixing disabling external guider when not connected.

So I figured out why the restart was required (at least for my code) when switching between full external guide frames and the guide star image from PHD2. It was a matter of two methods with very similar names but different parameters. So I had given it the wrong parameter. I think it works now. I'm pretty sure we can now make a button to click back and forth between full external guide frames and the guide star image. It would be just like going to a subframe, except it isn't really. Thoughts?

Fixed the external guide frame enable/disable issue that was requiring restart.

Changing to contains method

In D24257#538989, @wreissenberger wrote:

One behavior that seems to be new: if PHD2 is not connected to EKOS and PHD2 is looping, the images of the guiding camera are displayed in the FITS viewer. Is there a reason behind or is it simply a bug?

Fixing i18n